Ol 629 Stud

V8.
cover
Front cover
DB2 for i: DB Coding and

Implementation Using DDS
and CL Commands
(Course code OL62)
Student Notebook
ERC 9.0
Student Notebook
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International
Business Machines Corp., registered in many jurisdictions worldwide.
The following are trademarks of International Business Machines Corporation, registered in
many jurisdictions worldwide:
AS/400
Integrated Language
Environment
Language Environment
Power Systems Software
Redbooks
VisualAge
400
DB
iSeries
DB2
i5/OS
MVS
Power
RPG/400
WebSphere
Power Systems
Rational
System i
xSeries
Adobe is either a registered trademark or a trademark of Adobe Systems Incorporated in

the United States, and/or other countries.
Pentium is a trademark or registered trademark of Intel Corporation or its subsidiaries in
the United States and other countries.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or
both.
Microsoft, Windows and Windows NT are trademarks of Microsoft Corporation in the
United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Java and all Java-based trademarks and logos are trademarks or registered trademarks
of Oracle and/or its affiliates.
Other product and service names might be trademarks of IBM or other companies.
June 2013 edition

The information contained in this document has not been submitted to any formal IBM test and is distributed on an as is basis without
any warranty either express or implied. The use of this information or the implementation of any of these techniques is a customer
responsibility and depends on the customers ability to evaluate and integrate them into the customers operational environment. While
each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will
result elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk.
Copyright International Business Machines Corporation 1997, 2013.

This document may not be reproduced in whole or in part without the prior written permission of IBM.
Note to U.S. Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions
set forth in GSA ADP Schedule Contract with IBM Corp.
V8.0
Student Notebook
TOC
Contents
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Course description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Unit 1. Introduction to DB2 for i database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
The relational model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
Relational operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4
Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5
Select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
Union . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8
Inner join . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
Left outer join . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12
Unit 2. Physical files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2
2.1. Physical file DDS keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3
Physical file DDS keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4
IBM i files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5
Field/Record level description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7
Physical file components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8
Data Description Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9
PF, LF keywords summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11
Keyword levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12
File-level keywords: REF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-13
File-level keywords: UNIQUE, FCFO, FIFO, and LIFO . . . . . . . . . . . . . . . . . . . . . 2-14
Record-level keywords: FORMAT and TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15
Field definition and keywords definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16
Field-level keywords: Data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17
Field-level keywords: ALIAS, ALWNULL, DATFMT, and DATSEP . . . . . . . . . . . . 2-19
Field-level keywords: DFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20
Field-level keywords: FLTPCN and REFFLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21
Field-level keywords: TEXT, TIMFMT, and TIMSEP . . . . . . . . . . . . . . . . . . . . . . . 2-22
Field-level keywords: VARLEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
Field-level keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-24
Key-level keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-26
2.2. Physical file creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-29
Physical file creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30
Creating a physical file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-31
Copyright IBM Corp. 1997, 2013

Course materials may not be reproduced in whole or in part
without the prior written permission of IBM.
Contents
iii
Student Notebook
CRTPF: Create physical file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-32

Multiple members in a file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-33
Multiple member files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-34
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-35
Lab exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-36
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-37
Unit 3. IBM i application development tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-2
3.1. Introduction to IBM i application development tools . . . . . . . . . . . . . . . . . . . . . . . . .3-3
Introduction to IBM i application development tools . . . . . . . . . . . . . . . . . . . . . . . . .3-4
Programming tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-5
RDS/RDP 8.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-6
Tool choices: Editors (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-8
Tool choices: Editors (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-10
3.2. LPEX Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-11
LPEX Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-12
LPEX Editor overview (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-13
LPEX Editor overview (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-14
LPEX Editor interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-15
SEU-like features: Prompting DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-17
Multiple edit windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-18
Help: At your fingertips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-19
LPEX Editor compile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-20
Working disconnected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-21
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-22
Lab exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-23
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-24
Unit 4. Adding data to physical files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-2
Adding data to a physical file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3
Copy file review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-4
Copy file: FROMMBR and TOMBR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-6
Copy file: CRTFILE and MBROPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-7
Copy file: FROMRCD and TORCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-8
Copy file: FROMKEY and TOKEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-9
Copy file: NBRRCDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-10
Copy file: INCCHAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-11
Copy file: INCREL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-12
Copy file: FMTOPT(*DROP *MAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-13
Copy file: FMTOPT(*NOCHK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-15
Creating test data using a DB copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-16
Create a file not previously defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-17
View data in file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-18
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-19
Lab exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-20
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-21
iv
Coding Using DDS and CL Commands

V8.0
Student Notebook
TOC
Unit 5. Field reference file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2
Field reference file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3
Use field reference file for new file definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-4
Field reference file supplies field definitions at file creation . . . . . . . . . . . . . . . . . . 5-5
How do you structure a field reference file? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-7
Fields in alphabetical sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-8
Fields by record format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-9
Field reference file keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-10
Why use field reference files? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-11
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-12
Lab exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-13
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-14
Unit 6. Non-join logical files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2
A logical file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3
Non-join logical file keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-4
File-level keyword: REFACCPTH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5
Record-level keyword: PFILE (1 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-6
Record-level keyword: PFILE (5 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-10
Record-level keyword: PFILE (6 of 6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-11
Field-level keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-12
Field-level keywords: Renaming fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13
Field-level keywords: CONCAT and SST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-14
Field-level: Changing field lengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-15
Field-level: Changing data type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-16
Key-level keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-17
Select-/Omit-level keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-18
Select-/Omit-level keywords: Examples (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . 6-19
Select-/Omit-level keywords: Examples (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . 6-20
File-level keyword: DYNSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-22
Creating a logical file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-23
CRTLF: Create logical file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-24
Checkpoint (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25
Checkpoint (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-26
Lab exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-27
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-28
Unit 7. Join logical files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Join logical files: Simplicity and performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Join logical file (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
7-1
7-2
7-3
7-4
7-5
7-6
v
Student Notebook
Multiple secondary matches case (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-8

Multiple secondary matches case (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-9
Missing secondary records case (1 of 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-10
Join field does not have to be in resulting format (1 of 2) . . . . . . . . . . . . . . . . . . . .7-13
Join field does not have to be in resulting format (2 of 2) . . . . . . . . . . . . . . . . . . . .7-14
More than one field to join files (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-15
More than one field to join files (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-16
Joining more than two files (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-17
Joining more than two files (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-18
File joined to itself (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-19
File joined to itself (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-20
Lab example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-21
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-22
Lab exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-23
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-24
Unit 8. Database maintenance considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-2
Database maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-3
Example: Enlarging a field size (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-4
Example: Enlarging a field size (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-5
DSPFFD: Fields within file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-6
DSPPGMREF: Files used by programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-7
DSPDBR: Which LFs use which PFs? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-8
System cross-reference files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-9
Using system cross-reference files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-10
FNDSTRPDM: Find string with PDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-11
FNDSTRPDM parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-12
Example: Implement the field change (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-13
Example: Implement the field change (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-14
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-15
Lab exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-16
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8-17
Unit 9. Interface to DB2 for i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-2
9.1. Traditional interface: PDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-3
Traditional interface: PDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-4
Application Development Toolset for IBM i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-5
STRPDM: Programming Development Manager . . . . . . . . . . . . . . . . . . . . . . . . . . .9-7
PDM options to access database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-8
9.2. Data file utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-9
Data file utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-10
Generates interactive program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-11
DFU features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-12
Using DFU versus writing a program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-13
vi

V8.0
Student Notebook
TOC
STRDFU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create a DFU Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Define General Information/Indexed File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Define Audit Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work with Record Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Select and Sequence Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Work with Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specify Extended Field Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exit DFU Program Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Change a Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Initially, change mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entry mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F3=Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DFU commands and objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3. Rational Developer for Power Systems: RSE . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Rational Developer for Power Systems: RSE . . . . . . . . . . . . . . . . . . . . . . . . . . . .
RSE: IBM i/OS workbench perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Manage objects through filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a library filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating an object filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating a member filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Editing: Compiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.4. Structured Query Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Structured Query Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introducing SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SQL program products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
More terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types of SQL statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Run SQL statements (RUNSQLSTM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interactive SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interactive SQL: Enter SQL Statements panel . . . . . . . . . . . . . . . . . . . . . . . . . . .
Create CLASSPF table with interactive SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Select a CREATE statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Panel for defining a table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enter SQL statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SELECT statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How the SELECT looks during prompting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resulting query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.5. IBM i Access: System i Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IBM i Access: System i Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Starting System i Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What is System i Navigator? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Integration with Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
File shares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Open a table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Table properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
9-14
9-15
9-16
9-17
9-18
9-19
9-20
9-21
9-22
9-23
9-24
9-25
9-26
9-27
9-29
9-30
9-31
9-33
9-34
9-35
9-36
9-37
9-39
9-40
9-41
9-43
9-44
9-45
9-48
9-49
9-50
9-51
9-52
9-53
9-58
9-59
9-61
9-62
9-63
9-64
9-65
9-66
9-67
9-68
9-71
9-72
9-74
9-75
vii
Student Notebook
Run SQL scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-77

Data Transfer Excel Add-in install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-78
Microsoft Excel: Transfer data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-79
Creating a schema with System i Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-80
SQL schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-81
Using System i Navigator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-82
Create new table: GRADEPF99 add fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-83
New View: CLSGRDIJ99 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-85
New View: Join Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-88
New View: Join Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-90
New View: CLSGRDIJ99 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-91
New View: Show Generated SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-93
9.6. Query for IBM i and Query Manager: QRY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-95
Query for IBM I Query Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-96
IBM i query products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-97
Query Manager and Query for IBM i: Similarities . . . . . . . . . . . . . . . . . . . . . . . . . .9-99
Query Manager and Query for IBM i: Differences . . . . . . . . . . . . . . . . . . . . . . . .9-100
QUERY menu: STRQRY or GO QUERY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-101
Checkpoint (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-103
Checkpoint (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-104
Lab exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-105
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-106
Unit 10. Database performance considerations for application design . . . . . . . . .10-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-2
Performance considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-3
Logical file access path sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-4
Automatic access path sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-5
Minimizing logical files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-7
Variable-length fields (1 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-8
Variable-length fields (2 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-9
Variable-length fields (3 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-10
Variable-length fields (4 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-11
Variable-length field recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-12
File attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-13
Compile and compile listing options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-14
CRTPF: Space allocation parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-15
CRTPF and CRTLF: Availability and recovery parameters . . . . . . . . . . . . . . . . .10-16
CRTPF and CRTLF: Change control parameters . . . . . . . . . . . . . . . . . . . . . . . . .10-17
CRTPF: Application performance parameters . . . . . . . . . . . . . . . . . . . . . . . . . . .10-18
OVRDBF parameters (1 of 5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-20
Parallel, concurrent, and interruptible reorganize (1 of 2) . . . . . . . . . . . . . . . . . . .10-26
Parallel, concurrent, and interruptible reorganize (2 of 2) . . . . . . . . . . . . . . . . . . .10-27
Checkpoint (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10-29
viii

V8.0
Student Notebook
TOC
Checkpoint (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-30
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10-31
Unit 11. Referential integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2
DB2 referential integrity (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3
DB2 referential integrity (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4
Referential integrity benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-5
Referential integrity: Concepts (1 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-6
Referential integrity: Concepts (4 of 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-10
Referential constraint: Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11
Referential integrity: An example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-13
Referential integrity: Requirements (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-14
Referential integrity: Requirements (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-16
Creating primary key constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-17
Creating a referential constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-18
Building a referential integrity network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-19
Displaying constraint information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-21
Constraint states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-22
Verifying constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-23
Access paths and referential integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-24
Journaling and commitment control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-26
Monitoring exceptions in applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-28
Check pending: Unmatched foreign keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-29
Work with Physical File Constraints: WRKPFCST . . . . . . . . . . . . . . . . . . . . . . . 11-31
Constraint management commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-32
Edit Check Pending Constraints: EDTCPCST . . . . . . . . . . . . . . . . . . . . . . . . . . 11-34
Check constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-35
Adding a check constraint example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-36
Referential integrity and journal changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-37
Save and restore considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-39
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-41
Lab exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-42
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-43
Unit 12. Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2
DB2 for i triggers: Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3
Triggers: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4
Triggers: An example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5
Trigger: Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6
Execution order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-8
ADDPFTRG: Add physical file trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-9
RMVPFTRG: Remove physical file name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-11
ADDPFTRG and RMVPFTRG considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 12-12
Trigger parameters (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-13
Contents
ix
Student Notebook
Trigger parameters (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-14

Suppose trigger ends abnormally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-15
Logical trigger failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-17
Data integrity and trigger failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-18
Additional trigger considerations and recommendations (1 of 2) . . . . . . . . . . . . .12-20
Additional trigger considerations and recommendations (2 of 2) . . . . . . . . . . . . .12-23
Trigger can perform update cascade (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-26
Trigger can perform update cascade (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-27
Checkpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-28
Lab exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-29
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-30
Unit 13. Course summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-1
Unit objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-2
What can you do now? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-3
13.1. Your next step. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-5
Your next step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-6
Database courses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-7
Congratulations! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-8
Unit summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13-9
Appendix A. Checkpoint solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

V8.1
Student Notebook
TMK
Trademarks
The reader should recognize that the following terms, which appear in the content of this
training document, are official trademarks of IBM or other companies:
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International
Business Machines Corp., registered in many jurisdictions worldwide.
The following are trademarks of International Business Machines Corporation, registered in
many jurisdictions worldwide:
AS/400
Integrated Language
Environment
Language Environment
Power Systems Software
Redbooks
VisualAge
400
DB
iSeries
DB2
i5/OS
MVS
Power
RPG/400
WebSphere
Power Systems
Rational
System i
xSeries
Adobe is either a registered trademark or a trademark of Adobe Systems Incorporated in

the United States, and/or other countries.
Pentium is a trademark or registered trademark of Intel Corporation or its subsidiaries in
the United States and other countries.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or
both.
Microsoft, Windows and Windows NT are trademarks of Microsoft Corporation in the
United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other
countries.
Java and all Java-based trademarks and logos are trademarks or registered trademarks
of Oracle and/or its affiliates.
Other product and service names might be trademarks of IBM or other companies.

Trademarks
xi
Student Notebook
xii

V8.0
Student Notebook
pref
Course description
DB2 for i: DB Coding and Implementation Using DDS and CL Commands
Duration: 3 days
Purpose
This classroom course of three days teaches basic relational database
theory, coding, creation, and maintenance of DB2 for i physical and
logical files. It teaches many techniques that, if implemented, will
enhance the performance of applications using the database. This
course does not discuss in detail, the use of SQL for database
management.
Audience
This course is designed for persons who will be responsible for
creating and maintaining a DB2 for i database. It will also provide the
necessary foundation for those persons intending to write application
programs for DB2 for i.
Prerequisites
Before taking this course, a student should be able to:
Use a Windows-based PC
Navigate and use a Windows-based desktop
Use basic IBM i navigation tools, including:
- CL commands
- Menus
- Online Help
- WRKSPLF and related commands to manage output
- WRKJOB, DSPMSG, DSPJOB commands and so forth to perform
basic problem determination
Use the Program Development Manager/Source Entry Utility or the
RSE LPEX Editor to create and maintain source files
List and explain the use of data types supported by the DB2 for i
database
Prerequisite courses:
- OE98/OE980: Introduction to IBM i for New Users
- OL49/OL490: IBM i Application Programming Facilities
Workshop

Course description
xiii
Student Notebook
Objectives
After completing this course, a student should be able to do the
following:
Create the physical and logical files required to implement a
database design
Understand the function of and create a field reference file
Explain how choices made while coding and creating a file affect
performance
Understand the different ways to interface to DB2 for IBM i
Perform database maintenance
Understand the concepts of referential integrity and triggers
Curriculum relationship
This course follows Programming Facilities Workshop for IBM i (5
days) (OL490 or OV490).
xiv

V8.0
Student Notebook
pref
Agenda
Day 1
Welcome and administration
Unit 1: Introduction to DB2 for i database
Unit 2: Physical files
Exercise 1: IBM i physical file coding (paper lab without a field
reference file)
Unit 3: IBM i application development tools
Exercise 2: Physical file creation (without a field reference file)
Unit 4: Adding data to physical files
Exercise 3: Adding data to physical file (CPYF)
Unit 5: Field reference file
Exercise 4: IBM i field reference file
Exercise 5: Physical file coding (with field reference file)
Day 2
Unit 6: Non-join logical files
Exercise 6: Logical file coding
Unit 7: Join logical files
Exercise 7: Join logical file coding
Unit 8: Database maintenance considerations
Exercise 8: Impact of field change
Exercise 9: DB maintenance
Unit 9: Interface to DB2 for i
Exercise 10: Interface to DB2 for i
Day 3
Unit 10: Database performance considerations for application design
Unit 11: Referential integrity
Exercise 11: Referential integrity
Unit 12: Triggers
Exercise 12: Triggers
Unit 13: Course summary

Agenda
xv
Student Notebook
xvi

V8.0
Student Notebook
Uempty
Unit 1. Introduction to DB2 for i database

What this unit is about
The DB2 for i database is a relational database. This unit describes
how it is implemented on the IBM i system.
What you should be able to do

After completing this unit, you should be able to:
Describe the relational operators
Describe IBM i relational database implementation
How you will check your progress

Accountability
Checkpoint questions

1-1
Student Notebook
Unit objectives
IBM i

Copyright IBM Corporation 1997, 2013. All Rights Reserved.

US Government Users Restricted Rights - Use duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp
Figure 1-1. Unit objectives
OL629.0
Notes:
1-2

V8.0
Student Notebook
Uempty
The relational model

IBM i
All data items are in base tables.

Views of the data in the base tables are created using the
relational operators of Sequence, Select, Project, Union, and
Join.
Any change to the data is immediately reflected in all the
views.
There are no embedded pointers or linkages in the data
records.

Figure 1-2. The relational model
OL629.0
Notes:
A relational database is a database that can be perceived as a set of tables and can be
manipulated in accordance with the relational model of data. The relational database
contains a set of objects used to store, access, and manage data. The set of objects
includes tables, views, indexes, and packages. For the IBM i, the relational database is an
integrated part of the operating system.

1-3
Student Notebook
Relational operators
IBM i
Sequence (row sequence)

Selection (row selection)
Project (column selection)
Union (rows from multiple tables)
Join (columns from multiple tables)

Figure 1-3. Relational operators
OL629.0
Notes:
These are the general relational database operators implemented on the IBM i using either
Data Description Specifications (DDS) or Structured Query Language (SQL).
1-4

V8.0
Student Notebook
Uempty
Sequence
IBM i
COURSE
CODE
L001
L103
L211
L303
L001
L214
L211
L103
L001
L306
L370
COURSE
NAME
NUMBER
ENROLLED
INSTRUCTOR
12
23
05
44
23
11
01
00
2
3
99
DANTE
HIGGINS
CERVANTES
TSUNG
DANTE
HOMER
HIGGINS
HOMER
CERVANTES
HOMER
HOMER
ITALIAN
ENGLISH
SPANISH
CHINESE
ITALIAN
GREEK
SPANISH
ENGLISH
ITALIAN
JAPANESE
COBOL
COURSE
CODE
L211
L001
L001
L001
L103
L211
L214
L103
L306
L370
L303
COURSE
NAME
SPANISH
ITALIAN
ITALIAN
ITALIAN
ENGLISH
SPANISH
GREEK
ENGLISH
JAPANESE
COBOL
CHINESE
QTR
CLASS
ROOM
CLASS
MAX
93/1
93/1
93/1
93/1
93/1
93/1
93/2
93/2
93/2
93/2
93/2
1
4
4
3
1
6
4
4
1
6
5
30
40
40
50
30
35
40
40
30
35
99
Sequence
the file on
INSTRUCTOR
NUMBER
ENROLLED
INSTRUCTOR
QTR
CLASS
ROOM
CLASS
MAX
05
2
12
23
23
01
11
00
3
99
44
CERVANTES
CERVANTES
DANTE
DANTE
HIGGINS
HIGGINS
HOMER
HOMER
HOMER
HOMER
TSUNG
93/1
93/2
93/1
93/1
93/1
93/1
93/1
93/2
93/2
93/2
93/1
4
1
1
1
4
4
6
4
6
5
3
40
30
30
30
40
40
35
40
36
99
80

Figure 1-4. Sequence
OL629.0
Notes:
The sequence relational operator logically sorts the file.
On the IBM i, sequencing may be achieved through one or more key fields defined in the
physical file or a separate view (logical file).
Most query tools allow the data to be sequenced dynamically at the time the query is
processed.

1-5
Student Notebook
Select
IBM i
Select
where
enrollment
is greater
than 20
students
COURSE
CODE
L001
L103
L211
L303
L001
L214
L211
L103
L001
L306
L370
COURSE
NAME
ITALIAN
ENGLISH
SPANISH
CHINESE
ITALIAN
GREEK
SPANISH
ENGLISH
ITALIAN
JAPANESE
COBOL
COURSE
CODE
L103
L303
L001
L370
NUMBER
ENROLLED
12
23
05
44
23
11
01
00
2
3
99
COURSE
NAME
NUMBER
ENROLLED
ENGLISH
CHINESE
ITALIAN
COBOL
23
44
23
99
INSTRUCTOR
DANTE
HIGGINS
CERVANTES
TSUNG
DANTE
HOMER
HIGGINS
HOMER
CERVANTES
HOMER
HOMER
QTR
93/1
93/1
93/1
93/1
93/1
93/1
93/2
93/2
93/2
93/2
93/2
CLASS
ROOM
1
4
4
3
1
6
4
4
1
6
5
INSTRUCTOR
QTR
CLASS
ROOM
CLASS
MAX
HIGGINS
TSUNG
DANTE
HOMER
93/1
93/1
93/1
93/2
4
3
1
5
40
50
30
99
CLASS
MAX
30
40
40
50
30
35
40
40
30
35
99

Figure 1-5. Select
OL629.0
Notes:
The select relational operator performs a logical record select.
Only the records (rows) selected are visible and can be updated when this view is used.
Record selection may also be achieved through a logical file, though this is not normally
recommended. Most query tools provide more powerful (and flexible) record selection
capabilities.
1-6

V8.0
Student Notebook
Uempty
Project
IBM i
COURSE
CODE
COURSE
NAME
L001
ITALIAN
L103
ENGLISH
L211
NUMBER
ENROLLED
INSTRUCTOR
QTR
CLASS
ROOM
CLASS
MAX
12
DANTE
93/1
30
23
HIGGINS
93/1
40
SPANISH
05
CERVANTES
93/1
40
L303
CHINESE
44
TSUNG
93/1
50
L001
ITALIAN
23
DANTE
93/1
30
L214
GREEK
11
HOMER
93/1
35
L211
SPANISH
01
HIGGINS
93/2
40
L103
ENGLISH
00
HOMER
93/2
40
L001
ITALIAN
CERVANTES
93/2
30
L306
JAPANESE
HOMER
93/2
35
L370
COBOL
99
HOMER
93/2
99
COURSE
NAME
ITALIAN
ENGLISH
SPANISH
CHINESE
ITALIAN
GREEK
SPANISH
ENGLISH
ITALIAN
JAPANESE
COBOL
PROJECT
NUMBER
ENROLLED
QTR
12
23
05
44
23
11
01
00
2
3
99
93/1
93/1
93/1
93/1
93/1
93/1
93/2
93/2
93/2
93/2
93/2

Figure 1-6. Project
OL629.0
Notes:
The project relational operator performs a field select.
Only the fields (columns) projected are visible and can be updated when this view is used.
This operator is often used for security and end-user queries.
Logical files can be used for column projection.

1-7
Student Notebook
Union
IBM i
COURSE
CODE
L001
L001
L001
L001
L001
QTR
92/3
92/3
92/3
92/4
92/4
STUDENT
NAME
PARKER,C
TORME,M
KENTON,S
DAVIS,M
BRUBECK,D
GRADE
93
86
96
81
90
COURSE
CODE
L001
L001
L001
L001
L001
QTR
STUDENT
NAME
BOWIE,D
LAUPER,C
TURNER,T
MADONNA
STING
93/1
93/1
93/1
93/2
93/3
GRADE
93
72
79
UNION of 92 and 93 FILES

COURSE
CODE
L001
L001
L001
L001
L001
L001
L001
L001
L001
L001
QTR
92/3
92/3
93/3
92/4
92/4
92/1
93/1
93/1
93/2
93/3
STUDENT
NAME
KENTON,S
PARKER,C
BOWIE,D
BRUBECK,D
TORME,M
DAVIS,M
TURNER,T
LAUPER,C
MADONNA
STING
GRADE
96
93
93
90
86
81
79
72
Union requires
a sequence

Figure 1-7. Union
OL629.0
Notes:
A union stacks multiple (same format) small tables together to form a single large table.
This operator is used extensively in mainframe applications to keep individual table size
down and performance up.
The union above was sequenced by GRADE. A union of two files on the IBM i system
requires that the file have a key.
Unions and joins (see below) are another function of logical files.
1-8

V8.0
Student Notebook
Uempty
Inner join
IBM i
GREEK
CODE
TITLE
INSTRUCTOR
CODE
STUDENT
GRADE
L001
ITALIAN
DANTE
L001
BOWIE,D
93
L103
ENGLISH
HIGGINS
L001
LAUPER,C
72
L211
SPANISH
CERVANTES
L001
TURNER,T
79
HOMER
L103
BOWIE,D
62
L303
STING
86
L214
L303
CHINESE
INNER JOIN
TSUNG
FILE 1 and
FILE 2 joined
on CODE
CODE
TITLE
INSTRUCTOR
STUDENT
GRADE
L001
ITALIAN
DANTE
BOWIE,D
93
L001
ITALIAN
DANTE
LAUPER,C
72
L001
ITALIAN
DANTE
TURNER,T
79
L103
ENGLISH
HIGGINS
BOWIE,D
62
L303
CHINESE
TSUNG
STING
86
Only rows that match are joined.

Figure 1-8. Inner join
OL629.0
Notes:
The inner join is also referred to as a natural join or a matching join.
Joins allow recombination of data stored as separate files (due to normalization) into a
convenient and usable form.
Data presented through a joined logical file can only be used for query purposes. In other
words, the underlying records cannot be changed or deleted, nor can any new records be
added.

1-9
Student Notebook
Left outer join

IBM i
CODE
TITLE
INSTRUCTOR
L001
L103
ITALIAN
ENGLISH
DANTE
HIGGINS
L211
SPANISH
CERVANTES
L214
L303
GREEK
CHINESE
HOMER
TSUNG
CODE
LEFT OUTER
JOIN
STUDENT
GRADE
L001
L103
BOWIE,D
BOWIE,D
93
62
L214
L303
L410
NELSON,W
STING
HOLIDAY,B
97
86
75
FILE 1 and
FILE 2 joined
on CODE
CODE
TITLE
INSTRUCTOR
STUDENT
GRADE
L001
L103
ITALIAN
ENGLISH
DANTE
HIGGINS
BOWIE,D
BOWIE,D
93
62
L211
L214
SPANISH
GREEK
CERVANTES
HOMER
NELSON,W
97
L303
CHINESE
TSUNG
STING
86
Contains all rows from the left table

Figure 1-9. Left outer join
OL629.0
Notes:
The left outer join is sometimes referred to as a value fill or just default value join.
In this type of join, there is a left (primary) and a right (secondary) file. Some primary
records may have no matching secondary records. In this case, the secondary fields are
assigned their default value.
With a join default value specified, the system returns a record, even though the record is
missing in the secondary file. With a join default value specified, missing character fields
normally use blanks, and missing numeric fields use zeros.
In SQL the missing secondary fields would be null and NOT the default value (blanks or
zero).
1-10 Coding Using DDS and CL Commands

V8.0
Student Notebook
Uempty
Checkpoint
IBM i
1. True or False: All data items in a relational database are

stored in base tables.
2. Which of the following are relational operators?
a. Selection
b. Projection
c. Joins
d. All of the above
3. True or False: The IBM i implementation of a relational

database has performance advantage over the traditional
implementation in that it is an integrated part of the operating
system.
Figure 1-10. Checkpoint
OL629.0
Notes:

1-11
Student Notebook
Unit summary
IBM i
Having completed this unit, you should be able to:


Figure 1-11. Unit summary
OL629.0
Notes:
Logical files support all of the relational operators we have covered (including both join
functions).
The i relational database has a performance advantage over the traditional implementation
in that it is an integrated part of the operating system.
The i implementation of a relational database allows the option of not maintaining changes
in logical files while they are not open if the files do not require unique keys. This is done to
improve performance. This option will be covered in detail later.

V8.0
Student Notebook
Uempty
Unit 2. Physical files

Physical files are the heart of an the DB2 for i Database.

Describe an IBM i physical file
Code the DDS and create an IBM i physical file

Accountability
Paper exercise

2-1
Student Notebook
Unit objectives
IBM i


OL629.0
Notes:
2-2

V8.0
Student Notebook
Uempty
2.1. Physical file DDS keywords

2-3
Student Notebook
Physical file DDS keywords
Powertm with IBM i

Figure 2-2. Physical file DDS keywords
8.1
OL629.0
Notes:
Data description specifications (DDS) describe data attributes in file descriptions external
to the application program that processes the data. DDS can be used with the following
types of files:
Physical files (DDS is optional)
Logical files (DDS is required)
Display files (DDS is optional)
We will use DDS to describe (and create) physical files and logical files.
The smallest element of data we wish to define is a field.
Field definitions are grouped together to form a single unit called a Record Layout or
Format.
Physical files only has one format, but other types of file (for example, logical files and print
files) may have multiple formats.
2-4

V8.0
Student Notebook
Uempty
IBM i files
IBM i
Files
File device
Database files
PF
LF
printer
workstation
tape
Source
Data

Figure 2-3. IBM i files
OL629.0
Notes:
Database files are files (including distributed files) whose associated data is stored
permanently in the system.
Device files are files that provide access to externally attached devices such as displays,
printers, tapes, and other systems that are attached by a communications line. The device
files supported are:
Display files, which provide access to display devices
Printer files, which describe the format of printed output
Tape files, which allow access to data files on tape devices
Save files are files that are used to store saved data on disk (without requiring diskettes or
tapes).
Each file type has its own set of unique characteristics that determine how the file can be
used and what capabilities it can provide. The concept of a file, however, is the same
regardless of what type of file it is When a file is used by a program, it is referred to by
name, which identifies both the file description and/or some file types, the data itself. This
2-5
Student Notebook
information is designed to help you understand the common characteristics of all file types
so you can use the files to their full capabilities.
A source file is used when a command alone cannot supply sufficient information for
creating an object. It contains input (source) data needed to create some types of objects.
For example, to create a control language (CL) program, you must use a source file
containing source statements, which are in the form of commands. To create a logical file,
you must use a source file containing DDS.
With source files we can create:
High-level language programs
Control language programs
Logical files
Commands
Physical files
Display files
Printer files
2-6

V8.0
Student Notebook
Uempty
Field/Record level description

IBM i
Field level description
Externally described files

DDS
Record level description
Program-described files
Figure 2-4. Field/Record level description
OL629.0
Notes:
Records in database files can be described in two ways:
Field-level description. The fields in the record are described to the system. Some of
the things you can describe for each field include: name, length, data type, validity
checks, and text description. Database files that are created with field-level descriptions
are referred to as externally described files.
Record-level description. Only the length of the record in the file is described to the
system. The system does not know about fields in the file. These database files are
referred to as program-described files.
Programs can use either externally described or program-described files. However, if you
choose to describe a file to the field-level, the system can do more for you.
For example, when you compile your programs, the system can extract information from an
externally described file and automatically include field information in your programs.
Therefore, you do not have to code the field information in each program that uses the file.

2-7
Student Notebook
Physical file components

IBM i
Physical
File
Object
header
Format
D
D
S
CRTPF
Access
path
Data

Figure 2-5. Physical file components
OL629.0
Notes:
A physical file is defined by:
Object header
Created as a result of the CRTPF command.
Format
Formed by CRTPF using DDS source for record and fields.
Access path
Formed by CRTPF using DDS source.
Member
Created as a result of the CRTPF command. Populated by user

applications, DFU, CPYF, and so on.
2-8

V8.0
Student Notebook
Uempty
Data Description Specifications

IBM i
8 9 10 11 12 13 14 15 16 17 18 19
28 29 30
34 35
36
Usage (I, O, B, H)
Decimal
positions
Length
Data type
Reference (R)
Type(R.K.S.O)
Name
Reserved
Indicator
Not (N)
Indicator
Not (N)
Indicator
Not (N)
Form type
AND/OR/COMMENT
AS/400 DATA DESCRIPTION SPECIFICATIONS
Line
38 39
Pos
41 42
44 45
Functions
65
A
A
A
A
A
A
A
A
A
A
A
A
Figure 2-6. Data Description Specifications
OL629.0
Notes:
Data description specifications (DDS) uses a position-sensitive format. Within a DDS
statement, the data takes its meaning based upon its position in the line. The positions in
the DDS lines that are valid for physical files are:
6
Form type: A = DDS. Blank will default to DDS if the member

type is ICCF, DSPF, LF, PF, or PRTF.
Name type: R = Record name, K = Key field name, blank =
Field name.
Name: Name of record, field, or key field that this DDS
statement affects.
Reference: R = Defined in a reference field or file. Blank in this
field is not referenced. Entering an R in this field is only valid
when 17 is blank and 19-28 contains a field name.
Field length: Only valid when 19-28 contains a field name. Must
be right justified.
Data type: We will discuss valid entries later in this course. Data
type is valid only when 19-28 contains a field name.
17
19 - 28
29
30 - 34
35

2-9
Student Notebook
36 - 37
45 - 80
Decimal Position: 0 through 31 defines the number of decimal

positions in a numeric field. This field should be left blank
unless 19-28 contain the name of a numeric field.
Functions: This is where keywords are defined.

V8.0
Student Notebook
Uempty
PF, LF keywords summary

IBM i
Level
Physical files
Logical
Files
Level
Physical files
Logical files
Files:
ALTSEQ
ALTSEQ
CCSID
DYNSLT
FCFO
FIFO
JDFTVAL
LIFO
FCFO
FIFO
LIFO
REF
REFACCPTH
UNIQUE
UNIQUE
FORMAT
FORMAT
RANGE
REFFLD
REFSHIFT
TEXT
TIMFMT
TIMSEP
Record:
RANGE
REFSHIFT
RENAME
SST
TEXT
TIMFMT
TIMSEP
TRNTBL
VARLEN
PFILE OR
JFILE (one
required for
logical files)
TEXT
TEXT
Join:
JDUPSEQ
JFLD
JOIN
Field:
ALIAS
ALWNULL
CCSID
CHECK (AB,ME,
MF,M10,M10F,
M11,M11F,VN,
VNE)
CHKMSGID
CMP
COLHDG
COMP
DATFMT
DATSEP
DFT
EDTCDE
EDTWRD
FLTPCN
ALIAS
CHECK (AB,ME,
MF,M10,M10F,
M11,M11F,VN,
VNE)
CHKMSGID
VARLEN
Key field:
ABSVAL
DESCEND
DIGIT
NOALTSEQ
SIGNED
UNSIGNED
ZONE
ABSVAL
DESCEND
DIGIT
NOALTSEQ
SIGNED
UNSIGNED
ZONE
Select/Omit:
CMP
COLHDG
COMP
CONCAT
DATFMT
DATSEP
EDTCDE
EDTWRD
FLTPCN
ALL
CMP
COMP
RANGE
VALUES
JREF

Figure 2-7. PF, LF keywords summary
OL629.0
Notes:
This visual summarizes the physical and logical files keywords. We are not going to cover
each and every keyword. In the next visuals, we will focus on the most important keywords.

2-11
Student Notebook
Keyword levels
IBM i
FILE-LEVEL
100
KEYWORDS
200
REF(RDBLIB/EDUCFLDREF)
UNIQUE
300
400
A R
500
A
600
A
700
A
800
A
900
A
1000 A
1100 A
1200 A
1300 A K
F16=Refresh
F17=Repeat
change
RECORD-LEVEL
INSTFMT
INSID
7A
INSNM
TEXT ('INSTRUCTOR MASTER +

FILE')
COLHDG ( ' INSTRUCTOR' 'NUMBER' )
ALIAS (INSTRUCTOR_NUMBER)
FIELD-LEVEL
KEYWORDS
INSID
F9=Retrieve
F10=Cursor
F24=More keys
KEYWORDS

Figure 2-8. Keyword levels
OL629.0
Notes:
Physical file DDS source member format
IBM i DDS file definitions are enhanced by using keywords. The physical location of a
keyword within the source member defines its scope of control.
File-level keywords are located prior to record name
Record-level keywords, between record name and first field name
Field-level keywords, between field name and the next field name or first key field name
Key-level keywords, between key field name and next key field name or end of member
Keywords enable additional field attributes to be specified, for example, default value,
display/print formatting, descriptive narrative, and so on.
Keywords can also be defined at format level and thus apply to all fields.
It is also possible to specify file-level keywords, which apply to all fields in all formats.

V8.0
Student Notebook
Uempty
File-level keywords: REF
A
A
A
A
A
A
A
A
A
A
A
DECIMAL POS
DATA TYPE
NAME
LENGTH
REFERENCE
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS
CCSID(value)
UNIQUE
R
CRSFMT
CRSID
CRSDSC
CRSPRC
CRSDUR
INSID
CRSID
R
R
R
R
R

Figure 2-9. File-level keywords: REF
OL629.0
Notes:
File-level keywords apply to the file in general and must be coded before the record format
line.
The REF keyword is used to identify the file to be referenced for the definition of the field.
This file is called a field reference file. It functions as a data dictionary. We will cover field
referencing in more detail later on.
The Code Character Set Identifier (CCSID) identifies the coding scheme for graphic
representation of the data in a character field. CCSID may also be specified at the
field-level for any field.
For a list of valid CCSIDs for the i System, go to the Information Center, and then use the
following path, Programming > Programming support > Globalization > CCSIDs.

2-13
Student Notebook
File-level keywords: UNIQUE, FCFO, FIFO, and

LIFO
IBM i
Allow duplicate key values?
NO
YES
UNIQUE
FCFO
FIFO
LIFO

Figure 2-10. File-level keywords: UNIQUE, FCFO, FIFO, and LIFO
OL629.0
Notes:
The UNIQUE keyword is used to ensure that duplicate keys do not exist in the file. Attempts
to add records or change existing records which would create a duplicate key condition will
be prevented and an error code will be returned to the program.
The FCFO, FIFO and LIFO keywords specify that, if records exist in the file which have
equal (identical) keys, the first changed (FCFO), the earliest records (FIFO), or the most
recently added records (LIFO) will be retrieved first. Those keywords cannot be used when
the keyword UNIQUE is used.
The key fields definitions are coded as the last DDS entries. We will discuss these later.

V8.0
Student Notebook
Uempty
Record-level keywords: FORMAT and TEXT
STUCLS
CLASNO
COURSE
DECIMAL POS
DATA TYPE
LENGTH
NAME
REFERENCE
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS
FORMAT(FILE1)
TEXT('COURSE FILE')

Figure 2-11. Record-level keywords: FORMAT and TEXT
OL629.0:
Notes:
Record-level keywords are coded anywhere in the function section starting in the line in
which the record format is named and ending before the first field is coded.
Use the FORMAT keyword to specify that this record format is to share the field
specifications for a previously defined record format. The name of the record format you
are defining must be the name of the previously defined record format. Defining any fields
when the FORMAT keyword is used will result in an error at file creation time.
The TEXT keyword allows up to 50 characters of description to be included in the format
portion of the file for each field. It is for documentation purposes only.

2-15
Student Notebook
Field definition and keywords definition

IBM i
100
FILE-LEVEL
KEYWORDS
300
400
500
600
700
800
900
1000
1100
1200
1300
A
A
A
A
A
A
A
A
A
A
REF (RDBLIB/EDUCFLDREF)200
UNIQUE
R
INSTFMT
TEXT ('INSTRUCTOR MASTER + FILE')
RECORD-LEVEL
F16=Refresh
KEYWORDS
F17=Repeat change
INSID
7A
INSNM
COLHDG ( ' INSTRUCTOR' 'NUMBER' )

ALIAS (INSTRUCTOR_NUMBER)
INSID
F9=Retrieve
FIELD-LEVEL
KEYWORDS
F10=Cursor
F24=More keys

Figure 2-12. Field definition and keywords definition
OL629.0
Notes:
Question: Where does field INSNM get its keywords?
Field-level keywords are coded on the same line as the field or following lines but before
the next field is defined.
INSNM is defined as referring to another field (later) for additional attributes (keywords).
This field INSNM has been defined in a separate file called field reference file.
You can use the COLHDG keyword to specify column headings used as a label for a field by
text management, the query utility, the data file utility (DFU), and the screen design aid
(SDA).
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.

V8.0
Student Notebook
Uempty
Field-level keywords: Data types

IBM i
Decimal
positions
Type
Columns . . .
:6
76
RDBLIB/QDDSSRC
SEU==>
FMT PFA. . . . . . T .Name+++++RLen++TDpB. . . . . . . . . . . ..Functions+++++++++++++++++++++
0137.00A
0138.00A
DELRQS
0139.00A
0140.00A
0141.00A
0142.00A
0143.00A
0144.00A
0145.00A
0146.00A
0147.00A
0148.00A
0149.00A
0150.00A
0151.00A
0152.00A
DPTID
DPTORN
DPTUSE
Data Types:
3 (PACKED DECIMAL)
P
S (ZONED DECIMAL)
B (BINARY)
F (FLOATING-POINT)
A (CHARACTER)
H (HEXADECIMAL)
3 (DATE)
L
T (TIME)
9 (TIMESTAMP)
2
Z
LOTID
PAYNET
PAYQTD
COLHDG('Delivery' 'Requested')
ALIAS(REQUESTED_DELIVERY)
COLHDG('Department' 'ID')
Defaults:
A (CHARACTER) IF DECIMAL POS. BLANK
P (PACKED DECIMAL) IF DECIMAL POS 0-31

Figure 2-13. Field-level keywords: Data types
OL629.0
Notes:
For a physical file, we have to specify the data type of each field within the database.
Valid data type entries are as follows:
P = Packed decimal
S = Zoned decimal
B = Binary
F = Floating-point
A = Character
L = Date
T = Time
Z= Timestamp

2-17
Student Notebook
For physical files, if you do not specify a data type or duplicate one from a referenced field,
the i5/OS program assigns the following defaults:
A (character) if the decimal positions 36 through 37 are blank.
P (packed decimal) if the decimal positions 36 through 37 contain a number in the
range 0 through 31.
Field type L denotes a date field, T denotes a time field, and Z denotes a time stamp
field.
- Do not code field size for types L, T, or Z. The system will generate the correct size
field.
Z (timestamp) fields have the form yyyymmddhhmmsszzzzzz where yyyy, mm, dd, hh,
mm, ss, and zzzzzz represent, respectively, the number of years, months, days, hours,
minutes, seconds, and microseconds.
L (date) data type is discussed again when keyword DATFMT is described.

V8.0
Student Notebook
Uempty
Field-level keywords: ALIAS, ALWNULL, DATFMT,

and DATSEP
IBM i
ALIAS (alternative-name): Usage depends on HLL compiler

ALWNULL: Allow null value
DATFMT (date-format): For date fields (data type L)
*ISO
yyyy-mm-dd
*JUL
yy/ddd
*USA
mm/dd/yyyy
*EUR
dd.mm.yyyy
*JIS
yyyy-mm-dd
*MDY
mm/dd/yy
*DMY
dd/mm/yy
*YMD
yy/mm/dd
(default)
DATSEP(*JOB | 'date-separator'): for date fields

Figure 2-14. Field-level keywords: ALIAS, ALWNULL, DATFMT, and DATSEP
OL629.0
Notes:
ALIAS is a very important keyword in that it allows the programmer to define more
descriptive field names than can be defined in the maximum 10-character field name. The
ALIAS name can be up to 30 characters. It is very helpful for languages such as COBOL
that support its use. ALIAS is not supported by RPG. When the program is compiled, the
alternative name is brought into the program instead of the DDS field name. The high-level
language compiler in use determines if the ALIAS name is used.
ALWNULL allows null values. Character fields with null values are set to blanks. Numeric
fields with null values are set to zero.
DATSEP specifies the separator character for this date field.
DATFMT 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). Field length and decimal position values
must be blank.
Separator characters for data type T fields actually appear in the data as it is stored on a
DASD.
2-19
Student Notebook
Field-level keywords: DFT

IBM i
DFT('value' | numeric-value | X'hexadecimal-value' | *NULL)

DFT defines a default value for a field
Value is assigned to field when:
Program uses logical file (LF) to add a physical file (PF) record and LF
does not include this field
You use Initialize Physical File member (INZPFM) for a member in this
file
You use CPYF. . .FMTOPT(*MAP) is issued and a field is not in the
'from-file'
Value is supplied to programs reading join LFs and both conditions

exist:
Field is in missing secondary file record
JDFTVAL keyword is used

Figure 2-15. Field-level keywords: DFT
OL629.0
Notes:
DFT defines a default value for a field. If the DFT keyword is not used, the field defaults to
blanks for a character field and zeros for a numeric field. The DFT() value may be
character, numeric, or X'hex'.
The value specified is assigned to the field in the following cases:
- When the program does an output operation to a logical file based on this physical
file and the record format 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.
The specified value is supplied to the program when the program does an input operation
to a join logical file and all of the following are true:
You specify the JDFTVAL keyword for the join logical file.
The file being defined is specified as a secondary file in the join logical file.
The input operation occurs and the link to the secondary file produces no records.

V8.0
Student Notebook
Uempty
Field-level keywords: FLTPCN and REFFLD

IBM i
FLTPCN (*SINGLE | *DOUBLE) specifies the floating-point precision

REFFLD ([format/] field [{*SRC | library/] file}]) specifies the referenced field.
An R must be in position 29
FIELD1 has the same attributes as FLD1 in FILE1
REF(FILE1)
FIELD1
R
REFFLD(FLD1)
FIELD2 has the same attributes as FLD2 in format RECORD2 of file FILE2
in library LIB2
REF(FILE1)
FIELD2
R
REFFLD(RECORD2/FLD2 LIB2/FILE2)
Referenced field is in same DDS source
REF(FILE1)
FIELD3
R
FIELD4
R
REFFLD(FIELD3 *SRC)
Figure 2-16. Field-level keywords: FLTPCN and REFFLD
OL629.0
Notes:
Use the field-level keyword FLTPCN to specify the precision of a floating-point field.
You have to specify FLTPCN(*SINGLE) or FLTPCN(*DOUBLE), where *SINGLE is single
precision and *DOUBLE is double precision. This keyword is valid for floating-point fields
only (data type F). If you do not specify the FLTPCN keyword, the default is single precision.
A single-precision field can be up to 9 digits; a double-precision field can be up to 17 digits.
If you specify a field length greater than 9 (single precision) or 17 (double precision), an
error message is sent and the file is not created.
The REFFLD keyword is very useful for defining field attributes to be like another
referenced field.

2-21
Student Notebook
Field-level keywords: TEXT, TIMFMT, and TIMSEP

IBM i
TEXT ('description')
TIMFMT (time-format) for data type T
*HMS
hh:mm:ss
*ISO
hh:mm:ss
*USA
hh:mm AM or hh:mm PM
*EUR
See *ISO
*JIS
See *ISO
TIMSEP (*JOB \ 'time-separator') for data type T

Figure 2-17. Field-level keywords: TEXT, TIMFMT, and TIMSEP
OL629.0
Notes:
Use the TEXT keyword to supply a text description (or comment) for the record format or
field that is used for program documentation. The format of the keyword is: TEXT
('description'). The text must be enclosed in apostrophes. If the length of the text is greater
than 50 positions, only the first 50 characters are used by the high-level language compiler.
Use the TIMFMT keyword to specify the format of a time field. This keyword is valid for
either time fields (data type T) or zoned fields (data type S) whose corresponding physical
file fields are time fields (data type T). The format of the keyword is: TIMFMT (time-format)
Use the TIMSEP keyword to specify the separator character used for a time field. This
keyword is valid only for time fields (data type T). The format of the keyword is:
TIMSEP(*JOB | 'time-separator'). The time-separator parameter specifies the
separator character that appears between the hour, minute, and second values. Valid
values are a colon (:), period (.), a comma (,), and blank ( ). The parameter must be
enclosed in apostrophes. If you specify *JOB, the default is the job attribute.

V8.0
Student Notebook
Uempty
Field-level keywords: VARLEN

IBM i
VARLEN[(allocated-length)]
A . . . . . . . T .NAME+++++RLEN++TDpB... Function++++++++
A
VAR1
300A
VARLEN(20)
A
FIELD2
20A
VAR1
FIELD2
20
20
VAR 1 (Variable Portion)
300
Fixed portion

Figure 2-18. Field-level keywords: VARLEN
OL629.0
Notes:
Variable-length fields must be character fields. The field becomes a variable length field
when the VARLEN keyword is specified for the field. The length specified in the LENGTH
field of the DDS becomes the maximum length. If a value is specified with the VARLEN
keyword, it becomes the allocated length in the fixed portion of the record. The VARLEN
keyword only affects the field size when the field is stored on disk. The system uses the
maximum length when the field is printed or displayed.
When the data in the field exceeds the allocated length, the data is stored in the variable
portion along with linkage data that the system uses to tie the variable data to the correct
field. The linkage is approximately 25 characters long. There is no linkage or variable data
for records that do not exceed the allocated length. There is some performance overhead
involved with using variable-length fields. Variable-length fields are well-suited to
description type fields, where in some records the data size will exceed the allocated length
by 50 characters or more, but the majority will not exceed the allocated length. The only
advantage to using variable-length fields is if it will reduce the disk storage significantly.

2-23
Student Notebook
Field-level keywords
IBM i
Keywords that do not affect the PF:

CHECK
EDTCDE
CHKMSGID
EDTWRD
CMP, COMP
RANGE
COLHDG
REFSHIFT
VALUES
But are used when the PF field definition is referred to at creation by:
Display files
Printer files
Screen design aid
QUERY for i5/OS
Data file utility
Report layout utility
Figure 2-19. Field-level keywords
OL629.0
Notes:
It is important to consider the above field-level keywords when creating a field reference file
or other physical file, even though they do not affect the physical file.
You can use CHECK, CMP, COMP, RANGE, or VALUES field-level keywords to specify validity
checking in display files.
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 i5/OS 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.
For example you can specify CHECK(AB), CHECK(ME), CHECK(MF). AB means Allow
blank, ME means Mandatory enter and MF means Mandatory fill.
Use the CHKMSGID keyword to identify an error message that is associated with
validity-checking keywords. If the CHKMSGID keyword is not specified, a system-supplied
message is used. If the CHKMSGID keyword is specified and the field you are now defining
is referred to later during display file creation, the validity checking information and the

V8.0
Student Notebook
Uempty
CHKMSGID keyword are copied into the display file. If a validity-checking error is found
while checking input from the screen, the error message specified on the CHKMSGID
keyword is displayed on the message line.
The format of the keyword is:
CHKMSGID(message-id [library/]message-file [message-data-field])
You can use the EDTCDE keyword to edit output-capable numeric fields.
The format of the keyword is: EDTCDE(edit-code [* |floating-currency-symbol])
Editing includes the following changes to the appearance of displayed fields, depending on
which edit code is specified:
Leading zeros are suppressed.
The field can be punctuated with commas and periods to show decimal position and to
group digits by threes.
Negative values can be displayed with a minus sign or CR to the right.
Zero values can be displayed as zero or blanks.
Asterisks can be displayed to the left of significant digits to provide asterisk protection.
A currency symbol (corresponding to the system value QCURSYM) can be displayed
immediately to the left of the significant digit that is farthest to the left (called the
floating-currency symbol). For fixed-currency symbols, use the EDTWRD keyword.
When EDTCDE is not sufficient, you can use EDTWRD. An edit word specifies the form in
which the field values are to be displayed and clarifies the data by inserting characters
directly, such as decimal points, commas, floating- and fixed-currency symbol, and credit
balance indicators. The edit word can also be used to suppress leading zeros and to
provide asterisk fill protection.
Use these field-level keywords to specify editing for the field you are defining when the field
is referenced later during display or printer file creation. The EDTCDE and EDTWRD
keywords do not affect the physical or logical file.
Coding these keywords at the physical file level makes it easier to perform other functions,
such as building a display file. It also leads to consistency across applications.

2-25
Student Notebook
Key-level keywords
DECIMAL POS
NUMBER
DATA TYPE
LENGTH
NAME
REFERENCE
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS
Keyword
DESCEND
ABSVAL
UNSIGNED
SIGNED
DIGIT
ZONE
NOALTSEQ
Figure 2-20. Key-level keywords
OL629.0
Notes:
The above keywords control how the i database evaluates the key fields for accessing
data.
The DESCEND keyword is used to specify that the values of this character, hexadecimal, or
numeric key field are retrieved in descending sequence. The default is ascending
sequence.
When sequencing the values associated with a numeric key field, the SIGNED keyword
specifies that the i5/OS program is to consider the signs of the values (negative versus
positive values).
Defining the key field as packed decimal or zoned decimal does not affect the sequence of
the records in a file using the ABSVAL, SIGNED, or DESCEND keywords.
The ZONE and DIGIT keywords are not permitted with packed decimal keys.

V8.0
Student Notebook
Uempty
When using the UNSIGNED keyword,

Packed decimal sorts each position of the field as expected without regard to the sign.
Zoned decimal sorts the tens position and higher as expected. The units position sorts
-0, -1, -2, -3, -4, -5, -6, -7, -8, -9, 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9. This pattern results
because zoned decimal sorts a half character at a time and the sign is stored in the first
half of the units position.
Refer to the DDS Reference for detailed information on the use of these keywords in
physical files. Be careful to read the field type restrictions and limits on combinations
with other keywords.

2-27
Student Notebook

V8.0
Student Notebook
Uempty
2.2. Physical file creation

2-29
Student Notebook
Physical file creation
Powertm with IBM i

Figure 2-21. Physical file creation
8.1
OL629.0
Notes:

V8.0
Student Notebook
Uempty
Creating a physical file

IBM i
QDDSSRC
DESCRIPTION
PFILE1
STRSEU
or
RSE/LPEX
CRTPF
LFILE1
PFILE1
DESCRIPTION
DATA
MEMBER

Figure 2-22. Creating a physical file
OL629.0
Notes:
It is at this point (CRTPF) that the file is named to the system.
Normally, the file will have the same name as the source member in the source file, but
there is no reference (other than as TEXT) in the DDS to the actual name of the file.
Three steps have to be performed when creating a DDS file:
1. Assign the DDS needed for the file definitions
Use an editor to specify and store file descriptions, editors include SEU (host), and
RSE/LPEX (client).
The descriptions are stored in a source file (usually QDDSSRC) as a source member
(the member name is usually the same as the physical file name).
2. Create physical file
Use the CRTPF CL command or the LPEX Editor Compile menu option.
DDS file descriptions (if any) are used with CRTPF to define file layout.
3. Load data
Physical file must have at least one member to hold data.
Many methods can be used to load information (*PGM, utilities, SQL, CPY, and so on).

2-31
Student Notebook
CRTPF: Create physical file

IBM i
The syntax of the CRTPF command is the following:

CRTPF
FILE(*CURLIB/file-name)
SRCFILE(*LIBL/QDDSSRC)
SRCMBR(*FILE)
MBR(*FILE)
MAXMBRS(1)
TEXT(*SRCMBRTXT)

Figure 2-23. CRTPF: Create physical file
OL629.0
Notes:
The CRTPF command has many more parameters than are shown here.
Implications of the SIZE parameter will be discussed in a later topic. For now, just take the
default value.
The default member name is the same as the file.
The default value for MAXMBRS is 1.
Here we are creating the file with a member named the same as the file.

V8.0
Student Notebook
Uempty
Multiple members in a file

IBM i
FILE DESCRIPTION
RECORD FORMAT: EMPMAS
FIELDS: EMPNO
EMPNAM
EMPRAT
EMPSSN
KEY - EMPNO
PAYC01
ACCESS PATH
PAYC02
ACCESS PATH
PAYC03
ACCESS PATH
DATA
Figure 2-24. Multiple members in a file
OL629.0
Notes:
A file on the IBM i may be subset in order to maintain separate groupings of records with
their own access path. This is called a multi-membered file.
This is an example of an employee master file for three companies.
The file description is common to all of the members.

2-33
Student Notebook
Multiple member files

IBM i
Use the following commands to:

Create the physical file:
CRTPF
FILE(*CURLIB/PAYROLL)
MBR(PAYC01)
MAXMMBRS(3)
Add additional members:

ADDPFM
MBR(PAYC02)
ADDPFM
MBR(PAYC03)
Figure 2-25. Multiple member files
OL629.0
Notes:
The default member name is the same as the file.
The default value for MAXMBRS is 1.
Here we are creating the file with a member named PAYC01 and adding two more
members named PAYC02 and PAYC03.

V8.0
Student Notebook
Uempty
Checkpoint
IBM i
1. True or False: Data description specifications (DDS) describe

data attributes of files to the system.
2. DDS keywords
a.
b.
c.
d.
Enable additional field attributes to be specified

Can be specified at the file and record levels
Can be specified at the field and key levels
All of the above
3. The REF keyword

a.
b.
c.
d.
Identifies the record format referenced for the definition of a field

Identifies the field referenced for the definition of another field
Identifies the file referenced for the definition of a field
Identifies only a field reference file

OL629.0
Notes:

2-35
Student Notebook
Lab exercise
IBM i
IBM i physical file coding

(paper lab without a field reference file)

Figure 2-27. Lab exercise
OL629.0
Notes:

V8.0
Student Notebook
Uempty
Unit summary
IBM i


OL629.0
Notes:

2-37
Student Notebook

V8.0
Student Notebook
Uempty
Unit 3. IBM i application development tools

This unit introduces the many tools available on the IBM i server and
the PC Windows platform to assist you in performing your day-to-day
application development activities.

Name each of the IBM i application development tools
Identify the platforms on which each tool resides
State the features of the LPEX Editor
Use LPEX Editor to edit and create physical files

Accountability
Machine exercise

3-1
Student Notebook
Unit objectives
IBM i

Use the LPEX Editor to edit and create a physical file

OL629.0
Notes:
3-2

V8.0
Student Notebook
Uempty
3.1. Introduction to IBM i application development tools

3-3
Student Notebook
Introduction to IBM i application

development tools
Powertm with IBM i

Figure 3-2. Introduction to IBM i application development tools
8.1
OL629.0
Notes:
3-4

V8.0
Student Notebook
Uempty
Programming tasks
IBM i
Code programs
Design DB files
Define DB files
Code programs when connected or disconnected to IBM i
Create test data

Compile programs
Test programs
Debug programs
Support applications

Figure 3-3. Programming tasks
OL629.0
Notes:
As you perform these tasks, many tools are available to assist you. Some of them, such as
debugging, are better discussed with specific program examples. However, we introduce
and discuss many of the tools that you will use in this class. In addition, machine exercises
will enable you to learn enough about the tools that you can begin to apply your new skills
as soon as you return to work.

3-5
Student Notebook
RDS/RDP 8.5
IBM i
i V5.4
5722WDS
i V7.1
5770WDS
Base
Option 21 ADTS
Option 31 ILE RPG
Option 32 S/36 Compatible RPGII
Option 33 S/38 Compatible RPGII
Option 34 RPG/400
Option 35 ILE RPG *PRV Compiler
Option 41 ILE COBOL
Option 42 S/36 Compatible COBOL
Option 44 OPM COBOL
Option 45 ILE COBOL *PRV Compiler
Option 51 ILE C
Option 52 ILE C++
Option 56 IXLC for C/C++
Feature: ILE Compilers

Option 31 ILE RPG
Option 35 ILE RPG *PRV Compiler
Option 41 ILE COBOL
Option 45 ILE COBOL *PRV Compiler
Option 51 ILE C
Option 52 ILE C++
Option 56 IXLC for C/C++
Feature: Heritage Compilers

Option 32 S/36 Compatible RPG II
Option 33 S/38 Compatible RPG II
Option 34 RPG/400 (RPG III)_
Option 44 OPM COBOL
WDSC Unlimited
RDP
COBOL, RPG, C/C++
RD for i for SOA

RDP, RBD, HATS
EGL, Web design
RAD
Java
Feature: ADTS
Option 21 ADTS

Figure 3-4. RDS/RDP 8.5
OL629.0
Notes:
There is one consolidated, application development product available for IBM i
programmers. It runs on the IBM i. The product is called the Rational Development Studio
for i V7.1, which includes the following:
IBM i compilers
- ILE RPG (RPG IV)
- ILE COBOL
- ILE C/C++
Application Development ToolSet (ADTS)
- Source entry utility (SEU)
- Screen design aid (SDA)
- Report layout utility (RLU)
- Data file utility (DFU)
3-6

V8.0
Student Notebook
Uempty
- Character generator utility (CGU)

- Advanced printer function (APF)
- Programming Development Manager (PDM)
- Host Access Programs for CODE/400 and VisualAge for RPG
- Interactive source debugger (ISDB)
- File compare and merge utility (FCMU)
Rational Developer for Power Systems Software (RDP) is a workstation-based tool set.
RDP includes:
LPEX Editor
Screen Designer
Report Designer
Debugger
Rational Developer for i for SOA includes:
Rational Developer for Power Systems (RDP)
Rational Business Developer
Rational HATS Toolkit
Rational Application Developer for WebSphere
Java development tools (with IBM i enhancements)
Web development tools (with IBM i enhancements)
Server development tools
Database development tools
Web services development tools
XML development tools
Test environments for WebSphere Application Server and WebSphere Portal products
With IBM i 7.1, RDS has three separately priced optional features: ILE compilers, heritage
compilers, and ADTS (legacy development tools). Modernized shops can now avoid the
cost of legacy tools and compilers they no longer use. PC tool users now have the option of
ordering RDP (to use with RDS) or RD for i for SOA at additional license costs.
Entitlement on the 5770-WDS ILE Compilers, Heritage Compilers, and ADTS features are
based on a maximum number of users per processor tier.
Users of the previous WDSC Standard Edition product are not entitled to use either RDP or
RD for i for SOA. RDP and RD for i for SOA are considered separate new products, not an
upgraded WDSC product.

3-7
Student Notebook
Tool choices: Editors (1 of 2)

IBM i
Source entry utility (IBM i Server)
Create and maintain program source members

Create and maintain database file definition
source
5250 'green screen' interface
Can invoke using STRSEU or from within
Program Development Manager (PDM)

Figure 3-5. Tool choices: Editors (1 of 2)
OL629.0
Notes:
You can use the source entry utility (SEU) to work with source members in source physical
files, and the records contained in source members.
With SEU, you can perform operations such as:
Create members
Edit members
Print members
Copy records into a member from another member or spooled file
These source members can include:
ILE RPG
File description (DDS)
Screen display file source (DDS)
Report definition source (DDS)
3-8

V8.0
Student Notebook
Uempty
DDS (data description specifications) is a common definition used for files, displays, and
reports. Because the IBM i is a database system, it is possible to define fields in one place
and then reference that definition (using DDS) to define other files, displays, and reports.
In this example, we show you some of the source of a DDS source member. You can work
with the member directly on the i system.

3-9
Student Notebook
Tool choices: Editors (2 of 2)

IBM i
LPEX Editor (Windows PC)

Part of RDP set of client tools
Can be connected to i or
disconnected
Uses GUI interface
Tokenizes source and uses
color to differentiate tokens

Figure 3-6. Tool choices: Editors (2 of 2)
OL629.0
Notes:
This is the same source program we showed in the SEU example. You can use whichever
tool you prefer or use them interchangeably.
With the LPEX Editor, you can:
Access local and i source files seamlessly
Download IBM i source members to the PC and then maintain them in disconnected
mode
Work concurrently with multiple edit sessions of the different source members
Navigate through multiple programs and subroutines in one or more source members
Search and compare multiple files at once

V8.0
Student Notebook
Uempty
3.2. LPEX Editor

3-11
Student Notebook
LPEX Editor
Powertm with IBM i

Figure 3-7. LPEX Editor
8.1
OL629.0
Notes:

V8.0
Student Notebook
Uempty
LPEX Editor overview (1 of 2)

IBM i
Seamless access to local and host

source
Language-sensitive editing
Token highlighting
Built-in syntax checking
Source verification
RPG
COBOL,
CL, DDS,
C, C++,
Java, HTML
SEU commands, format rulers, and

prompting
Lots of online help
Windows GUI, clipboard, unlimited
undo
Programmable and customizable
Plus lots more
Figure 3-8. LPEX Editor overview (1 of 2)
OL629.0
Notes:
You can open source from the i, your workstation, or a network drive.
RPG, COBOL and CL are supported in Integrated Language Environment (ILE) and
Non-ILE versions. Free-form RPG is supported starting with V5R1.
The different elements of the programming languages are displayed in different colors in
the Editor to enhance the readability.
Syntax checking and program verification are done on the workstation. A connection to an i
host server is not required to run these functions.
The Editor is by default set to behave like SEU; for example, F1 is used for Help, and F4 for
prompt.
The default behavior of the Editor can easily be changed and expanded. Details for this
capability are given later.

3-13
Student Notebook
LPEX Editor overview (2 of 2)

IBM i
Available for
ILE RPG, RPG/400, SQL RPG, ILE SQL RPG
COBOL, ILE COBOL, SQL COBOL, ILE SQL COBOL
Native System I Control Language Programs (CLP), Native System 38
Control Language Programs (CL), ILE CL
DDS: Printer file (PRTF), logical file (LF), physical file (PF), display file
(DSPF), interactive communications facility file (ICFF)
C, C++
JAVA
HTML

Figure 3-9. LPEX Editor overview (2 of 2)
OL629.0
Notes:
Language features are special features that relate to the fact that you are editing a program
and not just plain text.
Language features and their availability vary between languages.
All features are available while disconnected from the i except:
Prompting for CL and ILE CL
Language sensitive help for CL and ILE CL

V8.0
Student Notebook
Uempty
LPEX Editor interface

IBM i
Format line
Sequence numbers
Syntax checking
Figure 3-10. LPEX Editor interface
OL629.0
Notes:
The LPEX Editor has the standard features of a Windows-based application:
Cut, copy, and paste

Menus
Toolbar
Resizable window
It provides IBM i specific features such as:

Member locking when source member opened for editing
Verification of object authority to prevent users from editing source they are not
authorized to
The area at the top of the editor is used as a ruler for column-sensitive languages. The
ruler helps keep track of columns and position of the cursor. The ruler changes to reflect
the type of line you are on.
Other features are also available:

3-15
Student Notebook
Syntax errors are marked immediately. Interactive (or on demand) syntax checking
allows you to verify directly your code and ask help if needed (F1).
The use of color to display the tokens makes reading source code easier. A token is a
language construct, for example, specification fields for RPG, constructs in COBOL,
columns in DDS, functions in C, and commands and labels in CL. Each token in your
file is displayed in a different color to facilitate reading the source.
Multiple files can be opened at the same time, and you can switch to a different file
using the quick file access. You can even do a search and replace on all loaded files.
Compare is available for all source types. It shows you a graphical comparison of two
files in the editor.
The LPEX Editor has a number of navigational options that helps you to easily find your
way in the code:
Searching and replacing.
Creating and finding marks.
Locating code using line numbers. Pressing CTRL+L or type a line number in the prefix
area will take you to that line. Locating a line number works in both directions, up and
down.
Locating code using filters. Filtering allows you to look only at lines which match the
filter. The editor allows filtering of particular types of lines in a program:
- Comment lines
- For COBOL showing outline lines, shows only COBOL lines that start in area A

V8.0
Student Notebook
Uempty
SEU-like features: Prompting DDS

IBM i
SEU
commands
Format line

Figure 3-11. SEU-like features: Prompting DDS
OL629.0
Notes:
The Editor allows a gentle learning curve. Use it like SEU until you feel comfortable and
learn the more powerful features by exploring the menu items and toolbar.
The Editor displays line numbers for local files and sequence numbers for host members in
the prefix area.
The prefix area allows you to enter SEU editing commands, like d for delete and block
commands like mm to move multiple lines.
Prompts can be used to enter code instead of typing directly into the editor window.
By requesting a prompt, a window appears where you can enter or change a line using
convenient entry fields with descriptions.
Use F4 for prompt, F1 for Help, and so on.

3-17
Student Notebook
Multiple edit windows

IBM i

Figure 3-12. Multiple edit windows
OL629.0
Notes:
The Editor allows several members to be edited:
The default is one edit window for all open source files
Optionally you can have an edit window for each open source file. This option is
enabled by selecting Window > New Window.
You can navigate from source member to source member by using the tabs or the
navigation icons from the tool bar. This example shows the list of members that are
currently opened for edit, as well as those previously opened for edit.

V8.0
Student Notebook
Uempty
Help: At your fingertips

IBM i
Context-sensitive
Message help

Figure 3-13. Help: At your fingertips
OL629.0
Notes:
Language-sensitive help is available by pressing F1.
Pressing Help on a language construct displays specific help for that construct; for
example, pressing F1 while the cursor is on REFFLD in your DDS source displays a
window with possible DDS keywords. You can then choose the description of the keyword
REFFLD from the DDS Reference.
In the case of RPG and DDS, column-sensitive help is available.
DDS also has keyword-sensitive help.

3-19
Student Notebook
LPEX Editor compile

IBM i

Figure 3-14. LPEX Editor compile
OL629.0
Notes:
Right-click a source member and select Compile (Prompt) to get the prompted compile
display.

V8.0
Student Notebook
Uempty
Working disconnected
IBM i
What You CAN DO while disconnected
Work with local source.

Syntax check RPG, ILE COBOL, and DDS
Prompt RPG, COBOL, and DDS.
Access language reference help for RPG, COBOL, and DDS.
Verify RPG, COBOL, and DDS (without caching, copy members and
information on database fields will not be available).
What You CANNOT DO while disconnected
Edit, design, or compile host source.

Debug host programs.
Execute host commands.
Prompt CL statements.

Figure 3-15. Working disconnected
OL629.0
Notes:
All features that execute on the workstation are available with or without connection to an i.
Editing source
Syntax checking
Prompting, except for CL
All online Help
Program verify requires caching to make (or copy) members and database references
available.
Everything that runs on the i will not be accessible when disconnected.
Opening source from the host
Saving source to the host
Compiling
Debugging host applications
Prompting and Help for CL
Running any other host command

3-21
Student Notebook
Checkpoint
IBM i
1. The LPEX Editor can be used to download IBM i source members and
maintain them in (blank) mode from your PC workstation.
a.
b.
c.
d.
Isolated
Check
Disconnected
Verify
2. In order to modify existing DDS for a physical file, you can use:
a.
b.
c.
d.
PDM/SEU
RSE/LPEX
REX
All of the above
3. True or False: RDP and WDS provide an environment where you can
interchangeably maintain source code using workstation tools or hostbased tools.
OL629.0
Notes:

V8.0
Student Notebook
Uempty
Lab exercise
IBM i
Physical file creation (without a

field reference file)

OL629.0
Notes:

3-23
Student Notebook
Unit summary
IBM i

Use the LPEX Editor to edit and create a physical file

OL629.0
Notes:
You now have an appreciation of the IBM i application development tools that are available
and where they can be used.

V8.0
Student Notebook
Uempty
Unit 4. Adding data to physical files

Once the physical file is created using DDS, data can be added using
different methods. This unit describes in detail the copy file command.

After completing this unit, the student should be able to
List the different ways of adding data to a physical file
Use the CPYF command

Accountability
Machine exercise

4-1
Student Notebook
Unit objectives
IBM i


OL629.0
Notes:
There are many ways to add data to a physical file. This unit covers the copy file command.
4-2

V8.0
Student Notebook
Uempty
Adding data to a physical file

IBM i
DATA ENTRY
CPYF
PROGRAM
Figure 4-2. Adding data to a physical file
OL629.0
Notes:
Different methods can be used to add data to a physical file:
An interactive data entry program can be used to add data to the file
The data file utility can be used to add data to the file
A batch program can select data to be placed in the file
The CPYF command can be used to place data in the file
This unit covers the CPYF command. The other methods will be covered in more detail in a
later unit.
Adding data to a physical file is one of the functions that can be performed by the CPYF
command. Other functions are:
Load and merge data from another source, for example, application migration or batch
take-on
Extract sample data from a large file for testing purpose
Take a back-up copy prior to some maintenance or test run
Produce a raw list of the data for debugging purpose
Convert data to another file format

4-3
Student Notebook
Copy file review

IBM i
CPYF FROMFILE(
FROMMBR
) TOFILE(
member name
generic name
*ALL
*FIRST
MBROPT
*ADD
*REPLACE
CRTFILE
*YES
*NO
TOMBR
member name
*FROMMBR
*FIRST
If TOMBR does not exist, it

is added to the database file.
FMTOPT
*NONE
*NOCHK
*CVTSRC
*MAP
*DROP

Figure 4-3. Copy file review
OL629.0
Notes:
Member Option (MBROPT) indicates whether the records being copied into the file should
append to the end of the existing records (*ADD) or clear out and replace all existing
records in the file (*REPLACE).
This command greatly simplifies changes to field sizes after the files are created.
Data resides in one or more members of a physical file, and CPYF supports the copying of
data from members, to members.
A member name of *FIRST refers to the oldest member in the file, not the first member in a
stored list of member names.
Format Option (FMTOPT) is required only when the from-file does not EXACTLY match the
to-file.
*MAP causes the records to be brought across and moved into the to-file on a
field-by-field basis. Field size and/or type changes will be handled automatically.
If the to-field is numeric, the data is aligned on the decimal position defined in the
to-field. The decimal position in the from-file may be defined or implied.
4-4

V8.0
Student Notebook
Uempty
If the to-field is character, the data is aligned on the leftmost position of each field. The
from-field may be truncated or padded with blanks to fit the to-field.
If fields exist in the to-file that are not present in the from-file, they are set to one of the
following:
- The default value indicated by the DFT value in the DDS for the to-field
- Blanks for character fields
- Zeros for numeric fields
- Current date/time for date/time fields
- Null values for null capable fields
*DROP will prevent the CPYF function from terminating if the from-file contains fields
that are not present in the to-file.
*CVTSRC is used to copy between database files, from a source file to a data file, or
from a data file to a source file. It is valid only when the from-file and to-file are different
types (source and data). The file type conversion is done as follows:
- If the to-file is a data file, the from-file sequence number and date fields are dropped,
and the source data part of each from-file record is copied to the to-file as described
in the help text for the FMTOPT(*NOCHK) parameter of the CPYF command.
- If the to-file is a source file, sequence number and date fields are appended, and the
from-file record data is copied to the source data part of each to-file record as
described in the help text for the FMTOPT(*NOCHK) parameter of the CPYF
command. The SRCOPT and SRCSEQ parameters are used to control the sequence
numbers created in the to-file. Null values are ignored, and no conversion of
date/time data occurs.

4-5
Student Notebook
Copy file: FROMMBR and TOMBR

IBM i
Default
FROMMBR
*FIRST
MBR3
*ALL
TOMBR
*FIRST
*FIRST
*FIRST
*ALL
*FROMMBR
FROMFILE
MBR1
TOFILE
MBR2
MBR1
MBR3
MBR1
MBR1
MBR2
MBR2
MBR3
MBR3
MBR3

Figure 4-4. Copy file: FROMMBR and TOMBR
OL629.0
Notes:
The member names represent the content of the respective members.
4-6

V8.0
Student Notebook
Uempty
Copy file: CRTFILE and MBROPT

IBM i
TOFILE
Before
After
NONE
CRTFILE (*YES)
FROMFILE
MBROPT (*ADD)
MBROPT (*REPLACE)

Figure 4-5. Copy file: CRTFILE and MBROPT
OL629.0
Notes:
If you are copying data to a nonexistent file, the CRTFILE parameter of CPYF must be
*YES. A physical output file will be created.
If you are copying data to an existing database file, the MBROPT parameter must always be
*ADD or *REPLACE. Any other value will result in an error message.

4-7
Student Notebook
Copy file: FROMRCD and TORCD

IBM i
102
106
103
105
103
108
105
108
FROMRCD(3)
TORCD(5)

Figure 4-6. Copy file: FROMRCD and TORCD
OL629.0
Notes:
The FROMRCD and TORCD parameters are used to selectively copy based on relative record
position within the file.
4-8

V8.0
Student Notebook
Uempty
Copy file: FROMKEY and TOKEY

IBM i
102
106
103
105
103
106
105
108
FROMKEY(103)
TOKEY(106)

Figure 4-7. Copy file: FROMKEY and TOKEY
OL629.0
Notes:
Another form of selective copying is available using record keys. You can copy all records
within (and including) a range of keys.

4-9
Student Notebook
Copy file: NBRRCDS

IBM i
NBRRCDS(50)
/*
Number of Records to Copy
*/
Instead of
TORCD
-orTOKEY

Figure 4-8. Copy file: NBRRCDS
OL629.0
Notes:
NBRRCDS is another form for selective copying of data. You specify NBRRCDS for n
records. This parameter can be useful when you want to create test data.

V8.0
Student Notebook
Uempty
Copy file: INCCHAR

IBM i
102
SMITH
106
DAVIS
106 DAVIS
105 ST. DAVIDS
103
SAMPSON
105
ST. DAVIDS
108
DAVIDSON
108 DAVIDSON
INCCHAR(NAME 1 *CT
DAV)

Figure 4-9. Copy file: INCCHAR
OL629.0
Notes:
Another form of selective copying is the ability to include records based upon a character
test. This example includes all records where, starting in position 1 of the NAME field, the
field contains (*CT) the characters DAV.

4-11
Student Notebook
Copy file: INCREL

IBM i
102
59
106
160
103
175
105
23
108
132
106
160
103
175
INCREL((*IF AMT *GT 150))

Figure 4-10. Copy file: INCREL
OL629.0
Notes:
Another form of selective copying is to include records based upon a relation test.
In this example, records should be included IF the field AMT is greater than 150.
This is the most common method of copying records from one file to another. A relational
test is performed based on the entire value of one or more fields.
This provides a basic but powerful query facility.

V8.0
Student Notebook
Uempty
Copy file: FMTOPT(*DROP *MAP)

IBM i
FMTOPT(*DROP)
FROM
FLDA
TO
FLDA
FLDB
FLDC
FLDC
FLDD
FLDD
FMTOPT(*MAP)
FROM
TO
FLDA
FLDB
FLDC
FLDD
10
12
FLDB
FLDC
FLDD
FLDA
7
15

Figure 4-11. Copy file: FMTOPT(*DROP *MAP)
OL629.0
Notes:
The *MAP and *DROP parameters give CPYF the power to reformat database files when
field sizes must be changed, such as zip (postal) codes from 5 to 9 positions, or BALDUE
from 5,2 to 7,2, or when fields need to be dropped from the record format.
If copying to a file having a format with fields (same field names) of a different length, *MAP
must be specified, else truncations, paddings, or exceptions could occur. CPYF does a
field-by-field copy. *MAP will decimally align numbered fields and left justify alphanumeric
fields when mapping data to a new format where the fields have different lengths. *DROP
must be specified if the target file/format does not contain all the fields present in the
source file/format.
FMTOPT(*DROP): Must be specified if any of the field names in the from-file record
format do not exist in the to-file format.
FMTOPT(*MAP): Causes fields with the same name in the from-file and to-file record
formats to be copied and any fields in the to-file that do not exist in the from-file format
to be set to the default values specified on the DFT keyword for the data description

4-13
Student Notebook
specification (DDS) of the to-file, zero for numeric, blanks for character fields, current
date/time for date/time fields, or null value for null-capable fields.
If *DROP is specified, *MAP can also be specified. When *DROP is specified, all the field
names that exist in both record formats must have the same attributes and relative
positions in the from-file and to-file record formats, or *MAP must also be specified.

V8.0
Student Notebook
Uempty
Copy file: FMTOPT(*NOCHK)

IBM i
FROM
TO

Figure 4-12. Copy file: FMTOPT(*NOCHK)
OL629.0
Notes:
When FMTOPT(*NOCHK) is specified, if the record formats of the database files are
different, the copy operation continues despite the differences. The record data is copied
directly (left to right) from one file to the other, byte-by-byte, without regard to field
boundaries or data type.

4-15
Student Notebook
Creating test data using a DB copy

IBM i
CPYF
FROMFILE(PAYLIB/EMP1)
TOFILE(TESTLIB/EMP1T)
FROMMBR(*FIRST)
TOMBR(*FIRST)
MBROPT(*REPLACE)
Required keywords for database to database copy:

FROMFILE - TOFILE - MBROPT

Figure 4-13. Creating test data using a DB copy
OL629.0
Notes:
Write down below what you think this example is doing:
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________

V8.0
Student Notebook
Uempty
Create a file not previously defined

IBM i
CPYF
FROMFILE(BILL/CUSTOMER)
TOFILE(QGPL/CUSTOMER)
CRTFILE(*YES)
INCREL((*IF CRDLMT *GE
10000))

Figure 4-14. Create a file not previously defined
OL629.0
Notes:
Example of CRTFILE(*YES).

4-17
Student Notebook
View data in file

IBM i
View data in file by means of:

DSPPFM FILE (lib-name/file-name)
RUNQRY QRYFILE (lib-name/file-name)
STRQRY
STRDFU
STRSQL
Figure 4-15. View data in file
OL629.0
Notes:
The Display Physical File Member command (DSPPFM) allows you to look at the data in the
file in character or hexadecimal format. This is a developer tool, not an end-user function.
For a more readable form, use the following:
RUNQRY
STRQRY
STRDFU
STRSQL
System i Navigator
User-written application program
The different ways of accessing data will be covered in more detail in a later unit.

V8.0
Student Notebook
Uempty
Checkpoint
IBM i
1.
The format option (FMTOPT) parameter of the CPYF command is (blank) when
the from-file does not exactly match the to-file.
a. Optional
b. Required
c. Specified as *NOCHK
d. Not needed
2.
Which of the following methods can be used to add data to a physical file?
a. The CPYF command.
b. A data file utility.
c. An interactive program.
d. All of the above.
3.
The CPYF command can be used to:

a. Extract sample data from a large file for testing purposes.
b. Produce a list of specific data from a file.
c. Convert data to another file format.
d. Perform all of the above.
OL629.0
Notes:

4-19
Student Notebook
Lab exercise
IBM i
Adding data to physical files

(CPYF)

OL629.0
Notes:

V8.0
Student Notebook
Uempty
Unit summary
IBM i


OL629.0
Notes:

4-21
Student Notebook

V8.0
Student Notebook
Uempty
Unit 5. Field reference file

Physical files are the heart of the DB2 for i database. Field reference
files are a useful tool for simplifying the definition of physical files on
the IBM i. Field reference files are (usually) physical files that hold no
application data. This unit states the importance of using a field
reference file.

Recognize the benefits of field referencing in DB2 for i
Code the DDS and create a field reference file

Accountability
Machine exercises

5-1
Student Notebook
Unit objectives
IBM i
After completing this unit, you should be able to


OL629.0
Notes:
5-2

V8.0
Student Notebook
Uempty
Field reference file

IBM i

Figure 5-2. Field reference file
OL629.0
Notes:
Field referencing simplifies the process of application design and coding. Individual fields
within an externally described file can be defined as being like another field. The other field
may be described in the same or (better) in a different file called a field reference file.
A field reference file is a physical file referenced in other physical files as the place where
one or more fields are defined. Ideally, a field reference file is one without a data member
or key access. It serves as a data dictionary.
A field reference file on the IBM i is important because it does the following:
It enforces the naming convention.
It reduces programmer workload (define once, use often).
It defines in one place all data elements in the application for all users.

5-3
Student Notebook
Use field reference file for new file definitions
A
A
A
A
A
A
A
A
A
A
A
DECIMAL POS
DATA TYPE
LENGTH
NAME
REFERENCE
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS
UNIQUE
CRSFMT
CRSID
CRSDSC
CRSPRC
CRSDUR
INSID
CRSID
R
R
R
R
R
No need to code anything here.

Field definitions come from the
field reference file.
Simplify coding.
Standardize field definitions.

Figure 5-3. Use field reference file for new file definitions
OL629.0
Notes:
A field reference file is used like a data dictionary.
The REF keyword identifies the (externally described) file we wish to refer to. The library
name may be omitted; *LIBL is assumed. Only one REF keyword can be coded.
To provide further flexibility for additional reference files or differing field names, the field
level REFFLD keyword can be used as well as (or instead of) the REF keyword.
A field we wish to define like another in the physical file is marked with an R in the
REFERENCE column. Both fields are assumed to have the same name.
5-4

V8.0
Student Notebook
Field reference file supplies field definitions at file

creation
A
A
A
A
A
A
A
A
A
A
DECIMAL POS
DATA TYPE
NAME
LENGTH
REFERENCE
NAME TYPE
IBM i
FORM TYPE
Uempty
FUNCTIONS
*FILE-PF
RDBLIB/EDUCFLDREF
UNIQUE
CRSFMT
CRSID
CRSDSC
CRSPRC
CRSDUR
INSID
*FILE-PF
REFFLD(VNDLIB/VNDREF)
R
R
R
R
R
VNDLIB/VNDREF
*FILE
CRT
( )
PF
DSPF
PRTF
ICFF
MYFILE
FILE(MYFILE)

Figure 5-4. Field reference file supplies field definitions at file creation
OL629.0
Notes:
Use the REFFLD field level keyword to refer to a field under one of these following
conditions:
When the name of the referenced field is different from the name in positions 19
through 28
When the name of the referenced field is the same as the name in positions 19 through
28, but the record format, file, or library of the referenced field is different from that
specified with the REF keyword
When the referenced field occurs in the same DDS source file as the referencing field
The format of the keyword is
REFFLD([record-format-name/]referenced-field-name [{*SRC |
[library-name/]database-file-name}])
The referenced-field-name is required even if it is the same as the name of the field
being defined. Use the record-format-name when the referenced file contains more
than one record format. Use *SRC (rather than the database-file-name) when the field

5-5
Student Notebook
name being referred to is in the same DDS source file as the field being defined. *SRC
is the default value when the database-file-name and the library-name are not specified.
When you refer to a field in the same DDS source file, the field being referred to must
precede the field being defined.
Specify the database-file-name (with its library-name, if necessary) to search a
particular database file.
An R must be in position 29. Some keywords specified with the field being referred to are
not included on the field being defined.
If you specify REF at the file level and REFFLD at the field level in the same DDS source
file, the REFFLD specification is used. The search sequence depends on both the REF and
REFFLD keywords.
The field reference file is only referred to at file creation time.
If a field is changed in the field reference file, the field reference file must be recreated. The
change will not be propagated to the other files unless they are recreated also.
5-6

V8.0
Student Notebook
Uempty
How do you structure a field reference file?

IBM i
Code fields in alphabetic sequence.

Code fields by record format (use comments).

Figure 5-5. How do you structure a field reference file?
OL629.0
Notes:
These are just two suggestions for designing your field reference file. Much will depend on
your local applications conventions and standards.

5-7
Student Notebook
Fields in alphabetical sequence

IBM i
R DATAFLDS
CLASNO
COURNO
DABSNT
DESC
DURATN
4
5
3
30
3
EDCNTR
FGRADE
INSNAM
INSTNO
PRICE
30
3
30
7
3
STATUS
STRDA
STRMO
STRYR
STUCMP
STUNAM
STUNO
2
2
2
30
30
7
COLHDG('CLASS' 'NUMBER')
COLHDG('COURSE' 'NUMBER')
COLHDG('DAYS' 'ABSENT')
COLHDG('COURSE' 'DESCR')
COLHDG('DURATION')
1
1
RANGE(0.5 5.0)
0
0
0
0
0
0
COLHDG('EDUCATION' 'CTR')
COLHDG('FINAL' 'GRADE')
COLHDG('INSTR.' 'NAME)
COLHDG('INSTR.' 'NO')
COLHDG('COURSE' 'PRICE)
EDTWRD('0.')
COLHDG('ENROLL' 'STATUS')
VALUES('PEND' 'CONF' 'CAN
'CANL')
COLHDG('START' 'DAY')
COLHDG('START' 'MO')
COLHDG('START' 'YR')
COLHDG('EMPLOYED' 'BY')
COLHDG('STUDENT' 'NAME')
COLHDG('STUDENT' 'NO.')

Figure 5-6. Fields in alphabetical sequence
OL629.0
Notes:
Sequencing the fields alphabetically makes it easier to find a particular field definition;
however, unless extensive comments are included, we have no information to tell us which
files employ a particular field. Refer to the unit about maintenance for more information
about finding where a given field is used.
5-8

V8.0
Student Notebook
Uempty
Fields by record format

IBM i
R DATAFLDS
******************COURSE MASTER RECORD*********************
COURNO
DESC
PRICE
DURATN
30
3
3
COLHDG('COURSE' 'NUMBER')
COLHDG('COURSE' 'DESCR.')
0
COLHDG('COURSE' 'PRICE')
1 COLHDG('DURATION')
RANGE(0.5 5.0)
******************CLASS MASTER RECORD***********************

CLASNO
EDCNTR
STRMO
STRDA
STRYR
INSTRNO
4
30
2
2
2
7
0
0
0
0
COLHDG('CLASS' 'NUMBER')
COLHDG('EDUCATION' 'CTR')
COLHDG('START' 'MO')
COLHDG('START' 'DAY')
COLHDG'START' 'YR')
COLHDG('INSTR.' 'NO')
EDTWRD('0.')
******************STUDENT/CLASS MASTER RECORD***********

STATUS
DABSNT
FGRADE
3
3
COLHDG('ENROLL' 'STATUS')
VALUES('PEND' 'CONF' 'CAN' 'CANCL')
COLHDG('DAYS' 'ABSENT')
COLHDG('FINAL' 'GRADE')
*******************STUDENT MASTER RECORD******************

STUNO
STUNAM
STUCMP
7
30
30
COLHDG('STUDENT' 'NO.')
COLHDG('STUDENT' 'NAME')
COLHDG('EMPLOYED' 'BY')

Figure 5-7. Fields by record format
OL629.0
Notes:
This layout provides useful information about the field usage. There is a problem if a
specific field is used in more than one file. It is not possible to have duplicate definitions in
the reference file. A solution is to comment out the second (and any subsequent) definition
for the same field.
Of course, if unique field names are used across the entire application, this problem does
not arise; however, this may complicate application maintenance activities.
Use comments to document naming standards, applications to be supported, and so forth.
In DDS, comments (documentation) are defined by putting an asterisk (*) in column 7.
A field reference file should be used to do the following:
Document the naming standards
Document the abbreviations to be used
Including the above information in the field reference file will make your database much
easier to use.

5-9
Student Notebook
Field reference file keywords

IBM i
All PF keywords are valid.

Pay particular attention to field level keywords.
Validity checking keywords
CHECK
CHKMSGID
CMP
COMP
RANGE
VALUES
Text definition keywords

COLHDG
TEXT
Editing keywords
EDTCDE
EDTWRD
ALIAS
ALWNULL
CCSID
DATFMT
DATSEP
DFT
FLTPCN
REFSHIFT
TIMEFMT
TIMSEP
VARLEN

Figure 5-8. Field reference file keywords
OL629.0
Notes:
Many physical file keywords can be defined for a field reference file so that they may be
employed when creating (by referencing) display or printer files. Remember a field
reference file is a physical file, so all physical file keywords are valid.

V8.0
Student Notebook
Uempty
Why use field reference files?

IBM i
Reduces effort in coding DDS

Ensures consistent use of field attributes throughout physical,
logical, display, printer, and ICF files
Simplifies propagating a change to a field throughout the
database

Figure 5-9. Why use field reference files?
OL629.0
Notes:
Using field reference files helps ensure consistency in naming conventions and attributes
for data fields throughout the database. It also simplifies the initial coding and the
maintenance of your database fields as well as input and output fields for display and
printer files.

5-11
Student Notebook
Checkpoint
IBM i
1. True or False: A field reference file is a physical file

referenced in other physical files as the place where one or
more fields are defined.
2. True or False: A field reference file cannot have a data
member nor can it have keyed access.
3. True or False: Only one file level REF keyword can be
coded.

OL629.0
Notes:

V8.0
Student Notebook
Uempty
Lab exercise
IBM i
IBM i field reference file

OL629.0
Notes:

5-13
Student Notebook
Unit summary
IBM i
Having completed this unit, you should be able to


OL629.0
Notes:

V8.0
Student Notebook
Uempty
Unit 6. Non-join logical files

Logical files add tremendous flexibility to the user's access to the data
in the physical files. This unit describes how to code and implement
the following relational database operators:
Sequence (row sequence)
Selection (row selection)
Projection (column selection)
Union (rows from multiple tables)

Describe the use of an IBM i logical file to implement the following
- Relational database operators: sequence, selection, projection,
and union
- Access path sharing
- Format sharing
- Dynamic record selection
Create logical files to apply the concepts and principles being
taught

Accountability
Machine exercise

6-1
Student Notebook
Unit objectives
IBM i

Describe the use of an IBM i logical file to implement the
following
Relational database operators: sequence, selection, projection, and
union
Access path sharing
Format sharing
Dynamic record selection

taught

OL629.0
Notes:
6-2

V8.0
Student Notebook
Uempty
A logical file
IBM i
12
SAM
12
15
DOT
47
91
BOB
25
47
JOY
32
JOE
21
43
DON
68
21
BEV
66
DEE
97
12
48
PAT
43
99
RAY
51
01
BEA
85
4
2
5
1 BEA
2 BEV
Physical
file
4 DOT
5 JOY
7 DEE
7
5
33
A logical file uses the relational operations to present

the physical data in a desired form.
Figure 6-2. A logical file
OL629.0
Notes:
A logical file can be used to provide different views of the data to meet processing needs
like the following:
Identify female students (SEX=F)
List students alphabetically by name
Show student names only

6-3
Student Notebook
Non-join logical file keywords

IBM i
2. Record level
FORMAT*
PFILE
TEXT*
1. File level
ALTSEQ
DYNSLT
FCFO*
FIFO*
LIFO*
REFACCPTH
UNIQUE*
5. Select/omit level
ALL
CMP
COMP
RANGE
VALUES
4. Key level
ABSVAL*
DESCEND*
DIGIT*
NOALTSEQ*
SIGNED*
UNSIGNED*
ZONE*
3. Field level
ALIAS*
CHECK*
CHKMSGID
CMP*
COLHDG*
COMP*
CONCAT
DATFMT*
DATSEP*
EDTCDE*
EDTWRD*
FLTPCN*
RANGE*
REFSHIFT*
RENAME
SST
TEXT*
TIMFMT*
TIMSEP*
TRNTBL
VALUES*
VARLEN*
* Keyword previously described for physical files

Figure 6-3. Non-join logical file keywords
OL629.0
Notes:
Here is a listing of non-join logical file keywords. Keywords with an asterisk (*) were seen
with physical files. We will limit our discussion to those keywords of practical use.
6-4

V8.0
Student Notebook
Uempty
File-level keyword: REFACCPTH
A
A
A
A
A
A
A
A
A
A
A
A
USAGE (O, I, B, H)
DECIMAL
POSITIONS
NAME
REFERENCE (R)
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS
REFACCPTH(RDBLIB/STUCLAS)
PFILE(STUCLAS)
R
STUCLS
Access path information is

copied from another logical or
physical file.

Figure 6-4. File-level keyword: REFACCPTH
OL629.0
Notes:
The REFACCPTH file-level keyword is used to specify that the access path information is to
be copied from another logical or physical file.
The access information includes the following:
Key information
Select/omit logic
Alternate collating sequence information
Dynamic select information
Key sequencing information (FCFI, FIFO, LIFO, and UNIQUE)
The format of the keyword is
REFACCPTH([library-name/]database-file-name)
This keyword copies the DDS coding for access path information into one file from another
file. In all probability the two files would end up sharing the actual access path. If you are
wondering under what circumstances they would not share the same access path, suppose
that there were two physical files of the same name in different libraries. Two logical files
could have the same coding for their access paths but depend on different physical files.

6-5
Student Notebook
Record-level keyword: PFILE (1 of 6)

IBM i
PFILE([library-name/]physical-file-name [.32])
PFILE identifies the PF containing the data
PFILE used for example in the following cases:
Single physique file
Union of records of two physical files
Multiformat logical files

Figure 6-5. Record-level keyword: PFILE (1 of 6)
OL629.0
Notes:
Use the PFILE record-level keyword to identify the physical files containing the data to be
accessed through the record format you are now defining.
Up to 32 physical file names can be specified on PFILE keywords in a logical file.
PFILE is required on every record format in a simple or multiple format logical file.
6-6

V8.0
Student Notebook
Uempty
A
A
A
A
A
A
A
A
A
A
A
A
USAGE (O, I, B, H)
DECIMAL
POSITIONS
DATA
TYPE (A, X, N, Y, S)
NAME
LENGTH
REFERENCE (R)
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS
SINGLE PHYSICAL FILE ALL FIELDS

R
K
PFILE (RDBLIB/COURSE)
CRSFMT
CRSPRC
Same format name, CRSFMT, for PF and LF.

LF uses all PF fields.
New record sequence: CRSPRC

OL629.0
Notes:
This logical file is performing the sequencing relational operator.
The PFILE keyword defines the physical file which contains the data that is to be
processed through this view.
Using the same format name as the physical file and defining no fields causes the file
format to be shared.
We would not normally specify the library name (defaults to *LIBL). As applications develop
and evolve, files will be moved or copied to different libraries (for example, from test to
production). Hard-coding the library name results in a loss of flexibility, requires more
maintenance effort, and may cause errors.

6-7
Student Notebook
A
A
A
A
A
A
A
A
A
A
A
A
USAGE (O, I, B, H)
DATA
DECIMAL
POSITIONS
NAME
LENGTH
REFERENCE (R)
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS
SINGLE PHYSICAL FILE SOME FIELDS

PFILE(RDBLIB/COURSE)
R
COUINQ
CRSDSC
CRSPRC
CRSDSC
Different format for LF: COUINQ

COUINQ only has two of the PF fields.
New record sequence: CRSDSC

OL629.0
Notes:
This logical file is performing the sequencing and projection relational operators.
You may choose any valid format name when you define the fields in the format.
The named fields are the only ones that can be seen and changed in a program using this
view.
6-8

V8.0
Student Notebook
Uempty
A
A
A
A
A
A
A
A
A
A
A
A
A
A
USAGE (O, I, B, H)
DECIMAL
POSITIONS
DATA
LENGTH
NAME
REFERENCE (R)
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS
UNION OF RECORDS OF TWO

PHYSICAL FILES
R
CLSHIST
K
K
K
CRSID
CLSLOC
CLSMON
CLSDAY
CLSYR
CLSYR
CLSMON
CLSDAY
PFILE(CLASS91 CLASS92)
Includes only the named fields from

all records in both 1991 and 1992
files.

OL629.0
Notes:
This example is a union of two files with selected fields. Only fields that are common to all
of the PFILEs may be named. Up to 32 physical files can be named in a union.
Each record will contain data from only one physical file record. When defining a union (two
or more physical files are named), at least one key field must be specified for the file.
Union is used when there is a need to merge data from two entirely different files, for
example, two customer master files from two separate applications which need to merge to
show common fields.

6-9
Student Notebook
A
A
A
A
A
A
A
A
A
A
A
A
A
A
USAGE (O, I, B, H)
DECIMAL
POSITIONS
DATA
LENGTH
NAME
REFERENCE (R)
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS
UNION OF RECORDS OF TWO

PHYSICAL FILES
R
K
K
K
CLSREC1
CLSYR
CLSMON
CLSDAY
PFILE(CLASS91 CLASS92)
CLSREC1 must be the format of the first

physical file.

OL629.0
Notes:
No data fields are named in this union, so all the fields are included.
The format (CLSREC1) from physical file CLASS91 defines the fields to be included.
The logical file create command (CRTLF) will only look in the first file named to see if the
format exists.
All fields named in this format must exist in the other (CLASS92) file.
Use this solution when you have, for example, current and history (archive) files with
exactly the same format. You may need to produce some analysis based on the
information you have accumulated over time, requiring a merge of several physical files.

V8.0
Student Notebook
Uempty

USAGE (O, I, B, H)
DECIMAL
POSITIONS
NAME
LENGTH
DATA
REFERENCE (R)
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS
MULTIPLE RECORD FORMATS

A
A
A
A
A
A
A
A
A
A
A
A
A
R
K
CRSFMT
CRSID
R
K
K
CLSFMT
CRSID
CLSID
PFILE (COURSE)
PFILE (CLASS)
Includes all records from the file COURSE

and the file CLASS as if they had been
merged.

OL629.0
Notes:
This is a logical file with multiple different record formats. Both files must have at least one
common key field for sequencing.
This is not a normal relational database form but an extension for compatibility with
non-database systems.
To the program, this is a hierarchical relationship with a header (primary) record, followed
by some detail (secondary) records, followed by another header, and so forth.
Use this solution when you want to merge data from two dissimilar files, such as order
header and order detail. This logical file can present the data in such a way as to make the
production of invoices much simpler. For example, header information followed by
associated detail information and so forth.

6-11
Student Notebook
Field-level keywords
IBM i
ALIAS CHECK CHKMSGID CMP COMP

CONCAT* DATFMT DATSEP EDTCDE EDTWRD
FLTPCN RANGE REFSHIFT RENAME*
SST* TIMFMT TIMSEP TEXT
TRANTBL*VALUES
VARLEN
* Not valid for physical files.

Figure 6-11. Field-level keywords
OL629.0
Notes:
All of the listed keywords are valid on a DDS logical file.
Only the emphasized (bold) keywords will affect the data as seen through the logical file.
All others are for workstation and printer functions.

V8.0
Student Notebook
Uempty
Field-level keywords: Renaming fields
A
A
A
A
A
A
A
A
A
A
A
A
A
EDCNTR
USAGE (O, I, B, H)
DECIMAL
POSITIONS
DATA
NAME
LENGTH
REFERENCE (R)
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS
RENAME(CLSLOC)
Changes name in this view to EDCNTR

CHARGE
PRICE
RENAME(PRICE)
Allows two names to reference one data storage

area

Figure 6-12. Field-level keywords: Renaming fields
OL629.0
Notes:
You can use the RENAME keyword when you want a field name in the logical record format
you are defining to be different from its corresponding physical file field name.
The format of the keyword is RENAME(physical-file-field-name)
The first example changes the name of the physical file field to a different name in the
logical file. All other characteristics of the field remain the same.
The second example causes the fields named CHARGE and PRICE in a program to refer
to the same data field on disk.
If updated, the data is moved to the physical file in the order that the fields are defined,
therefore the value of PRICE will be written to the physical file after the value of CHARGE.

6-13
Student Notebook
Field-level keywords: CONCAT and SST
A
A
A
A
A
A
A
A
A
A
A
A
A
USAGE (O, I, B, H)
DATA
DECIMAL
POSITIONS
LENGTH
NAME
REFERENCE (R)
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS
SEQDAT
CONCAT(STRYR STRMO STRDA)
PRTDAT
CONCAT(STRMO STRDA
STRYR)
Combines two or more fields from a

physical file record into a single field
in a logical file
CITY
SST(ADDRESS 1 18)
Defines a field in a logical file that

is a subset of a character or zoned
field in a physical file

Figure 6-13. Field-level keywords: CONCAT and SST
OL629.0
Notes:
The characteristics of the CONCAT keyword are the following:
Numeric fields with number of decimal places other than zero (0) cannot be used for
concatenation.
The length of the concatenated field is the sum of the lengths (digits and characters) of
the fields included in the concatenation.
With numeric fields, the sign of the right most field becomes the sign of the entire field.
Maximum result field lengths are 31 for zoned decimal and 32,740 for character (32,739
if null is allowed).
Cannot include floating point, date, time, or time stamp fields.
The fields to concatenate must be from the same physical file.
The characteristics of the SST keyword are the following:
The resulting field will always be character.
The usage of the resulting field must be input (I) only.
This keyword cannot be used on the same field with CONCAT, RENAME, or TRNTBL.

V8.0
Student Notebook
Uempty
Field-level: Changing field lengths
A
A
A
A
A
A
A
A
A
A
A
A
A
NAME
24
QUANT
COST
+2
PRICE
+4
+1
USAGE (O, I, B, H)
DECIMAL
POSITIONS
DATA
LENGTH
NAME
REFERENCE (R)
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS

Figure 6-14. Field-level: Changing field lengths
OL629.0
Notes:
You can override or change the length of the physical file field.
Fields with redefined lengths should be limited to input (I) only whenever possible.
A data field of the type binary with decimal positions greater than zero cannot be
overridden in this manner. If the size of a field is changed and the record is rewritten
(updated), mapping errors may occur.
The first example changes the length of the field NAME to 24 characters.
The second example changes the number of digits in the QUANT field to 7. The number of
digits to the right of the decimal is unchanged.
The third example increases the size of the field COST by two digits and defines three
digits to the right of the decimal.
The last example increases the size of the PRICE field by four digits and increases the
number of digits to the right of the decimal by one.

6-15
Student Notebook
Field-level: Changing data type

IBM i
Logical file data type

Physical file data Char
type
Character or
hexadecimal
Zoned
Hex
Zoned
Y
Packed
Binary
Floating
point
Date
Time
Timestamp
See note
1
See note
2
See note
2
See note
2
See note
2
See note See note

1
1
Packed
Binary
Floating point
Date
See note
6 and 7
See note See note

6
6
Time
See note
4
Timestamp
See note See note See note

2
2
3
Y
See note See note

5
5

Figure 6-15. Field-level: Changing data type
OL629.0
Notes:
A logical file can convert the data type of a physical file before presenting the data to a
program using the file.
Note 1: Valid only if the number of characters (or bytes) equals the number of digits and
the character (or hexadecimal) field is not defined as a variable length field.
Note 2: Valid only if the binary field has a decimal position of zero.
Note 3: Valid only if both fields have the same decimal position.
Note 4: The system generates the field length for you, so do not enter a length in columns
30 through 34. The length does not include the separator character.
Note 5: Valid only if the field is input only.
Note 6: You may specify a field length (columns 30 to 34) for these data types on a logical
file field. If you do not specify a length, the system will generate a default length. Valid
lengths for these data types are documented with the DATFMT keyword.
Note 7: DBCS field types are not allowed to be mapped over DATE fields.

V8.0
Student Notebook
Uempty
Key-level keywords
IBM i
Key
DESCEND
ABSVAL
UNSIGNED
DIGIT
ZONE
NOALTSEQ
Field
keywords
Same as for a physical file
Figure 6-16. Key-level keywords
OL629.0
Notes:
The usage of these seven key-level keywords in logical files is identical to their usage in
physical files.

6-17
Student Notebook
Select-/Omit-level keywords
IBM i
ALL
COMP
Select-/Omitlevel
keywords
VALUES
RANGE
Determine which physical file records have logical file access path
entries.
Figure 6-17. Select-/Omit-level keywords
OL629.0
Notes:
A select/omit field is a field in a logical file record format whose value is tested by the
system to determine if records including that field are to be used. The test is a comparison
with a constant, the contents of another field, a range of values, or a list of values, and the
record is either selected or omitted as a result of the test.
Floating point fields cannot be used for select/omit testing.
The fixed-format, hard-coded nature of DDS limits the application of record selection to
those situations where performance is an issue. DDS does not permit selection based on
variable criteria. Normally, selection would be specified dynamically at run-time within the
query tool being used, for example, SQL, OPNQRYF, Query for i5/OS. This allows much
greater flexibility.

V8.0
Student Notebook
Uempty
Select-/Omit-level keywords: Examples (1 of 2)
A
A
A
A
A
A
A
A
A
A
A
A
A
STUABS
STUGRD
AND
S
S
CRSDUR
CRSPRC
OR
STUSTS
USAGE (O, I, B, H)
DECIMAL
POSITIONS
DATA
NAME
LENGTH
REFERENCE (R)
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS
COMP(GT 0)
VALUES('UNS' 'INC')
RANGE(1 4)
COMP(LT 300)
VALUES('P' 'C')

Figure 6-18. Select-/Omit-level keywords: Examples (1 of 2)
OL629.0
Notes:
An S or O in position 17 specifies a select or omit field name.
By specifying an S or an O in column 17 of each select or omit statement, the system is
instructed to OR the statements. That is, if the first condition is met, the record is either
selected or omitted. The next select or omit condition is tested only on records that have
not yet been selected or omitted.
By specifying a blank in position 17, following a select or omit statement, the new
statement is ANDed with the select or omit statement. That is, the system will check all
records for each condition and select or omit only those records meeting all conditions.
If you do not specify the ALL keyword, the following default action is taken:
- If the last specification was select, the default is to omit all others.
- If the last specification was omit, the default is to select all others.

6-19
Student Notebook
Select-/Omit-level keywords: Examples (2 of 2)

USAGE (O, I, B, H)
DATA
DECIMAL
POSITIONS
CLSLOC
CRSID
INSID
COMP(EQ 'DAL')
VALUES('U3030' 'U3040')
COMP(EQ 531119)
O
S
CLSLOC
CRSID
INSID
COMP(NE 'DAL")
VALUES( 'U3030' 'U3040')
COMP(EQ 531119)
A
A
O
S
CLSLOC
COMP(NE 'DAL')
INSID
CRSID
COMP(NE 531119)
VALUES( 'U3030' 'U3040')
LENGTH
NAME TYPE
A
A
A
A
A
A
A
A
A
A
A
NAME
FORM TYPE
REFERENCE (R)
IBM i
FUNCTIONS

Figure 6-19. Select-/Omit-level keywords: Examples (2 of 2)
OL629.0
Notes:
The first example requires that all three conditions be met (AND).
The second example will stop if CLSLOC is not DAL and will test for CRSID and INSID if it
is DAL.
The third example will exit if CLSLOC is not DAL, will exit if INSID is not 531119, and will
only test CRSID if it failed the two omit tests.
All three perform the same function, but the third is the most efficient method (especially
when the DYNSLT file-level keyword is specified).
You can use the ALL 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 i5/OS program to select any records that do not meet any
of the other select/omit rules. Specify O in position 17 to direct the i5/OS 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.

V8.0
Student Notebook
Uempty
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.

6-21
Student Notebook
File-level keyword: DYNSLT
A
A
A
A
A
A
A
A
A
A
A
A
USAGE (O, I, B, H)
DECIMAL
POSITIONS
DATA
REFERENCE (R)
NAME
LENGTH
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS
DYNSLT
R
STUCLSFM
STUID
CLSID
STUSTS
CLSID
STUSTS
PFILE(STUCLASS)
COMP(EQ 'C')
All records are in access path

Execution time selecting/omitting
Easier for files to share access paths
Most efficient when most records are
selected

Figure 6-20. File-level keyword: DYNSLT
OL629.0
Notes:
The DYNSLT file-level keyword is used to specify dynamic record selection.
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 may be more efficient than maintaining access path information 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.

V8.0
Student Notebook
Uempty
Creating a logical file

IBM i
PFILE1
DESCRIPTION
QDDSSRC
DATA
MEMBER
DESCRIPTION
STRSEU
or
IBM CODE
LFILE1
CRTLF
FILE1
DESCRIPTION
MEMBER

Figure 6-21. Creating a logical file
OL629.0
Notes:
The steps to create a logical file are the same as for physical files.
Logical files can also have members, but the default is one (1) with the same name as the
file.

6-23
Student Notebook
CRTLF: Create logical file

IBM i
The syntax of the CRTLF command is the following:
CRTLF
FILE(*CURLIB/file-name)
SRCFILE(*LIBL/QDDSSRC)
SRCMBR(*FILE)
MBR(*FILE)
MAXMBRS(1)
DTAMBRS
*ALL
qualified-file-names (member-names)
TEXT(*SRCMBRTXT)

Figure 6-22. CRTLF: Create logical file
OL629.0
Notes:
If the source member was created with the same name as the file, all you need to enter is
the following:
CRTLF FILE(file-name)

V8.0
Student Notebook
Uempty
Checkpoint (1 of 2)
IBM i
1.
A logical file is created to implement which of the following relational database

operators:
a.
b.
c.
d.
Sequence
Selection
Format sharing
Keyed access
2.
True or False: A logical file can convert the data type of a physical file before
presenting the data to a program using the file.
3.
This logical file is performing the (blank) and (blank) operators.

R
COUINQ
CRSDSC
CRSPRC
CRSDSC
a.
b.
c.
d.
Sequencing and selection

Sequencing and projection
Union and selection
Union and projection

Figure 6-23. Checkpoint (1 of 2)
OL629.0
Notes:

6-25
Student Notebook
Checkpoint (2 of 2)
IBM i
4. True or False: A maximum number of 32 files can be named

in a union logical file.
5. True or False: When defining a union between multiple
physical files with selected fields, only the fields that are
common to all the physical files may be named.
6. True or False: You cannot change the name of a field in the
logical file from its original name in the physical file.

OL629.0
Notes:

V8.0
Student Notebook
Uempty
Lab exercise
IBM i
Logical file coding

OL629.0
Notes:

6-27
Student Notebook
Unit summary
IBM i

Describe the use of an IBM i logical file to implement the
following
Relational database operators: sequence, selection, projection, and
union
Access path sharing
Format sharing
Dynamic record selection

taught

OL629.0
Notes:
While the physical file provides the data definition to the database, it is the logical file that
gives it flexibility and function.

V8.0
Student Notebook
Uempty
Unit 7. Join logical files

This unit discusses the last database relational operator, join.

Code join logical files
Create join logical files

Accountability
Machine exercise

7-1
Student Notebook
Unit objectives
IBM i


OL629.0
Notes:
7-2

V8.0
Student Notebook
Uempty
Join logical files: Simplicity and performance

IBM i
Simplicity and performance are reached by means of the

following characteristics:
One join logical file format combines fields from multiple physical file
formats.
One HLL read > multiple reads below machine interface, which is
faster than multiple HLL reads.
Join logical files are input only.
All key fields must come from the same physical file.
Select/omit fields from any physical file.
Fields can be combined to form a new record format.
Records joined are not merged as in union.

Figure 7-2. Join logical files: Simplicity and performance
OL629.0
Notes:
A join logical file is a logical file that combines (in one record format) fields from two or more
physical files. In the record format, not all the fields need to exist in all the physical files.
Join logical files can simplify programming in HLL, especially when compared to
multiformat logical files.

7-3
Student Notebook
Join logical file (1 of 3)

IBM i
Join logical
file
Student Number
Student Name
Class Number
STUDENT
STUCLASS
Student Number
Student Number
Student Name
Class Number

Figure 7-3. Join logical file (1 of 3)
OL629.0
Notes:
A join logical file combines fields from two or more physical files in one format. Only one
record format is allowed in a join logical file. Key fields must all exist in the primary file.
7-4

V8.0
Student Notebook
Uempty

IBM i
Join logical file

235
235
440
500
729
ANNE
ANNE
DOUG
MARK
SUE
STUCLASS
STUDENT
235
440
500
729
Multiple
secondary
matches
T2000
D2020
U1001
I2050
U1010
235
235
440
500
600
729
ANNE
DOUG
MARK
SUE
T2000
D2020
U1001
I2050
S6020
U1010
Extra secondary
OL629.0
Notes:
The STUDENT and STUCLASS files are joined on the Student Number field.
Since Anne's number (235) is matched twice in the secondary file, she has multiple records
in the join file.
Student 600 in the STUCLASS file is an unmatched secondary record and does not appear
in the join logical file.

7-5
Student Notebook
A
A
A
A
A
A
A
A
A
A
A
A
A
JOINREC
USAGE (O, I, B, H)
DECIMAL
POSITIONS
DATA
LENGTH
NAME
REFERENCE (R)
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS
JFILE(STUDENT STUCLASS)
JOIN(STUDENT STUCLASS)
JFLD(STUID STUID)
STUID
STUNM
CLSID
JREF(STUDENT)
STUID
Character fields may have different lengths.

Numeric fields must have the same length,
type, and decimal positions or be redefined
to do so.
OL629.0
Notes:
JFILE replaces the PFILE keyword used in non-join logicals. You must specify at least two
physical files. The first one named is the primary file. Use this record level keyword to
identify the physical files containing the data to be accessed through the join logical file you
are defining.
A J in column 17 identifies the start of a join specification.
JOIN identifies which two files are joined by these specifications (if only two files are to be
joined, this keyword is optional). You can use file names or relative file numbers to indicate
which files are to be joined. You must specify a relative file number if the same file is
specified more than once on the JFILE keyword. If you specify file names, you must select
files that you have specified only once on the JFILE keyword. On each JFILE keyword,
the from-file must occur before the to-file.
JFLD identifies the join fields that link the files named with the JOIN keyword. These fields
must have the same attributes.
7-6

V8.0
Student Notebook
Uempty
Fields in a join logical file must be uniquely identified. The JREF keyword allows you to
specify which file this field is to come from when the same name exists in more than one
physical file.
All of the field, key, and select/omit level keywords from non-join logical files are allowed on
join logical files.
Note the J entry in the name type column. It starts a new set of join specifications. There
will be a set of join specifications for each pair of physical files being joined. The J only
appears on the first line of the set. It does not appear on every line.

7-7
Student Notebook
Multiple secondary matches case (1 of 2)

IBM i
Use JDUPSEQ
to control sequence
Join logical file

235
235
440
729
STUDENT
235 ANNE
440 DOUG
729 SUE
ANNE
ANNE
DOUG
SUE
D2020
T2000
U1001
U1010
JDUPSEQ(CLSID)
STUCLASS
235
235
440
729
600
T2000
D2020
U1001
U1010
S6020

Figure 7-6. Multiple secondary matches case (1 of 2)
OL629.0
Notes:
The program performs a read to get each join logical file (JLF) record containing the
student number, the student name, and the course name.
The IBM i reads two records to supply the data for each of the program reads.
Multiple secondary matches result in multiple join records, sequenced by the JDUPSEQ
keyword (optional).
Unmatched secondaries (600 S6020) do not result in a join record.
Note, with an inner join, unmatched primaries (all are matched in this example) also do not
result in a join record.
JDUPSEQ can be used 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.
7-8

V8.0
Student Notebook
Uempty
Multiple secondary matches case (2 of 2)
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
JOINREC
USAGE (O, I, B, H)
DECIMAL
POSITIONS
DATA
NAME
LENGTH
REFERENCE (R)
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS
JFILE(STUDENT STUCLASS
JFLD(STUID STUID)
JDUPSEQ(CLSID)
STUID
STUNM
CLSID
K
JREF(STUDENT)
STUID

Figure 7-7. Multiple secondary matches case (2 of 2)
OL629.0
Notes:
JDUPSEQ controls the sequence of records with duplicate join fields when your program
reads a join logical file.
In this example, duplicates will be sequenced on CLSID.

7-9
Student Notebook
Missing secondary records case (1 of 3)

IBM i
Default result records omitted

Terminology:
Natural join
Matching join
Inner join
Join logical file

235
440
729
ANNE T2000
DOUG U1001
SUE
U1010
STUCLASS
STUDENT
235
440
500
729
ANNE
DOUG
MARK
SUE
235
440
729
T2000
U1001
U1010

Figure 7-8. Missing secondary records case (1 of 3)
OL629.0
Notes:
The default is to omit records in the join logical file when there is no matching secondary
record. This is called the inner join. In other words, the inner join returns only the records
from each file that have matching values in the join fields. Any records that do not have a
match between the files will not appear in the result logical file.

V8.0
Student Notebook
Uempty

IBM i
JDFTVAL Include records

Supply default values
Join logical
file
235
440
500
729
STUDENT
235
440
500
729
ANNE
DOUG
MARK
SUE
ANNE
DOUG
MARK
SUE
T2000
U1001
bbbbb
U1010
JDFTVAL
blank
zero
DFT(value)
STUCLASS
235
440
729
T2000
U1001
U1010

OL629.0
Notes:
Use the JDFTVAL keyword in a join logical file so the system provides default values for
fields when a join to a secondary file does not produce any records.
JDFTVAL is valid only for join logical files. This keyword has no parameters.
If you specify JDFTVAL, your program retrieves records for which a secondary file does not
have a corresponding record. If you do not specify JDFTVAL, a record in the primary file for
which there is no corresponding record in a secondary file is skipped.
JDFTVAL supplies values of zero, blank, or DFT(value) for fields from missing secondary
records.
This is also called a left outer join.

7-11
Student Notebook

IBM i
A
A
A
A
A
A
A
A
A
A
A
A
A
A
JOINREC
USAGE (O, I, B, H)
DECIMAL
POSITIONS
DATA
LENGTH
NAME
REFERENCE (R)
NAME TYPE
FORM TYPE
JDFTVAL Include Records, Supply Default Values
FUNCTIONS
JFLD(STUID STUID)
STUID
STUNM
CLSID
STUID
JREF(STUDENT)

OL629.0
Notes:
JDFTVAL coded at the file level causes a left outer join which provides at least one join
record for every primary record.
In other words, the left outer join returns values for all of the rows from the primary file (the
file on the left) and the values from the secondary file for the records that match. Any
records that do not have a match in the secondary file will return the JDFTVAL value for all
columns from the secondary file.
JDFTVAL is all that is needed to specify a left outer join as opposed to an inner join.

V8.0
Student Notebook
Uempty
Join field does not have to be in resulting format (1 of 2)

IBM i
Join logical
file
ANNE
DOUG
MARK
SUE
T2000
U1001
I2050
U1010
STUDENT
235
440
500
729
ANNE
DOUG
MARK
SUE
STUCLASS
235
440
500
729
T2000
U1001
I2050
U1010

Figure 7-11. Join field does not have to be in resulting format (1 of 2)
OL629.0
Notes:
The student number field is used to join these two physicals, but it is removed from the
user's view.
Any field in the primary file could have been chosen as the key for the file.
In this and all other join logical files, any field or fields in any of the physical files could be
used for selecting or omitting records from the view.

7-13
Student Notebook
Join field does not have to be in resulting format (2 of 2)

USAGE (O, I, B, H)
DECIMAL
POSITIONS
DATA
LENGTH
NAME
REFERENCE (R)
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
JOINREC
JOIN(1 2)
JFLD(STUID STUID)
STUID
STUNM
CLSID
K
JREF(1)
STUNM

Figure 7-12. Join field does not have to be in resulting format (2 of 2)
OL629.0
Notes:
A field can be used to join physical files but not appear in the join logical file if you want to
prevent the user's seeing it.
The field is coded in the normal manner for joining.
An N is coded in column 38 specifying that this is neither an input nor an output field and
will not appear in the join logical file. The field can be used as a join field without being
included as a field in the join logical file.
If you specify numbers (in this case JOIN(1 2) or JREF(1)), they correspond to the files
specified on the JFILE keyword. The following are the 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.

V8.0
Student Notebook
Uempty
More than one field to join files (1 of 2)

IBM i
Join logical
file
Part number
Color
Price
Quantity on hand
PF1
Part number
Color
Price
Vendor
PF2
Part number
Color
Quantity on hand
Warehouse

Figure 7-13. More than one field to join files (1 of 2)
OL629.0
Notes:
PF1 and PF2 are joined based on the combination of two join fields.

7-15
Student Notebook
More than one field to join files (2 of 2)
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
JOINREC
USAGE (O, I, B, H)
DECIMAL
POSITIONS
DATA
LENGTH
NAME
REFERENCE (R)
NAME TYPE
FORM TYPE
IBM i
FUNCTIONS
JFILE(PF1 PF2)
JOIN(1 2)
JFLD(PTNBR PTNBR)
JFLD(COLOR COLOR)
PTNBR
COLOR
PRICE
QUANTOH
JREF(1)
JREF(1)

Figure 7-14. More than one field to join files (2 of 2)
OL629.0
Notes:
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.
The JREF is only needed because there is ambiguous field naming. In this case the field
name, PRNBR, is used in both physical files.
If you adopt a good convention of unique field naming, JREF will not be necessary.

V8.0
Student Notebook
Uempty
Joining more than two files (1 of 2)

IBM i
Join logical
file
CRSID
CRSDSC
CLSDAT
INSID
INSNM
COURSE
CLASS
CRSID
CRSDSC
CRSPRC
CRSDUR
CLSID
CRSID
CLSDAT
INSID
INSTR
INSID
INSNMM

Figure 7-15. Joining more than two files (1 of 2)
OL629.0
Notes:
This is an illustration of joining the COURSE file to the CLASS file on COURSE NUMBER
and joining the CLASS file to the INST file on INSTRUCTOR NUMBER.
Each record in the join logical file will contain data from all three physical files.
Up to 32 files can be joined. Joining is done two files at a time.

7-17
Student Notebook
Joining more than two files (2 of 2)
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
USAGE (O, I, B, H)
DECIMAL
POSITIONS
DATA
LENGTH
NAME
REFERENCE (R)
NAME TYPE
FORM TYPE
IBM i
JOINREC
Performance: List files with

fewest records first
Primary Secondaries
JFILE(COURSE CLASS INSTR)
Primary: first file of first JOIN

J
J
Secondaries: Joined in
sequence listed in JFILE
CRSID
CRSDSC
CLSDAT
INSID
INSNM
K
JOIN(COURSE CLASS)
JFLD(CRSID CRSID)
JOIN(CLASS INSTR)
JFLD(INSID INSID)
JREF(1)
JREF(3)
CRSID

Figure 7-16. Joining more than two files (2 of 2)
OL629.0
Notes:
This shows the DDS coding for the previous illustration. Notice that there are two sets of
JOIN specifications.
COURSE joined to CLASS on CRSID
CLASS joined to INST on INSID
If secondary records might be missing in either file, the JDFTVAL keyword should also be
coded at the file level.
The key to the file must come from the primary file. Therefore, even though the files in the
example could have been joined in any sequence, the sequence that you desire the
records to be in will affect your choice of a primary file.

V8.0
Student Notebook
Uempty
File joined to itself (1 of 2)

IBM i
Join logical
file
EMPLOYEE NO
EMPLOYEE NAME
MANAGER NAME
PF 1
PF 1
EMPLOYEE NO
EMPLOYEE NAME
MANAGER NO
EMPLOYEE NO
EMPLOYEE NAME
MANAGER NO

Figure 7-17. File joined to itself (1 of 2)
OL629.0
Notes:
If all of the company's employees are in a single physical file (PF1) and each record
contains the employee number, employee name, and manager's number (employee
number for the manager), PF1 can be joined to itself to produce this join logical file.
The JREF keyword must be used since all field names are ambiguous.

7-19
Student Notebook
File joined to itself (2 of 2)
JOINREC
FUNCTIONS
JFILE(PF1 PF1)
JOIN(1 2)
JFLD(MGRNO EMPNO)
EMPNO
EMPNM
MGRNM
USAGE (O, I, B, H)
DECIMAL
POSITIONS
NAME TYPE
A
A
A
A
A
A
A
A
A
A
A
A
A
DATA
FORM TYPE
NAME
LENGTH
REFERENCE (R)
IBM i
JREF(1)
JREF(1)
RENAME(EMPNM) JREF(2)
EMPNO

Figure 7-18. File joined to itself (2 of 2)
OL629.0
Notes:
The employee name in the secondary has been renamed to manager's name.
Since the primary and secondary files are the same file and therefore have the same
name, a relative file number must be used on the JOIN and JREF keywords.
We have shown examples of inner (natural) join, and left outer join. DDS does not support
the following joins: exception join, right outer join, and cross join. Therefore, DDS is limited
in its join logical file capabilities. SQL is a better option if more sophisticated join operations
are required. (An exception join can be achieved in Query for i5/OS and OPNQRYF.)

V8.0
Student Notebook
Uempty
Lab example
IBM i
BUYER
BUYID
BUYNM
101 PEABO BRYSON
121 HALLIE PERSTON
245 NATALIE COLE
101
PEABO BRYSON
BUYMGR
245
256
121
245
JFLD
245
NATALIE COLE
121
121
101 PEABO BRYSON
BUYID
BUYNM
245
BUYMGR
NATALIE COLE
BUYNM1
JFL
DHALLIE PERSTON
121
BUYID1
256
HALLIE PERSTON
BUYNM2
BUYJOIN

Figure 7-19. Lab example
OL629.0
Notes:

7-21
Student Notebook
Checkpoint
IBM i
1. True or False: A join logical file is a logical file that combines

(in one record format) fields from two or more physical files.
2. True or False: A join logical file is a logical file that can be
used by programs for adding and updating data.
3. True or False: The JREF keyword allows you to specify
which file a field comes from when the same names exist.

OL629.0
Notes:

V8.0
Student Notebook
Uempty
Lab exercise
IBM i
Join logical file coding

OL629.0
Notes:

7-23
Student Notebook
Unit summary
IBM i


OL629.0
Notes:

V8.0
Student Notebook
Uempty
Unit 8. Database maintenance considerations

This unit describes IBM i database maintenance concepts.

An IBM i database maintenance procedure

Accountability
Machine exercises

8-1
Student Notebook
Unit objectives
IBM i
After completing this unit, you should be able to describe


OL629.0
Notes:
8-2

V8.0
Student Notebook
Uempty
Database maintenance
IBM i
What objects affected

What actions required
Add, change, delete a field

Figure 8-2. Database maintenance
OL629.0
Notes:
There are many impact analysis utilities on the market which enable the impact of IBM i file
changes to be assessed. Most of these utilities will also automate the change process,
which is a lengthy series of steps that must be followed in a rigorous manner.
We will discuss the IBM i commands and tools which can assist in the assessment and
change process when there are no other utilities are available.
Be aware, however, that this is a passive process which depends on an accurate snapshot
of object information. Should object definitions change, the information will have to be
regenerated.

8-3
Student Notebook
Example: Enlarging a field size (1 of 2)

IBM i
*File - PF

Figure 8-3. Example: Enlarging a field size (1 of 2)
OL629.0
Notes:
What are the consequences of enlarging a fields size?
8-4

V8.0
Student Notebook
Uempty
Example: Enlarging a field size (2 of 2)

IBM i
*File - PF
Affected objects
*File - PF
*File - PRTF
*File - LF
*File - DSPF
*PGM

Figure 8-4. Example: Enlarging a field size (2 of 2)
OL629.0
Notes:
Different objects are affected by the fact that a field size was changed. The next visuals
describe the different ways of detecting those affected objects.
Any object that uses that field must be examined for the impact of the change. The first task
is to determine which objects use the field.

8-5
Student Notebook
DSPFFD: Fields within file

IBM i
*File - PF
*File - PF
*File - PRTF
*File - LF
DSPFFD
*File - DSPF
*PGM

Figure 8-5. DSPFFD: Fields within file
OL629.0
Notes:
The DSPFFD command shows which fields a file has.
File name, library, type, member, creation date, number of records, record format name,
format level identifier, text, record length, and number of fields in format
Field name, type, length, edit code, edit word, column headings, and validity checking
information
For fields referencing other fields, the name of the referenced file, record format, and
field; if any attributes of the referenced field were changed the attribute type is given.
Most importantly, the results of this (and subsequent) DSPxxx commands can be directed
to a physical file. If the information is put in a database file, the database file will have a
record format named QWHDRFFD. This allows for easy querying of results. Tools such as
Query for i5/OS, STRQM, SQL, and so forth can then be used to analyze the results in
such a way as to produce a list of each field and the files this field is defined in.
Furthermore, programs can be written to analyze and process the results automatically (a
speedier and more accurate approach than poring over listings).
8-6

V8.0
Student Notebook
Uempty
DSPPGMREF: Files used by programs

IBM i
*File - PF
*File - PF
*File - PRTF
*File - LF
*File - DSPF
*PGM
DSPPGMREF
Figure 8-6. DSPPGMREF: Files used by programs
OL629.0
Notes:
Knowing which files are affected (DSPPFD), the display program references command
(DSPPGMREF) will tell which programs use these affected files.
The DSPPGMREF command shows a list of the system objects to which the specified
programs refer. For files, the following is shown: name, use (input, output, update, or
unspecified), number of record formats, name of record format and its record format
identifier, and the number of fields referenced for each format.
Again, using the OUTPUT(*OUTFILE) parameter allows you to automate the process or
produce meaningful queries.

8-7
Student Notebook
DSPDBR: Which LFs use which PFs?

IBM i
*File - PF
*File - PF
*File - PRTF
*File - LF
*File - DSPF
*PGM

Figure 8-7. DSPDBR: Which LFs use which PFs?
OL629.0
Notes:
The display database relations (DSPDBR) command identifies the physical and logical files
that are dependent on a specific file, files that use a specific record format, or file members
that are dependent on a specific file member.
8-8

V8.0
Student Notebook
Uempty
System cross-reference files

IBM i
The IBM i manages files that contain the following:

Basic database file attribute information (QADBXREF)
Cross-reference information about all database files on the
system (QADBFDEP)
Database file field information (QADBIFLD)
Database file key field information (QADBKFLD)
Referential constraint file information (QADBFCST)
Referential constraint field information (QADBCCST)
SQL package information (QADBPKG)
Remote database directory information (QADBXRDBD)

Figure 8-8. System cross-reference files
OL629.0
Notes:
These files can be queried to give information similar to DSPFD, DSPFFD, and DSPDBR.
You could produce customized documentation of your database. To display fields
contained in these files, use the DSPFFD command.
System cross-reference files are active, meaning they are automatically updated by IBM
i/OS whenever any file changes occur! It only applies to database (PF and LF) files.

8-9
Student Notebook
Using system cross-reference files

IBM i
Same information as DSPFD, DSPFFD, and DSPDBR

Always open and always current
Physical files: QSECOFR only
Logical files: All users

Figure 8-9. Using system cross-reference files
OL629.0
Notes:
Normal file commands, such as DSPFD, DSPFFD, and DSPDBR, work against these files.
The cross-reference files may also be queried by Query for i5/OS or OPNQRYF.
The authority to use these files is restricted to the SECOFR; however, all users have
authority to view the data by using one of the (or the only) logical files built over each file.
The authority for these files cannot be changed because they are always open.

V8.0
Student Notebook
Uempty
FNDSTRPDM: Find string with PDM

IBM i
Complement to DSPFFD, DSPDBR, and DSPPGMREF

Preceding commands look at *FILE and *PGM objects.
Data in QxxxSRC includes field names and file names
Available through PDM Option 25 = Find String

Figure 8-10. FNDSTRPDM: Find string with PDM
OL629.0
Notes:
Use the find string PDM (FNDSTRPDM) command to find the files the field is in.
This is a source code scan tool which complements the DSPxxx commands. Many
systems may not have the source code, or the source may be unreliable.
It provides an additional means of investigating the impact of change, verifying the results
obtained from the DSPxxx commands.

8-11
Student Notebook
FNDSTRPDM parameters
IBM i
STRING
( 'string' )
FILE library/QxxxSRC
MBR
( *ALL
((
*EDIT
*DLT
*RNM
OPTION
PROMPT
*CHGT
*DSP
*SAVE
*NONPROMPT
*PROMPT
*CMPR
*COPY
*DSPD *PRT
*SDA
*RLU
NO
( **YES
)
*MARK
( *NOMARK )
PRTMBRLIST
MARK
PRTRCDS
*NONE
*ALL
number
*CHAR
*HEX
*ALTHEX
*MARK
*NOMARK
*FOLD
*TRUNCATE

Figure 8-11. FNDSTRPDM parameters
)
OL629.0
Notes:
The find string PDM (FNDSTRPDM) command will do the following:
FNDSTRPDM will search the members of the file named for the character string given.
As shown this visual, the command will search all members of QDDSSRC and print a
list of those that contain the field named in the STRING parameter.
FNDSTRPDM will display, delete, compile, print, or edit members containing the string if
requested in the OPTION parameter.

V8.0
Student Notebook
Uempty
Example: Implement the field change (1 of 2)

IBM i
1. Change field reference file source and re-create.

2. Find affected physical files.
DSPFFD
Or DSPFFD ... OUTPUT(*OUTFILE) and QUERY/400
Or FNDSTRPDM
3. Optional, but highly recommended, save the affected

physical files.
4. For each physical file do the following:
CHGPF FILE (physical file name)
SRCFILE (source file name)
SRCMBR (source file member name)
5. Find affected display files and externally described printer

files (see step 2).
6. If necessary, modify and recompile display and printer files.
Figure 8-12. Example: Implement the field change (1 of 2)
OL629.0
Notes:
When SRCFILE is specified on CHGPF, the specifications in the source file are used to
change the physical file. The specifications describe the record format and its fields and the
access path for the file and its members. The data in the existing file is connected to the
new format based on field names. If the name of a field is changed, its existing data is lost.
Because you are connecting data, it is strongly recommended that you save the file before
you issue this command. A new access path may have to be built. If data is connected or a
new access path is built, this command could take a long time to complete.

8-13
Student Notebook
Example: Implement the field change (2 of 2)

IBM i
7.
Find affected programs.

DSPPGMREF... OUTFILE(Y)
DSPFFD... OUTFILE(W)
W
PGMX
FILEA
"
"
FORMATX
FILEA
FIELDA
"
FIELDB
"
FIELDC
FILEB
PGMY
"
FILEA
"
FILEC
Select W records with changed field.

Join W and Y on file name using the following:
Join logical file
QUERY/400
8. Change program source if necessary.

9. Recreate programs.
Figure 8-13. Example: Implement the field change (2 of 2)
OL629.0
Notes:
In order to find the affected programs, a query can be done. From the DSPFFD outfile (W),
select files with the record formats that contain the changed field. The DSPPGMREF outfile
(Y) will have programs and the file resources used by those programs. By joining the two
files using file as the join field, we can get an idea of the scope of effort required to modify
programs that use the changed data field.

V8.0
Student Notebook
Uempty
Checkpoint
IBM i
1. True or False: System cross-reference files are automatically updated

by IBM i/OS whenever any database (PF and LF) file changes occur.
2. Source files can be searched with the (blank) command.
a. DSPFFD
b. DSPDBR
c. FNDSTRPDM
d. DSPPGMREF
3. True or False: The CHGPF command causes the data in the existing
file to be associated to a new format (specified with the SRCFILE
parameter) based on field names, allowing data format changes.

OL629.0
Notes:

8-15
Student Notebook
Lab exercise
IBM i
Database maintenance considerations

OL629.0
Notes:

V8.0
Student Notebook
Uempty
Unit summary
IBM i
Having completed this unit, you should be able to describe


OL629.0
Notes:

8-17
Student Notebook

V8.0
Student Notebook
Uempty
Unit 9. Interface to DB2 for i

In this unit you will learn how to manage IBM i database objects and
data using PDM, RDP, DFU, System i Navigator, SQL, and other query
tools.

Access DB2 with:
- Traditional interface: PDM
- Rational Developer for Power Systems: RSE
- IBM i Access: System i Navigator
- Data file utility: DFU
- Structured Query Language: SQL
- Query for IBM i and Query Manager: QRY

Accountability
Machine exercises

9-1
Student Notebook
Unit objectives
IBM i

Access DB2 with:
Traditional interface: PDM
Rational Developer for Power Systems: RSE
IBM i Access: System i Navigator
Data file utility: DFU
Structured Query Language: SQL
Query for IBM i and Query Manager: QRY

OL629.0
Notes:
Programming Development Manager (PDM), Remote System Explorer (RSE), and System
i Navigator are three navigation/explorer style tools. data file utility (DFU), Structured Query
Language (SQL), Query for IBM i (QRY) are data manipulation tools.
Equally, SQL SELECT provides a coarse method for data query, but for end-user reporting,
the Query Manager (QM) or Query for IBM i tools should be used.
9-2

V8.0
Student Notebook
Uempty
9.1. Traditional interface: PDM

9-3
Student Notebook
Powertm with IBM i

Figure 9-2. Traditional interface: PDM
8.1
OL629.0
Notes:
9-4

V8.0
Student Notebook
Uempty
Application Development Toolset for IBM i

IBM i
LICENSED PROGRAM
LIBRARIES
PDM
OBJECTS
MEMBERS
Programming Development Manager

Source entry utility
Screen design aid
Report layout utility
Data file utility
File compare and merge utility
Interactive source debugger

Figure 9-3. Application Development Toolset for IBM i
OL629.0
Notes:
The Programming Development Manager (PDM) provides the focal point for this integrated
application development environment by managing lists of items to be developed or
maintained. By subsetting and selecting from lists, the user can manipulate any number of
objects. This enhances the productivity of analysts, programmers, and other support
personnel in managing programs, data, and systems information by focusing activities on a
grouping of objects or items to be worked on. The other tools are fully integrated; the user
always returns to the PDM list when use of a tool is complete. Also, by automatically
invoking the appropriate command with correct parameters and syntax, keying and errors
are reduced. This integration is further enhanced by user-definable options to extend this
environment with the user's own tools.
Source entry utility (SEU) is a full-screen editor providing syntax checking of compiler
source statements.
Screen design aid (SDA) is used to interactively design, create, and maintain customer
application panels (displays and menus).

9-5
Student Notebook
Report layout utility (RLU) allows a programmer to define the layout of a printed report on
the screen.
Data file utility/application development (DFU/AD) can be used to define, create, and
maintain database applications that are primarily oriented to data entry, inquiry, or file
maintenance. It is especially useful for the creating of test data for an application being
developed.
File compose and merge utility (FCMU) is a compare function.
Interactive source debugger (ISDB) is used to debug programs.
9-6

V8.0
Student Notebook
Uempty
STRPDM: Programming Development Manager

IBM i
Programming Development Manager (PDM)
Select one of the following:

1.
2.
3.
4.
5.
6.
Work
Work
Work
Work
Work
Work
with
with
with
with
with
with
libraries
objects
members
projects
groups
parts
9. Work with user-defined options
Selection or command
===> __________________________________________________________________________
_______________________________________________________________________________
F3=Exit
F4=Prompt
F9=Retrieve
F10=Command entry
F12=Cancel
F18=Change defaults

Figure 9-4. STRPDM: Programming Development Manager
OL629.0
Notes:
On the command line, type STRPDM and press Enter.
Options 1 through 3 are the most frequently used options.

9-7
Student Notebook
PDM options to access database

IBM i
1. Work with libraries (or library lists)

Change, copy, display, rename, display description, save,
restore, work with contents, change text, or rearrange library list.
2. Work with objects in a library

Select objects from library by name and type, and then change,
copy, delete, display, rename, display description, save, restore,
move, work with, change text, copy file, run, change using DFU,
find string, create (service) program, debug, or compare.
3. Work with members in a file

Select members from file by name and type, and then edit, copy,
delete, display, print, rename, display description, save, change
text, compile, create module, run procedure, change with
SDA/RLU, find string, compare, or merge.

Figure 9-5. PDM options to access database
OL629.0
Notes:
Using the PDM options, you can use function keys and options that vary depending upon
the PDM option that you chose:
1. Work with LIBRARIES (or library lists)
Change, Copy, Display, Rename, Display Description, Save, Restore, Work with contents,
Change text, Rearrange library list.
2. Work with OBJECTS in a library
Select objects from library by name and type, and then Change, Copy, Delete, Display,
Rename, Display Description, Save, Restore, Move, Work with, Change text, Copy file,
Run, Change using DFU, Find string, Create (service) program, Debug, Compare.
3. Work with MEMBERS in a source file
Select members from file by name and type, and then Edit, Copy, Delete, Display, Print,
Rename, Display Description, Save, Change text, Compile, Create Module, Run
Procedure, Change with SDA/RLU, Find String, Compare, Merge.
9-8

V8.0
Student Notebook
Uempty
9.2. Data file utility

9-9
Student Notebook
Data file utility
Powertm with IBM i

Figure 9-6. Data file utility
8.1
OL629.0
Notes:

V8.0
Student Notebook
Uempty
Generates interactive program

IBM i
Generates interactive program

Maintain a file
Update
Add
Delete
Display file records (inquiry)

Browse only
Fast path
Use defaults
Preselect options
No programming language
Permanent or temporary program

Figure 9-7. Generates interactive program
OL629.0
Notes:
The data file utility (DFU) is a program generator that helps you create programs to enter
data, update files, and make file inquiries. You do not need a programming language to use
DFU. You create the program by responding to a series of displays. DFU creates the
program for you.
DFU is a quick and simple file patch tool used to fix data problems or create test cases. It
should not be used for end-user maintenance of data which should be provided through
local application programs.

9-11
Student Notebook
DFU features
IBM i
Modules 10 and 11 self-check digit

Audit report
Batch accumulators
Auto: DUP
Auto advance
Upper and lowercase control
Access approximate key then page to next or previous record
Print key support
Auto generate key or RRN

Figure 9-8. DFU features
OL629.0
Notes:
DFU is one tool you can use to create test data. Even though if has an impressive list of
basic features, DFU is not a replacement for good application code.

V8.0
Student Notebook
Uempty
Using DFU versus writing a program

IBM i
Computations on selected fields

Multiple file access
Relationships between fields
Complex screen format requirements

Figure 9-9. Using DFU versus writing a program
OL629.0
Notes:
While DFU can be easily used to create temporary programs that allow you to enter data,
update files, and make file inquiries, you should use a programming language (such as
RPG or COBOL) if your application requires any of the following:
Computations on selected fields
Multiple file access
Validation of the relationship between multiple field entries
Complex screen formatting requirements

9-13
Student Notebook
STRDFU
IBM i
Data File Utility (DFU)

1.
2.
3.
4.
5.
Run a DFU program

Create a DFU program
Change a DFU program
Delete a DFU program
Update data using temporary program
F3=Exit
F4=Prompt
===> 2
F9=Retrieve
F12=Cancel
(C) COPYRIGHT IBM CORP. 1981, 1999.

Figure 9-10. STRDFU
OL629.0
Notes:
Option 5. Update data using temporary program
This option executes the UPDDTA command.
Choose this option to create and run a temporary program. You can update an existing file
without having to define a program. When you press Enter, the Update Data Using
Temporary Program panel appears.
The visual shows option 2 selected. This option allows you to create a DFU program that
can be saved for repeated execution. The following visuals will take a look at screens youll
encounter as you define your DFU program.

V8.0
Student Notebook
Uempty
Create a DFU Program

IBM i
Create a DFU Program

Type choices, press Enter.
Program . . . . . . . . . .
Library . . . . . . . . .
CUSTL1DFU
*CURLIB
Name, F4 for list

Name, *CURLIB
Data file . . . . . . . . .
Library . . . . . . . . .
CUSTL1
*CURLIB
Name, F4 for list

Name, *LIBL, *CURLIB
F3=Exit
F4=Prompt
F12=Cancel

Figure 9-11. Create a DFU Program
OL629.0
Notes:
When you choose option 2 from the main DFU menu, the Create a DFU Program panel
prompts you for the name of the DFU program that you want to define and the data file on
which the program is to run. In the following example, you will create a DFU program
(CUSTL1DFU) to add and to update customers in the file CUSTL1. Press Enter.

9-15
Student Notebook
Define General Information/Indexed File

IBM i
Define General Information/Indexed File

Job title . . . . . . . . . . . . . .
Display format . . . . . . . . . . .
CUSTL1DFU TEAM 01
2
1=Single, 2=Multiple
3=Maximum, 4=Row oriented
Audit report . . . .
S/36 style . . . . .
Suppress errors . . .
Edit numerics . . . .
Allow updates on roll
Keys:
Generate . . . . .
Changes allowed . .
.
.
.
.
.
Y
N
N
N
Y
Y=Yes,
Y=Yes,
Y=Yes,
Y=Yes,
Y=Yes,
. . . . . . . .
. . . . . . . .
N
Y
Y=Yes, N=No
Y=Yes, N=No
F3=Exit
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
F12=Cancel
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
N=No
N=No
N=No
N=No
N=No
F14=Display definition

Figure 9-12. Define General Information/Indexed File
OL629.0
Notes:
Next, is the Define General Information/Indexed File panel, where you can specify the
general characteristics of your program.
To specify the characteristics, do the following:
1. Type CUSTL1 DFU TEAM01 in the Job title prompt to change the default job title.
2. Type 2 in the Display format prompt to change the display format to multiple.
3. Type Y (Yes) in the Audit report prompt to produce an audit report, which lists all
changes made to a data file.
Type Y in the Edit numerics prompt to format numeric fields.
4. Leave the other prompts to their defaults and press Enter.

V8.0
Student Notebook
Uempty
Define Audit Control

IBM i
Define Audit Control

Print additions .
Print changes . .
Print deletions .
Printer:
Line width . .
Column spacing
F3=Exit
. . . . . . .
. . . . . . .
. . . . . . .
Y
Y
Y
Y=Yes, N=No
Y=Yes, N=No
Y=Yes, N=No
. . . . . . .
. . . . . . .
132
1
60-198
0-9
F12=Cancel

Figure 9-13. Define Audit Control
OL629.0
Notes:
The Define Audit Control panel appears because you specified Y in the Audit report
prompt. If you specify N in the Audit report prompt, the Work with Record Formats panel is
shown.

9-17
Student Notebook
Work with Record Formats

IBM i
Work with Record Formats

File . . . :
CUSTL1
Library
Type options, press Enter.

2=Specify
4=Delete
Opt
2
Format
CUSFMT
Defined
N
. . . . :
FAC01
Press F21 to select all.
Description
Customer Master
Bottom
F3=Exit
F5=Refresh
F21=Select all
F12=Cancel

Figure 9-14. Work with Record Formats
OL629.0
Notes:
If you specify N in the Audit report prompt, the Work with Record Formats panel is shown.
The Work with Record Formats panel appears if your data file is a DDS described file. This
display lists the various record formats in your file specification. You can work with one or
more formats for processing. If you select more than one record format, DFU presents a
new Select and Sequence Fields panel and repeats the field definition sequence for each
record format you select from this panel.
If you type 2 (Specify) next to the CUSFMT format, the Select and Sequence Fields display
appears.

V8.0
Student Notebook
Uempty
Select and Sequence Fields

IBM i
Select and Sequence Fields

File . . . . . . . . . . . :
Record format . . . . . . . :
CUSTL1
CUSFMT
Library
. . . . :
FAC01
Select fields and their sequence or press F21 to select all; press Enter.
Sequence
1
2
3
4
5
6
Field
ACTIVE
CUSTNO
CNAME
CSTREE
CCITY
CSTATE
CZIP
CRLIM
BALANC
YRTOTL
DCODE
F3=Exit
F20=Renumber
Attr
KEY
Length
1,0
6
25
25
25
2
5,0
5,2
7,2
7,2
1
F5=Refresh
F21=Select all
Type
PACK
CHAR
CHAR
CHAR
CHAR
CHAR
PACK
PACK
PACK
PACK
CHAR
F12=Cancel
Description
Record Status Code
Customer Number
Customer Name
Street
City
State
Zip Code
Credit Limit
Account Balance
YTD Sales
Delete Code
Bottom

Figure 9-15. Select and Sequence Fields
OL629.0
Notes:
On the Select and Sequence Fields panel, you can select the fields and the field order that
your DFU program will use for each selected record format. Your field selections appear on
the data entry display when you run the program. The displayed information is from the
applicable DDS file descriptions.

9-19
Student Notebook
Work with Fields

IBM i
Work with Fields

File . . . . . . . . . . :
Record format . . . . . . :
CUSTL1
CUSFMT
Library . . . . :
FAC01
Type options, press Enter. Press F21 to select all.

2=Specify extended definition
4=Delete extended definition
Opt
2
2
2
2
2
Field
CUSTNO
CNAME
CSTREE
CCITY
CSTATE
CZIP
Extended
Definition
N
N
N
N
N
N
Heading
Cust
Customer Name
Street
City
ST
Zip
Bottom
F3=Exit
F5=Refresh
F21=Select all
F12=Cancel

Figure 9-16. Work with Fields
OL629.0
Notes:
The Work with Fields panel appears when you press Enter from the previous Select and
Sequence Fields panel. From here you can select the fields that need extended definition
and extended validation and specify alternate headings to appear on the data entry panel.
If you do not require extended definitions, press Enter. You can type 2 to work with a field
that you want to have an extended definition. You can work with more than one field. This
option will also allow you to specify validity checks to be performed against the field while
running your DFU program. If you type 4, you delete the extended definition of a field. This
will also delete any validity checks. Remember that file defined validity checking will still be
retained.

V8.0
Student Notebook
Uempty
Specify Extended Field Definition

IBM i
Specify Extended Field Definition

Field
. . . . . . . . :
CNAME
Record format
. . . . :
CUSFMT

Auto-duplicate . . . . . . . . . . .
Allow lowercase . . . . . . . . . . .
Extended field
heading . . . . . . . . . . . . . .
Heading location . . . . . . . . . .
Initial value . . . . . . . . . . . .
Validity checks . . . . . . . . . . .
N
Y
Y=Yes, N=No
Y=Yes, N=No
Cust
Name
*BEFORE
*ABOVE, *BEFORE
2=Change, 4=Delete
More...
F3=Exit
F12=Cancel

Figure 9-17. Specify Extended Field Definition
OL629.0
Notes:
Two extended definition panels exist: one for alphanumeric fields and one for numeric
fields. In this example, the Specify Extended Field Definition panel for alphanumeric fields
appears first because the first field selected for extended definition is the alphanumeric
CNAME field.
Lowercase is allowed (by specifying Y), and the heading has been changed. The field
heading can be further defined and an initial value for the field can be set.
Specify the validity checks you want to be performed by DFU while running the DFU
program.
Choose from the following for the validity check:
2=Change
Type 2 to specify validity checks to be used against the data entered.
4=Delete
Type 4 to remove any previously defined validity checks which you specified when you
created your DFU program. Any validity specified in the file definition will also be removed.

9-21
Student Notebook
Exit DFU Program Definition

IBM i
Exit DFU Program Definition

Save program . . .
Run program . . . .
For choice Y=Yes:
Type of run . .
Modify program . .
Save DDS source . .
. . . . . .
. . . . . .
Y
Y
Y=Yes, N=No
Y=Yes, N=No
. . . . . .
. . . . . .
. . . . . .
1
N
N
1=Change, 2=Display
Y=Yes, N=No
Y=Yes, N=No
CUSTL1DFU
*CURLIB
*LIBCRTAUT
CUSTL1DFU TEAM
Name
Name, *CURLIB, . . .
Name, *LIBCRTAUT, . . .
01
*CURLIB
CUSTL1DFU
Name
Name, *CURLIB, . . .
Name
For Save program Y=Yes:

Program . . . . . . .
Library . . . . . .
Authority . . . . . .
Text . . . . . . . .
For Save DDS source
Source file . . .
Library . . . .
Source member . .
F3=Exit
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Y=Yes:
. . . . . .
. . . . . .
. . . . . .
F17=Fast path

Figure 9-18. Exit DFU Program Definition
OL629.0
Notes:
The Exit DFU Program Definition panel allows you to save, to run, or to save and then run
your newly defined DFU program. In this example, you save the CUSTL1DFU program and
work on records in the CUSTL1 file while running the program.
If the program is saved, two objects will be created and saved.
1. Program object
Type: *PGM Attribute: DFU
2. File object
Type: *FILE Attribute: DFU
If you want to run the program automatically, press F17 (fast path). When you press F17
(fast path), you do not see any other displays before running the program. To choose a
specific member other than the first in the file, press Enter. A panel appears, prompting you
for program, file, and member information.

V8.0
Student Notebook
Uempty
Change a Data File

IBM i
Change a Data File

Program . . . . . . . . . .
Library . . . . . . . . .
CUSTL1DFU
*CURLIB
Name, F4 for list

Data file . . . . . . . . .
CUSTL1
Name, *SAME, F4 for list
Library . . . . . . . . .
Member . . . . . . . . . .
FAC01
*FIRST

Name, *FIRST, F4 for list
F3=Exit
F4=Prompt
F12=Cancel
The DFU program was saved successfully.

Figure 9-19. Change a Data File
OL629.0
Notes:
Use the Change a Data File (option 3 from the FDFU menu) panel to specify the name of
the program you want to use for working on a data file. You can use the default data file
specified by the program or specify a different data file by entering the new file name in the
Data file prompt of this display.This display appears automatically as a result of our
definition of a new DFU program.

9-23
Student Notebook
Initially, change mode

IBM i
CUSTL1DFU TEAM 01
Format . . . . :
CUSFMT
Mode . . . . :
File . . . . :
CHANGE
CUSTL1
Cust No:
F3=Exit
F9=Insert
F5=Refresh
F10=Entry
F6=Select format
F11=Change

Figure 9-20. Initially, change mode
OL629.0
Notes:
Use this panel to look at or change the records in a data file.
If you selected to display a data file, you are in display mode. In display mode, your records
will be displayed, but you will be unable to change them.
If you selected to change a data file, you are in insert mode, entry mode, or change mode.
Press F9 for Insert, F10 for Entry, or F11 for Change to switch modes, respectively.
In insert mode you are able to add new records between existing records. In entry mode
you add new records to the end of the data file. In change mode you change existing
records.
For further details on how to use function keys, position the cursor in the function key area
on the display, and press Help for the extended help for the panel. For example, this is how
you would discover that F23, when pressed, deletes a currently displayed record.

V8.0
Student Notebook
Uempty
Entry mode
IBM i
CUSTL1DFU TEAM 01
Format . . . . :
Cust
Cust
Cust
Cust
Cust
Cust
CUSFMT
Mode . . . . :
File . . . . :
ENTRY
CUSTL1
No:
Name:
Address:
City:
State:
Zip:
F3=Exit
F9=Insert
F5=Refresh
F10=Entry
F6=Select format
F11=Change

Figure 9-21. Entry mode
OL629.0
Notes:
Entry mode allows the entry of new records into the file.

9-25
Student Notebook
F3=Exit
IBM i
End Data Entry

Number of records processed
Added . . . . . :
Changed . . . . :
Deleted . . . . :
2
0
0
Type choice, press Enter.

End data entry
. . . . . . .
Y=Yes,
N=No
F3=Exit
F12=Cancel
All records added, changed, or deleted will be printed.

Figure 9-22. F3=Exit
OL629.0
Notes:
Upon exit (F3) from Change or Entry modes, a panel that verifies the number of adds,
updates, and deletes is presented.

V8.0
Student Notebook
Uempty
DFU commands and objects

IBM i
DFU application
Program:
*PGM
Attribute:
DFU
File:
* File
Attribute:
DFU
Commands
STRDFU: Show DFU menu.
DLTDFUPGM : Delete DFU program and file.
CHGDTA: Run DFU program.
DSPDTA: Run DFU program. You cannot change the data in the file.
UPDDTA: Update a file using a temporary DFU program.

Figure 9-23. DFU commands and objects
OL629.0
Notes:
DFU applications, if saved, have *PGM and *FILE objects that represent the DFU program
and display screen, respectively.
Listed on the visual are valid DFU commands that can be executed from the command line
or menu options.

9-27
Student Notebook

V8.0
Student Notebook
Uempty
9.3. Rational Developer for Power Systems: RSE

9-29
Student Notebook

IBM i
Rational Developer for

Power Systems:
RSE

Figure 9-24. Rational Developer for Power Systems: RSE
OL629.0
Notes:
Rational Developer for Power Systems (RDP) allows you to create and maintain RPG and
COBOL applications with the powerful workstation tools in this development environment.
Use the Remote System Explorer (RSE) to navigate through your IBM i objects and then
use the built-in editing and compiling features. Once you have defined a connection, you
are ready to find and edit your IBM i members.

V8.0
Student Notebook
Uempty
RSE: IBM i/OS workbench perspective

IBM i
The Remote Systems Explorer (RSE) is the workbench perspective for

IBM i development tools. You can use RSE to do the following:
Connect to an IBM i host or to other systems, such as UNIX or Linux.
Perform actions against objects and database objects.
Define your connections to an i host through an RSE communications
connection.

Figure 9-25. RSE: IBM i/OS workbench perspective
OL629.0
Notes:
The Remote Systems Explorer (RSE) is a workbench perspective for IBM i development
tools that has views and tools that let you develop applications for remote operating
systems. A perspective is a specific arrangement of views and tools in the workbench.
Depending on what role the workbench user has, he or she will use a different perspective.
For example, a web developer will use the web perspective, a Java developer will use the
Java perspective, and an IBM i developer will use the Remote Systems Explorer
perspective.
The user interface lets you do the following:
Define your connections to an IBM i system through an RSE communications
connection
Manage your local set of files through a filtering system that obtains information from
your IBM i system
Manage resources
Monitor jobs
Run commands

9-31
Student Notebook
First, start Rational Developer for Power Systems. Select Start > Programs > IBM
Software Delivery Platform > IBM Rational Developer for Power Systems Software
V8.5> IBM Rational Developer for Power Systems Software.
Follow the following steps to create a new connection:
1. Open the Remote Systems Explorer: Window > Open Perspective > Remote
Systems Explorer.
2. Invoke the New Connection window.
3. Click the + sign beside New Connection in the Remote Systems view.
4. Click the + sign beside the IBM i (select IBM i).
5. Enter the connection name.
6. Fill in the TCP/IP address of the i machine in the Host Name field, and add a description
(optional).
7. When prompted, enter the user ID and password.

V8.0
Student Notebook
Uempty
Manage objects through filters

IBM i
You can manage objects through a filtering system that

presents information from your IBM i host in a tree view.
Member filter
Library filter
Filters
Object filter
Filters can help you organize your objects, especially in cases

where you are working with a lot of them.
You can store a combination of filters.
Figure 9-26. Manage objects through filters
OL629.0
Notes:
There are three main types of filters.
Library filters retrieve and display a set of libraries from the IBM i.
Object filters retrieve and display a set of objects from the IBM i.
Member filters retrieve and display a set of source members from the IBM i.

9-33
Student Notebook
Creating a library filter

IBM i
Just fill in the fields Click, then

Figure 9-27. Creating a library filter
OL629.0
Notes:
Expand Objects, and perform the following steps:
1. Click the + sign in front of Work with libraries.
2. Choose the library to include from the pull-down menu, browse to find a library, or
specify your own.
3. Specify a filter name.
4. Click Finish.

V8.0
Student Notebook
Uempty
Creating an object filter

IBM i
Click, and then fill in

Figure 9-28. Creating an object filter
OL629.0
Notes:
Expand Work with objects, and then perform the following steps:
1. Click the + in front of Work with objects.
2. Browse, specify, or select from the Library drop-down list the library that contains your
objects.
3. Browse, specify, or select an object from the Object drop-down list.
4. Define object type and attributes (optional), and then click Next.
5. Specify a name for the filter.
6. Click Finish.

9-35
Student Notebook
Creating a member filter

IBM i
Click, and then fill in

Figure 9-29. Creating a member filter
OL629.0
Notes:
Expand Work with members, and then perform the following steps:
1. Click the + in front of Work with members.
2. Browse, specify, or select from the Library drop-down list the library that contains your
objects.
3. Browse, specify, or select from the File drop-down list the file within the library that
contains the appropriate source members.
4. Browse, specify, or select from the Member drop-down list the member that contains
your data.
5. Optionally, browse, specify, or select from the Member type drop-down list the type of
members in which you are interested.
6. Use the check boxes to select whether you want to retrieve source members, data
members, or both (you must select at least one).
7. Click Next.
8. Specify a name for the filter.
9. Click Finish.

V8.0
Student Notebook
Uempty
Editing: Compiling
IBM i
You can use the Remote

Systems Explorer to edit your
files through the IBM i objects
subsystem.
You can edit source physical
file members using the LPEX
Editor.
There are two ways to

compile.
Prompted
Non-prompted
Both compile actions
invoke a submenu with a
list of compile commands.

Figure 9-30. Editing: Compiling
OL629.0
Notes:
Drill down through your subsystem in the Remote Systems view until you reach the
member you want to work with.
Right-click and select Open with > LPEX Editor.
Make your changes.
To compile within Remote Systems view, right-click a source member and select Compile
> name or Compile (No Prompt) > name (name representing the command you want to
run).
When you use Compile, a window will appear that allows you to view and change
parameters for that command.
When you use Compile (No Prompt), the command is performed on the server without
prompting you first.

9-37
Student Notebook

V8.0
Student Notebook
Uempty
9.4. Structured Query Language

9-39
Student Notebook
Structured Query Language
Powertm with IBM i

Figure 9-31. Structured Query Language
8.1
OL629.0
Notes:
While this class is not meant to teach you the SQL language, it will provide you with an
understanding of some of the features that are available in the language and how they
might be used.
There are other courses that teach SQL.
OL370/OV370 - Accessing the IBM i Database Using SQL
OL380/OV380 - Developing IBM i Applications Using SQL
or
OD470/OV470 - IBM i DB2 and SQL School
OD470 is a combined alternative to OL370 and OL380.

V8.0
Student Notebook
Uempty
Introducing SQL
IBM i
Introducing SQL,
Structured Query
Language
Developed originally by IBM

De facto industry standard
Define and maintain database
Create and maintain data
Query the database reports
Embedded in high-level language

Figure 9-32. Introducing SQL
OL629.0
Notes:
SQL, Structured Query Language, has been the de facto standard query tool in IT for a
number of years. SQL has been available on the AS/400, iSeries, and i since 1988.
Structured Query Language is a standardized language for defining and manipulating data
in a relational database. In accordance with the relational model of data, the database is
perceived as a set of tables. Relationships are represented by values in tables, and data is
retrieved by specifying a result table that can be derived from one or more base tables.
The ability to create SQL objects is built into DB2 for i, which is part of IBM i/OS; however,
the ability to query these objects requires that DB2 Query Manager and SQL Development
Kit (5770-ST1 for Version 7 of IBM i/OS) be installed on your system.
In addition to the SQL Development Kit, or as an alternative, you could use System i
Navigator which enables the use of SQL using ODBC to access DB2 objects on the IBM i.
SQL statements are executed by the DB2 database manager. One of the functions of the
database manager is to transform the specification of a result table into a sequence of

9-41
Student Notebook
internal operations that optimize data retrieval. This transformation occurs when the SQL
statement is prepared. This transformation is also known as binding.
All SQL statements must be prepared before they can be executed. The result of
preparation is the executable or operational form of the statement. The method of
preparing an SQL statement and the persistence of its operational form distinguish static
SQL from dynamic SQL.
SQL can be used to create and manage databases and to extract information from and
about databases. SQL can be run interactively or from within an application program or
through System i Navigator. Queries may also be designed and managed by Query
Manager, which is a component of the DB2 Query Manager and SQL Development Kit.

V8.0
Student Notebook
Uempty
SQL program products

IBM i
IBM i/OS provides run-time support for existing SQL

applications.
Query Management (not an end-user tool)

Call-level interface
APIs
RUNSQLSTM to run SQL statements in source members
DB2 Query Manager and SQL Development Kit
For SQL application development

Query Manager (end-user tool)
HLL precompilers
Interactive SQL
IBM i Access if System i Navigator is desired

GUI to the database
Leading edge database interface
Figure 9-33. SQL program products
OL629.0
Notes:
Many SQL based applications can be run without any special software; however, to
develop new SQL applications and for end-user support, many companies install both
System i Access (included with the system in version 7) and the DB2 Query Manager and
SQL Development Kit (separate charge software).

9-43
Student Notebook
More terminology
IBM i
SQL term
TABLE
Native i term
FILE
ROW
RECORD
COLUMN
FIELD
VIEW
LOGICAL FILE
INDEX
KEYED LOGICAL FILE
COLLECTION
LIBRARY
Industry terms
DB2 UDB terms
SCHEMA
SCHEMA
LOG
JOURNAL
ISOLATION LEVEL
COMMITMENT CONTROL
LEVEL

Figure 9-34. More terminology
OL629.0
Notes:
The terms on the left equate to the terms on the right. Traditional IBM i system users are
accustomed to using the terms on the right. While the terms used may be different, the
function provided is the same.
In some interfaces, you may see the term collection. An SQL collection is a schema.

V8.0
Student Notebook
Uempty
Types of SQL statements

IBM i
Security
Data definition
CREATE
DROP
ALTER
And so on
GRANT
REVOKE
SQL
Structured Query
Language
Data
manipulation
SELECT
INSERT
UPDATE
DELETE
And so on
Dynamic
DESCRIBE
EXECUTE
PREPARE
Miscellaneous
CONNECT
DECLARE
CALL
WHENEVER

Figure 9-35. Types of SQL statements
OL629.0
Notes:
Many of you will not have seen much of SQL (or maybe not heard much) beyond the basic
SELECT statement, which is used to query DB2 tables and views as well as physical and
logical files.
This visual shows you that SQL is much more than a query language. It includes
statements to manage DB objects, statements to manage security to DB objects,
statements to enable functional coding in HLL programs, and other statements.
The following are the major components of the Structured Query Language:
DDL (Data Definition Language) is used to create, drop, and alter SQL objects and their
description and definition. For example, you can define a column or field and then add a

9-45
Student Notebook
constraint to restrict the range of data allowed. The IBM i supports the following DDL
statements:
-
ALTER TABLE
COMMENT ON
CREATE SCHEMA
CREATE INDEX
CREATE PROCEDURE
CREATE SCHEMA
CREATE TABLE
CREATE VIEW
DROP SCHEMA
DROP INDEX
DROP PACKAGE
DROP PROCEDURE
DROP SCHEMA
DROP TABLE
DROP VIEW
LABEL ON
RENAME
The GRANT and REVOKE statements are also considered DDL statements but are
grouped under the CONTROL category in the visual.
DML (Data Manipulation Language) is used to select and present data, and change the
value of columns or fields. The IBM i supports the following DML statements:
-
CLOSE
COMMIT
DECLARE CURSOR
DELETE
FETCH
INSERT
LOCK TABLE
OPEN
ROLLBACK
SELECT INTO
UPDATE

V8.0
Student Notebook
Uempty
CONTROL statements are actually DDL statements but are being addressed
separately here because they are used to grant or revoke authority to SQL objects. The
i supports the following statements:
-
GRANT PACKAGE
GRANT PROCEDURE
GRANT TABLE
REVOKE PACKAGE
REVOKE PROCEDURE
REVOKE TABLE
DYNAMIC statements improve execution. SQL can be dynamically prepared in order to

improve execution. The i supports the following DYNAMIC statements:
-
DESCRIBE
EXECUTE
EXECUTE IMMEDIATE
PREPARE
MISCELLANEOUS statements allow access to databases. The IBM i supports the

following as MISCELLANEOUS statements:
-
BEGIN DECLARE SECTION

CALL
CONNECT
DECLARE PROCEDURE
DECLARE STATEMENT
DECLARE VARIABLE
DESCRIBE TABLE
DISCONNECT
END DECLARE SECTION
INCLUDE
RELEASE
SET CONNECTION
SET OPTION
SET RESULT SETS
SET TRANSACTION
WHENEVER

9-47
Student Notebook
Run SQL statements (RUNSQLSTM)

IBM i
Run SQL Statements (RUNSQLSTM)

Source file . . .
Library . . . .
Source member . .
Commitment control
Naming . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
F3=Exit
F4=Prompt
F5=Refresh
F13=How to use this display
SRCFILE
*LIBL
SRCMBR
COMMIT
NAMING
*CHG
*SYS
F10=Additional parameters
F24=More keys
Bottom
F12=Cancel

Figure 9-36. Run SQL statements (RUNSQLSTM)
OL629.0
Notes:
Following some cleanup and editing, you could run a series of SQL statements from a
source member as a group using the RUNSQLSTM command. Statements are still prepared
one-by-one sequentially. Any error in a statement causes an error at that point. No syntax
checking is done.

V8.0
Student Notebook
Uempty
Interactive SQL
IBM i
Interactive and immediate execution of SQL statements

SQL statement entered from a workstation
Statement is prepared and executed dynamically
Results displayed to the user
Invoked by STRSQL
Panel like the Command Entry panel
F4 prompting and Help available
Statements are syntax checked
Session statements can be saved to a source member for reuse with
RUNSQLSTM

Figure 9-37. Interactive SQL
OL629.0
Notes:
Interactive SQL is a 5250 based interface. This interface is used as a prototyping tool when
you are testing SQL statements.
Interactive SQL allows you to run individual SQL statements only. You can use the Run
SQL Scripts feature of System i Navigator to run SQL statements from a GUI interface
rather than a 5250 interface.

9-49
Student Notebook
Interactive SQL: Enter SQL Statements panel

IBM i
Enter SQL Statements

Type SQL statement, press Enter.
Current connection is to relational database EDUC3.
===>_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
_________________________________________________________________________
Bottom
F3=Exit F4=Prompt
F12=Cancel
F6=Insert line
F13=Services
F9=Retrieve
F10=Copy line
F24=More keys

Figure 9-38. Interactive SQL: Enter SQL Statements panel
OL629.0
Notes:
To use the native IBM i interactive SQL interface, you must first enter the STRSQL
command. There are a number of parameters that should be checked when you enter the
command. They include such things as the date format and the naming convention used to
reference database files. You can use the normal i library/file convention or the SQL
schema.table convention in queries.
Notice that the sessions history is saved in a fashion similar to that of QCMD. You can
retrieve queries using your cursor and F9. In the history, you can see the completion and
error messages as well.
On this display, you enter your SQL statements one at a time. This is an interactive
environment.
F4=Prompt displays a list of SQL statements, most of which can be prompted as well.
This tool is best suited as a prototyping tool to test individual SQL statements.

V8.0
Student Notebook
Uempty
Create CLASSPF table with interactive SQL

IBM i

===>create________________________________________________________
_
___________________________________________________________________
___________________________________________________________________
_
_
_
_
_
_
_
_
_
_
Bottom
F3=Exit
F4=Prompt
F12=Cancel
F6=Insert line
F13=Services
F9=Retrieve
F10=Copy line
F24=More keys

Figure 9-39. Create CLASSPF table with interactive SQL
OL629.0
Notes:
1. From a command line, enter STRSQL
2. Type CREATE
3. Press F4=Prompt.

9-51
Student Notebook
Select a CREATE statement

IBM i
Select CREATE Statement

1.
2.
3.
4.
5.
6.
CREATE
CREATE
CREATE
CREATE
CREATE
CREATE
ALIAS
COLLECTION
INDEX
PROCEDURE
TABLE
VIEW
Selection
5
F3=Exit
F12=Cancel

Figure 9-40. Select a CREATE statement
OL629.0
Notes:
This is the resulting screen from the F4 prompt of the create statement. Note that you can
now choose which SQL object you would like to create. By selecting option 5, you can
create a table and the panel for defining a table appears next.

V8.0
Student Notebook
Uempty
Panel for defining a table

IBM i
Specify CREATE TABLE Statement

Type information, press Enter.
File . . . . . . . . . .
Library . . . . . . .
Nulls:
Name
Name, F4 for list
1=NULL, 2=NOT NULL, 3=NOT NULL WITH DEFAULT
Field
crscode
crstitle
instno
instlname
FOR Field
Type
char
char
char
char
Length
4
7
3
7
File CONSTRAINT . . . . . . . . . . . . .
Distributed File . . . . . . . . . . . . .
F3=Exit
F4=Prompt
F11=Display more attributes
F5=Refresh
F12=Cancel
N
N
Scale
Nulls
3
3
3
3
3
3
3
Bottom
Y=Yes, N=No
Y=Yes, N=No
F6=Insert line
F14=Delete line
F10=Copy line
F24=More keys

Figure 9-41. Panel for defining a table
OL629.0
Notes:
A table
Has an unique name, such as EMPLOYEE

Consists of rows and columns
All values in one column are the same data type
0, () (blank), and NULL are different values
Every column is available in an SQL statement
Is created as physical file
- Maximum number of columns is 8000
- Maximum length of a row is 32766 bytes
- Update/Add/Delete capable
- Size = *NOMAX
- Contiguous = *NO
- Allocate = *NO
- Name length = 30
This is how the panel for defining a table initially appears.


9-53
Student Notebook
The Specify CREATE TABLE Statement panel lets you define a table (file).
In the File/Library field, type the name of the file to be created. The name must not be the
name of an index or file that already exists in the library. Library is the name of the library
where the file is created. Use F20 to type or display a name that is longer than the prompt.
A trailing greater than symbol (>) indicates that the entire name is not displayed.
In the Field field, type the column (field) names of the table (file). Do not use the same
name for more than one column of the table (file) or the system column name of the table
(file). You can define up to 8000 columns. Use F20 to type or display a name that is longer
than the prompt. A trailing greater than symbol (>) indicates that the entire name is not
displayed.
In the FOR Field field, type the FOR column (field) name for the column (field). This name
is optional. If the column (field) name is more than 10 characters long and the FOR column
(field) name is not specified, one will be generated when the table is created. The FOR
column (field) name may also be referred to as the system column (field) name.
Notice that there is no place to specify an index or key field (column). SQL tables are arrival
sequence files.
Notice that a more descriptive column heading, as was entered using the COLHDG keyword
in DDS, cannot be specified on this display. They can be entered later with a LABEL ON
statement.

V8.0
Student Notebook
Uempty
In the Type field, select the type of data. The possible choices include the following:
INTEGER (INT): A large integer. If INTEGER is selected, do not specify length and
scale.
SMALLINT: A small integer. If SMALLINT is selected, do not specify length and scale.
FLOAT: A floating-point number. If FLOAT is selected, precision (length) should be
specified but not scale. If length is between is 1 and 24 inclusive, the format is that of
single precision floating-point. If length is between 25 and 53 inclusive, the format is that
of a double precision floating-point. If length is not specified, the default is 53. If a single
precision floating-point (REAL) or a double precision floating-point (DOUBLE
PRECISION) is specified, do not specify length and scale.
NUMERIC: A zoned decimal number. The first integer is the precision of the number
(total number of digits) which can range from 1 to 31. The second integer is the scale of
the number (number of digits to the right of the decimal point) which can range from 0 to
the precision. If NUMERIC is selected, precision (length) and scale should be specified.
If you specify length but not scale, the default for scale is 0. If you omit both length and
scale, the default for length is 5 and the default for scale is 0.
DECIMAL (DEC): A decimal number. The first integer is the precision of the number
(the total number of digits) which can range from 1 to 31. The second integer is the
scale of the number (the number of digits to the right of the decimal point) which can
range from 0 to the precision. If DECIMAL is selected, precision (length) and scale is
specified. If you specify length, but not scale, the default for scale is 0. If you omit both
length and scale, the default for length is 5 and the default for scale is 0.
CHARACTER (CHAR): A fixed-length character string. The length (specified by an
integer) can range from 1 to 32766 (32765 if null capable). For mixed data, the range is
4 to 32766 (32765 if null capable). If precision (length) is omitted, 1 character is the
default. If CHAR is selected, length can be specified but not scale.
VARCHAR (CHARACTER VARYING, CHAR VARYING): A variable-length character
string. All values of the string have the same maximum length determined by the length
attribute of the column. The length must be specified as an integer. Length can be from
1 to 32740 (32739 if null capable).
LONG VARCHAR (not valid for DECLARE PROCEDURE): A variable-length
character string whose maximum length is determined by the amount of space available
in the row.
DATE: A three-part value (year, month, day) designating a point in time under the
Gregorian calender. The range of the year part is 1 to 9999, beginning with the year 1
A.D. The range of the month part is 1 to 12. The range of the day part is 1 to 28, 29, 30,
or 31 depending on the month. Length and scale cannot be specified.
TIME: A three-part value (hour, minute, second) designating a time of day under a
24-hour clock. The range of the hour part is 0 to 24. The range of the other two parts is
0 to 59. If the hour is 24, the minute and second parts are both 0. Length and scale
cannot be specified.
TIMESTAMP: A seven-part value that designates a date and time under the Gregorian
calendar. The seven parts are
- Year - range is 1 to 9999

9-55
Student Notebook
- Month - range is 1 to 12
- Day - range is 1 to 28, 29, 30, or 31, depending on the month
- Hour - range is 1 to 24
- Minute - range is 0 to 59
- Second - range is 0 to 59
- Microsecond - range is 0 to 999999
Length and scale cannot be specified.
GRAPHIC: A graphic data is used. If you do not specify a length, the default of 1 is
used. The range is 1 to 16383 (16382 if null capable). Length can be specified. Scale
VARGRAPHIC: A variable-length graphic data type is used. You must specify a length.
The range is 1 to 16370 (16369 if null capable). Scale cannot be specified.
LONG VARGRAPHIC (not valid for DECLARE PROCEDURE): A variable-length
graphic string whose maximum length is determined by the amount of space available
in the row.
REAL: For precision floating-point. Length and scale cannot be specified.
DOUBLE PRECISON (DOUBLE): For double precision floating-point. Length and scale
CLOB(CHARACTER LARGE OBJECT or CHAR LARGE OBJECT): A variable-length
character string that can be from 1 to 15 megabytes (15,728,640) long. The length can
be specified as integer, integer K (kilobyte), or integer M (megabyte). Scale cannot be
specified.
BLOB (BINARY LARGE OBJECT): A variable-length binary string that can be from 1 to
15 megabytes (15,728,640) long. The length can be specified as integer, integer K
(kilobyte), or integer M (megabyte). Scale cannot be specified.
DBCLOB: A variable-length double-byte character string that can be from 1 to 15
megabytes (15,728,640) long. The length can be specified as integer, integer K
(kilobyte), or integer M (megabyte). Scale cannot be specified.
DATALINK: A variable-length string which contains a Uniform Resource Locator (URL).
Length can be from 1 to 32718 (32717 if nullable). Scale cannot be specified.
distinct type: The name of an object that exists on the system, type *SQLUDT, which
contains type information. This can be library qualified. Length and scale cannot be
specified.
Length: Type the number of characters for characters and graphic data types or the
precision if numeric.
Scale: Type the number of digits to the right of the implied decimal point. The default for
scale is 0.
Nulls: Select the null attribute to used for the specified column. The possible choices are
1=NULL: Allows null values in the specified column (field).
2=NOT NULL: Does not allow null values in the specified column (field), and no default
is provided.

V8.0
Student Notebook
Uempty
3=NOT NULL WITH DEFAULT: Does not allow null values in the specified column
(field), but provides the default for the data shown below
Data Type
CHAR
VARGRAPHIC
VARCHAR
GRAPHIC
DATE
TIME
TIMESTAMP
Numeric Types
Default
Blanks
Empty string
Empty string
DBCS or UCS2 blanks
Current date
Current time
Current timestamp
0
Table (File) CONSTRAINT: Indicates whether or not table (file) constraints have been
defined for this table (file). To define table (file) constraints, type Y in the Table (file) prompt
and press Enter.
Distributed Files: Indicates whether or not this file is defined as s distributed file. A
distributed file has its data partitioned across a group of systems. To define file distribution
attributes, type Y in the Distributed File prompted and press Enter.

9-57
Student Notebook
Enter SQL statements

IBM i

> CREATE TABLE RDBLIB/CLASSPF (CRSCODE CHAR (4 ) NOT NULL WITH
DEFAULT, CRSTITLE CHAR (7 ) NOT NULL WITH DEFAULT, INSTNO CHAR (3 )
NOT NULL WITH DEFAULT, INSTLNAME CHAR (7 ) NOT NULL WITH DEFAULT)
Table CLASSPF created in RDBLIB.
===> ___________________________________________________________________________
_
_
_
_
_
_
_
_
_
_
Bottom
F3=Exit
F4=Prompt
F6=Insert line
F9=Retrieve
F10=Copy line
F12=Cancel
F13=Services
F24=More keys

Figure 9-42. Enter SQL statements
OL629.0
Notes:
Once all of the columns have been defined, press Enter and the Enter SQL Statements
panel is shown. The SQL CREATE TABLE statement that resulted from the prompt panel is
shown.

V8.0
Student Notebook
Uempty
SELECT statement
IBM i
SELECT . . . .
FROM . . . .
WHERE . . . .
GROUP BY . . . .
HAVING . . . .
ORDER BY . . . .
Clauses must be used in this order.

Figure 9-43. SELECT statement
OL629.0
Notes:
The SELECT statement is the data retrieval statement in SQL. The SELECT statement is
composed of the verb SELECT and a number of clauses known as predicates. These
predicates must be coded in a specific order.
A predicate specifies a condition that is true, false, or unknown about a given row or group.
FROM: The FROM clause specifies that an intermediate result table is to be produced.
If only one table or view is specified, the intermediate result table is simply that table or
view.
WHERE: The WHERE clause specifies that an intermediate result table is to be
produced. It will consist of a grouping of those rows of a result set from the SELECT for
which the search condition is true.
GROUP BY: The GROUP BY clause specifies that an intermediate result table is to be
produced. It will consist of a grouping of the rows of the result set of the SELECT.

9-59
Student Notebook
HAVING: The HAVING clause specifies that an intermediate result table is to be

produced. It will consist of those groups of the result set of the SELECT for which the
search condition is true.
ORDER BY: The ORDER BY clause specifies an ordering of the rows of the result
table. If a single column is identified, the rows are ordered by the values of that column.
If more than one column is identified, the rows are ordered by the values of the first
identified column, then by the values that the second identified column, and so on. Each
column specified can be ordered in either ascending or descending order.
The clauses must be coded in this order. When using interactive SQL, the F4 key will
prompt the correct order. When coding embedded SQL statements in a high-level
language, you will need to know the order.
When coding, you should place each keyword of the SELECT on a separate line and
indent it as shown in the visual. Your code will be more easily debugged and maintained.
SELECT statements can also be nested in what are known as subselects. A subselect,
when used, is a component of the fullselect, the CREATE VIEW statement, and the
INSERT statement. A fullselect specifies a result table that is to be generated. The
subselect is also a component of certain predicates which, in turn, are components of a
subselect. A subselect that is a component of a predicate is called a subquery.

V8.0
Student Notebook
Uempty
How the SELECT looks during prompting

IBM i
Specify SELECT Statement

Type SELECT statement information.
FROM files . . . . .
SELECT fields . . .
WHERE conditions . .
GROUP BY fields . .
HAVING conditions .
ORDER BY fields . .
FOR UPDATE OF fields
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Press F4 for a list.
RDBLIB/CUSTOMER__________________________
*________________________________________
CRSCODE = 'L001_________________________
_________________________________________
_________________________________________
STUDNO___________________________________
Bottom
DISTINCT records in result file . . . . . . . .
UNION with another SELECT . . . . . . . . . . .
Specify additional options . . . . . . . . . . .
F3=Exit
F10=Copy line
F4=Prompt
F12=Cancel
N
N
N
Y=Yes, N=No
Y=Yes, N=No
Y=Yes, N=No
F5=Refresh
F6=Insert line
F9=Specify subquery
F14=Delete line
F15=Split line
F24=More keys

Figure 9-44. How the SELECT looks during prompting
OL629.0
Notes:
Type select into the interactive SQL display and press F4 to prompt. This display allows
keying the needed clauses to complete your select statement.

9-61
Student Notebook
Resulting query
IBM i
Display Data
Data width . . . . . . :
Position to line . . . . .
Shift to column . . . . . .
....+....1....+....2....+....3....+
Crs
Cls
Cls Stu Student Stu
Code Yr
Qtr No
Name
Grd
L001 1999
1
101 BOWIE
93
L001 1999
1
102 LAUPER
72
L001 1999
1
103 TURNER
79
L001 1999
2
105 MADONNA
L001 1999
3
107 STING
******** End of data ********
35
Bottom
F3=Exit
F12=Cancel
F19=Left
F20=Right
F21=Split

Figure 9-45. Resulting query
OL629.0
Notes:
If the SELECT is successful, the result set is displayed.

V8.0
Student Notebook
Uempty
9.5. IBM i Access: System i Navigator

9-63
Student Notebook
Powertm with IBM i

Figure 9-46. IBM i Access: System i Navigator
8.1
OL629.0
Notes:

V8.0
Student Notebook
Uempty
Starting System i Navigator

IBM i
System i Navigator icon

Desktop icon
Start menu
Client Access
folder
Context menu
for IBM i System
Connection
Default view

Figure 9-47. Starting System i Navigator
OL629.0
Notes:
IBM i Access for Windows offers an all-inclusive client solution for accessing and using
resources from your Windows desktop. It includes 5250 emulation and access to DB2 for i
database through its Data Transfer, and it utilizes IBM i NetServer for working with the IBM
i/OS integrated file system and printers. It also has a variety of middleware for using and
developing client applications to access IBM i/OS resources and System i Navigator, the
IBM i/OS GUI, for administering IBM i and AS/400 servers.
You can access the System i Navigator component of IBM i Access by doing any of the
following:
Clicking the System i Navigator icon in the IBM i Access folder.
Clicking the System i Navigator icon on your desktop.
Click Start > Programs > IBM i Access for Windows > System i Navigator.

9-65
Student Notebook
What is System i Navigator?

IBM i
Graphical user interface

End users
Work with printers and printer output
Work with messages
Administrators and system operators

Managing jobs
Inventory
Configuring network servers
Managing security
Work with users and groups
Database administration
Managing file systems
Perform backups, and much more
Figure 9-48. What is System i Navigator?
OL629.0
Notes:
System i Navigator is the graphical user interface to the system. Many of the features are
oriented to system administration. You should be aware of these features and their
capabilities. The following are features that you, as programmers, will use:
Browse libraries and files

Create new libraries, schemas and files
Explore the properties of files
Modify authorities to objects
Browse OUTQs
Use Run SQL Scripts to access and modify DB objects using SQL

V8.0
Student Notebook
Uempty
Integration with Windows

IBM i
System i Navigator
Point and click (buttons, checkbox)
Drag and drop (windows, context menus)
Green screen
Enter CL commands
Navigate i menus

Figure 9-49. Integration with Windows
OL629.0
Notes:
Benefits of the System i Navigator interface
Administering the IBM i is easier.
Windows users can use System i Navigator to administer an IBM i. This reduces the
need to learn the IBM i command interface. The user interface is what a Windows user
would expect.
Integrates the IBM i into the Windows environment using IBM i Access.
The System i Navigator is fully integrated into the Windows desktop. This means that the
administrator can perform IBM i tasks using Windows techniques. For example, you can do
the following:
Drag and drop a user onto a group to add that user to the group
Use Context menus and Property sheets to display or change information (for example,
change access authority to a database object)
Use the Explorer view of IBM i resources. The Explorer offers various views, such as
small or large icons, a list, or details.

9-67
Student Notebook
File systems
IBM i

Figure 9-50. File systems
OL629.0
Notes:
The integrated file system (IFS) is a part of IBM i/OS that supports stream input/output and
storage management. Similar functionality exists on personal computers. It also provides
an integrated structure for all information stored in the system (for example, stream files,
database files, directories, folders, and documents).
A file system provides you with the support to access specific segments of storage that are
organized as logical units. On your server, these logical units are files, directories, libraries,
and objects. Each file system has a set of logical structures and rules for interacting with
information in storage. These structures and rules may be different from one file system to
another. In fact, from the perspective of structures and rules, IBM i/OS support for
accessing database files and various other object types through libraries can be thought of
as a file system. Similarly, i5/OS support for accessing documents (which are really stream
files) through the folder structure may be thought of as a separate file system.
You can find objects in the IFS by clicking Edit in the Menu bar and then clicking Find. Use
the Find dialog to search a list for a string of characters.

V8.0
Student Notebook
Uempty
The key features of the integrated file system are the following:
Support for storing information in stream files that can contain long, continuous strings
of data, for example, the text of a document or the pixels in a picture. The stream file
support is designed for efficient use in client/server applications.
A hierarchical directory structure that allows objects to be organized in a branch-like
structure. Specifying the path through the directories to an object accesses the object.
A common interface that allows users and applications to access not only the stream
files but also database files, documents, and other objects that are stored in your
server.
A common view of stream files that are stored locally on your server, an Integrated
xSeries server for i, or a remote Windows NT server. Stream files can also be stored
remotely on a Local Area Network (LAN) server, a Novell NetWare server, another
remote IBM i server, or a network file system server.
To provide a transparent environment for the clients, IBM i/OS integrates the various file
systems shown below. It is not important that the student understand what all these file
systems are; only that there are many file systems available on the i system.
root (/): The root (/) file system, which takes full advantage of the stream file support
and hierarchical directory structure of the integrated file system. The root file system has
the characteristics of the disk operating system (DOS) and Windows file systems.
QOpenSys: The open systems file system, such as POSIX and XPG. Like the root file
system, this file system takes advantage of the stream file and directory support that is
provided by the integrated file system. In addition, it supports case-sensitive object names.
UDFS: The user-defined file system, which resides on the auxiliary storage pool (ASP) or
an independent auxiliary storage pool of your choice. You create and manage this file
system.
QSYS.LIB: The library file system, which supports the library structure on your server. This
file system provides access to database files and all of the other i server object types that
the library support manages in the system and basic user ASPs.
Independent ASP QSYS.LIB: The independent ASP QSYS.LIB file system, which
supports your server library structure in any independent auxiliary storage pools (ASPs)
you create and define. This file system provides access to database files and all of the
other i server object types that the library support manages.
QDLS: The document library services file system. This file system provides access to
documents and folders.
QOPT: The optical file system, which provides access to stream data that is stored on
optical media.
QNetWare: The QNetWare file system, which provides access to local or remote data,
objects that are stored on a server that runs Novell NetWare 4.10 or 4.11, and standalone

9-69
Student Notebook
PC servers running Novell NetWare 3.12, 4.10 4.11 or 5.0. You can dynamically mount
NetWare file systems on top of existing local file systems.
QNTC: The Windows NT server file system, which provides access to data and objects that
are stored on a server running Windows NT 4.0 or higher. It allows IBM i server
applications to use the same data as Windows NT clients. This includes access to the data
on a Windows NT server that is running on an integrated PC server. See i5/OS-iSeries
Integration with Windows NT Server, SC41-5439-01 (SC41-5439) for details.
QFileSvr.400: This file system provides access to other file systems that reside on remote
i servers.
NFS: Network file system, which provides you with access to data and objects that are
stored on a remote NFS server. An NFS server can export a network file system that NFS
clients will then mount dynamically.

V8.0
Student Notebook
Uempty
File shares
IBM i

Figure 9-51. File shares
OL629.0
Notes:
IBM i NetServer enables a shared directory in the IFS root to be mapped as a network drive
on a PC. Therefore, PC files may be stored on the i, which is very convenient for archiving,
sharing data, and performing backup and recovery actions.
This function allows you to do the following:
Display the list of NetServer shares
Open IBM i NetServer management panel
When clicking with the right button of the mouse on a share
-
Open the file share

Start Windows Explorer with the file share opened
Map a network drive to the file share
Display and modify the share properties

9-71
Student Notebook
Database
IBM i

Figure 9-52. Database
OL629.0
Notes:
The database component of System i Navigator provides a graphical interface for many
DB2 for i database operations including the following:
Creating and managing tables, views, and aliases with SQL
Creating and managing IBM i/OS journals
Creating libraries or SQL collections
Creating external or SQL procedures
Creating external, SQL, or sourced functions
Defining new types
Creating or modifying ODBC data source
Entering new or modifying already created SQL statements
Running and debugging previously created SQL statements (referred to as scripts)

V8.0
Student Notebook
Uempty
Doing performance analysis on your SQL statements using Visual Explain (V4R5 and
later)
Using SQL performance monitor to keep track of the resources your SQL statements
use. You can monitor specific resources or many resources. The information on
resource use can help you determine whether your system and your SQL statements
are performing as they should or whether they need fine tuning.
The database component of Operation Navigator supplies an SQL graphical interface to
manage the DB2 for i database. SQL vocabulary is different from the traditional terms used
on the IBM i. The following list illustrates some equivalences
Collection/Schema = library
Table = physical file
View = logical file without key
Index = logical file with key
Column = field
Row = record

9-73
Student Notebook
Open a table
IBM i

Figure 9-53. Open a table
OL629.0
Notes:
Right-click a table in the list to display the Context menu. This menu shows the different
actions that can be performed on the selected object.
Edit Contents allows the full range of file operations. Column values may be changed and
rows may be inserted or deleted: All very easily! Some security precautions should be
taken to reduce the risk of file corruption: Accidental or deliberate.
The View Contents selection allows the data to be viewed (inquiry).

V8.0
Student Notebook
Uempty
Table properties
IBM i

Figure 9-54. Table properties
OL629.0
Notes:
This panel is displayed when you select the Definition of an existing table or when you
create a new table.
Using this panel, you can do the following:
Modify a column description
Insert a column manually
Insert a column using the Browse button
Delete a column
Manage key constraints
Manage indexes
Manage referential constraints
Manage triggers
Manage check constraints

9-75
Student Notebook
Additional functions that can be done on a table include the following:

Display the table description (equivalent to DSPFD command) - V4R5 only
Start/manage journaling a table
Display locked rows - V4R5 only
Create an alias
Reorganize the table (equivalent to RGZPFM)
Work with permissions (equivalent to EDTOBJAUT plus the option to set column
authorities)
Cut, copy, rename, and delete the file

V8.0
Student Notebook
Uempty
Run SQL scripts

IBM i

Figure 9-55. Run SQL scripts
OL629.0
Notes:
This is how the System i Navigator Run SQL Scripts window is used.
1. Right-click the database name (the system name in this case).
2. Select Run SQL Scripts.
3. You can use one of the templates to construct your SQL statement by selecting Edit >
Insert from Examples. You may enter one or more SQL statements, separated by
semicolons. If you only enter one statement, the use of the semicolon is optional;
however, it is good practice to always enter the semicolon.
4. We enter our SQL statement.
5. Select the SQL statement.
6. In the menu, select Run > Selected.
The result set is presented in a separate window. Notice that there are two tabs.
1. Messages tells you whether your query was successful, what errors were encountered,
if any, and so forth.
2. The other tab (shown in the visual) displays the result set. Sometimes, the number of
rows is too wide or too many to display conveniently. In the Options menu, you can
select Display Results in a Separate Window.

9-77
Student Notebook
Data Transfer Excel Add-in install

IBM i

Figure 9-56. Data Transfer Excel Add-in install
OL629.0
Notes:
If you want to use Excel in order to transfer data from your PC to the IBM i or from the IBM
i to your PC, the Data Transfer Excel Add-in has to be installed as a separate component.
Right-click the My connections folder. Select Install Options > Install Plug-Ins in order
to see a list of available plug-ins to add.

V8.0
Student Notebook
Uempty
Microsoft Excel: Transfer data

IBM i

Figure 9-57. Microsoft Excel: Transfer data
OL629.0
Notes:
After installation of the Add-in, new menu items are installed in Excel under the Data menu
in the toolbar.

9-79
Student Notebook
Creating a schema with System i Navigator

IBM i

Figure 9-58. Creating a schema with System i Navigator
OL629.0
Notes:
The first thing we will need to do is create a schema that will hold our class database
objects.
1.
2.
3.
4.
Right-click Schemas.
Select New > Schema.
Complete the fields in the window.
Click OK.
Notice that the option to add the new schema to the list of displayed libraries is checked by
default. Doing this does not modify your library list. A more permanent solution would be to
change your library list in your job description to include the new library (schema).
You should recall that a schema contains objects just like a library; however, SQL
automatically creates a catalog as well as a journal and a journal receiver.
When a table, view, or index is created, it is assigned to exactly one schema. That is, when
you create a table, you assign it to a specific schema in the CREATE statement in a
manner similar to the way in which you assign a file to a library.

V8.0
Student Notebook
Uempty
SQL schema
IBM i

Figure 9-59. SQL schema
OL629.0
Notes:
To display the contents of the new schema, double-click the schema (OL62T01). Click All
Objects.
In the right side of the window, you can see that the schema contains a journal, a journal
receiver, and several views that are collectively known as an SQL catalog.

9-81
Student Notebook
Using System i Navigator

IBM i
Create table = create PF
Create view = create not keyed LF

Figure 9-60. Using System i Navigator
OL629.0
Notes:
To create a new table in the OL62T01schema, do the following:
1. Right click OL62T01.
2. Select New > Table > Table.
3. Select Table.
4. Name the table you want to create and enter a description.
5. Click OK.

V8.0
Student Notebook
Uempty
Create new table: GRADEPF99 add fields

IBM i
Browse column
definitions of
another table
Insert new field

Figure 9-61. Create new table: GRADEPF99 add fields
OL629.0
Notes:
This is the window presented to define the columns in a table.This visual shows you the
completed field definitions for the table and the New Column window.
Caution: Do not click OK until each column is defined. Clicking OK causes the table to be
created. Use the cursor and tab keys to navigate between different column definitions and
fields.
Once the table is created, column name and type cannot be changed. The table must be
dropped and recreated.
This window is used to define a new table. It provides for the name, data type, and length
for each column for a new table and shows you the information for an existing table. The
description of a column is optional when creating a new table.
There are some further details that we can describe here now that you are seeing this
window for the second time.
As you create a new column, the arrow to the left is positioned next to the column you are
defining.

9-83
Student Notebook
There are many data types supported by SQL. You select the data type for each column as
you enter it (VARGRAPHIC, DATE, TIME, TIMESTAMP, DATALINK, CLOB, BLOB,
DBLOB). Some data types have a predetermined size; the size is already filled in and you
cannot change the value.
New Table-Column
You can define the following additional properties for the currently selected column in
the grid for a new table.
Short column name
Allows you to specify a short i5/OS name for the column. If you do not specify a name,
the i generates a name for you. If your column name is longer than 10 characters, a 10
character short column name is generated for you using the first five characters of the
column name followed by a five digit unique number.
Heading
Defines the column heading that is used when displaying or printing query results. You
are limited to 60 characters, 20 per line.
Must contain a value (not null)
Prevents the column from containing null values.
We have built our basic tables.
Once a table has been populated with data it can be displayed by double-clicking the table
name from the main System i Navigator window.

V8.0
Student Notebook
Uempty
New View: CLSGRDIJ99

IBM i

Figure 9-62. New View: CLSGRDIJ99
OL629.0
Notes:
1. From the main System i Navigator window, right-click library OL62T01, select New, and
then select View.
2. Enter view name and description.
3. Click OK.
The New View dialog creates a view on a table or tables of your choice. A view provides an
alternative way of looking at the data in one or more tables.
Views are useful because all users do not need to look at the data in the same way. Some
users operate directly on the real tables that are stored in the database while other users
operate on views, which are virtual tables derived in some way from the real tables.
For example, several users may be sharing a table of data on employee salaries. One user
might see all the salaries of employees who report to her, and another user might see only
the average salaries for each level.

9-85
Student Notebook
A view can include all or some of the columns contained in the table or tables on which it is
defined. A view cannot refer to more than 32 real tables, including tables referred to in
underlying views.
The Browse Tables dialog allows you to choose entire tables or specific columns from
existing tables to include in the view. Expanding a library shows the tables in that library.
To select a table, drag the table you want from the Browse Tables dialog and drop it in the
work area at the top of the New View dialog.
If you want to include all or most of the columns from one table in the view, you can drag a
table from the Browse Tables dialog and drop it in the selection grid on the New View
dialog. All the columns in the table will be added to the grid. You can only have a single
instance of any one table in a work area.
The work area provides a space for you to choose the tables and joins on which the new
view will be based. You can also define the join conditions for the new view.
Selecting a column in the table and dragging it into the selection grid adds the column to
the view.
The Select Rows dialog allows you to construct a WHERE clause as part of your SQL
statement.
The WHERE clause specifies a search condition that is used for selecting the desired rows.
When a WHERE clause is used with a GROUP BY clause, the WHERE clause serves as a
filter that is applied before the forming of groups so that only those rows that satisfy the
search condition are retained.
Click to select a column, operator, or function.
Double-click to add the selection to the clause. The clause is constructed in the Clause box
below.
Operators
*
/
+
<
<=
=
>
>=
AND
OR
CONCAT
Multiplication
Division
Addition
Less than
Less than or equal to
Equal to
Greater than
Greater than or equal to
Logical AND
Logical OR
Concatenation

V8.0
Student Notebook
Uempty
Functions
All: Lists all functions

Conversion: Lists all scalar functions that convert from one data type to another
Date and Time: Lists all scalar functions relating to data and time
Logical: Lists all scalar functions relating to logical operators
Mathematical: Lists all scalar functions relating to mathematical functions
Summary: Lists all column functions
Text: Lists all scalar functions that work with character strings
Selection grid: If you want to include all or most of the columns from one table view,
you can drag a table from the Browse Table dialog and drop it in the selection grid. All
the columns in the table are then added to the grid, and the table is added to the work
area.
If you want to choose the columns to be included in the view, you can drag a table from the
Browse Tables dialog and drop it in the work area. Then drag the column you want into the
grid by the column name.
The following is a description of the selection grid:
Table field: Indicates the table from which the column will be retrieved
Column field: Names the column in the view. Column headings are used when
displaying or printing query results. The first column heading is displayed (or printed) on
the first line. The second column heading is displayed on the second line. The third
column heading is displayed on the third line. The column headings can be up to 60
bytes in length. The first 20 bytes is the first column heading. The second 20 bytes is
the second column heading. The third 20 bytes is the third column heading. Blanks are
trimmed from the end of each column heading. Changing a column name results in a
new column list being generated for the CREATE VIEW statement.
Description field: Describes the column
Column heading field: Indicates the name for each column. Do not use the same
name for more than one column in the view.
Group field: An X in this column for a row indicates that the table column will be
included in the GROUP BY clause. This field is toggled on and off for all columns when
selected.
Formula: The Formula dialog allows you to construct a formula. Click to select a
column, operator, or function. Double-click to add the selection to the clause. The
clause is constructed in the Clause box below.

9-87
Student Notebook
New View: Join Properties

IBM i

Figure 9-63. New View: Join Properties
OL629.0
Notes:
1. Drag CRSCODE of CLASSPF and drop it on CRSCODE of GRADEPF99.
2. Select the type of join.
The Join Properties dialog lets you define the way two tables are joined to produce an
intermediate result table. A join is an operation that allows the program to retrieve data
from two or more tables based on a join relationship. The results table consists of only the
rows that satisfy the join condition based on the type of join specified. Tables are always
joined from left to right, from column name to column name.

V8.0
Student Notebook
Uempty
The Join Type specifies the way two tables are joined to produce an intermediate results
table. The result table consists of only rows that satisfy the join condition based on the type
of join specified.
Inner join: This conventional join includes only rows in the left and right table that meet
the join criteria. Rows that have no matching value are not included in the result table.
Left outer join: Includes rows from the left table that do not meet the join criteria in the
right table. The columns in the rows from the right table are given null values.
Right Outer Join: New with V5R1, this is the converse of the left outer join.
Exception join: Specifies that only the rows in the table to the left that have no
corresponding rows in the table to the right are returned. The columns in the rows from
the right table are given null values.
Cross join: Specifies that the result table will contain a row from the table to the left
concatenated with each row from the table to the right. A join condition is not allowed.

9-89
Student Notebook
New View: Join Condition

IBM i

Figure 9-64. New View: Join Condition
OL629.0
Notes:
1. Click Join Condition to view the join condition.
2. Click OK.
The Join Condition dialog allows you to define the join condition for the type of join desired.
The default join type is an inner join, which includes only rows in the left table that have
matching values in the right table. The two selected columns are entered in the Clause box
with the equal to (=) operator between them.
Click to select a column or function.
Double-click to add the selection to the clause.
The clause is constructed in the Clause box. Column functions are not allowed in a join
condition.

V8.0
Student Notebook
Uempty
New View: CLSGRDIJ99

IBM i

Figure 9-65. New View: CLSGRDIJ99
OL629.0
Notes:
The New View window is displayed.
Notice the line connecting the CRSCODE columns in both tables. This is the column that
was dragged from one table and dropped onto the other table.
1. Drag and drop each column or field that is desired in the view to the bottom grid.
The Select Rows dialog allows you to construct a WHERE clause as part of your SQL
statement. The WHERE clause specifies a search condition that is used for selecting the
desired rows. When a WHERE clause is used with a GROUP BY clause, the WHERE
clause serves as a filter that is applied before the forming of groups so that only those rows
that satisfy the search condition are retained.
1. Click to select a column, operator, or function.
2. Double-click to add the selection to the clause. The clause is constructed in the Clause
box.

9-91
Student Notebook
The Summary Rows dialog which allows you to construct a HAVING clause is usually used
in conjunction with a GROUP BY clause. In these instances, the WHERE clause is applied
first as a filter on rows. The groups are then formed, and the HAVING clause is applied as
a filter on groups. When a HAVING clause is used without a GROUP BY clause, the entire
table is treated as one group.

V8.0
Student Notebook
Uempty
New View: Show Generated SQL

IBM i

Figure 9-66. New View: Show Generated SQL
OL629.0
Notes:
1. Click Show SQL to see the generated SQL statement.
2. Click OK.

9-93
Student Notebook

V8.0
Student Notebook
Uempty
9.6. Query for IBM i and Query Manager: QRY

9-95
Student Notebook
Query for IBM I Query Manager
Powertm with IBM i

Figure 9-67. Query for IBM I Query Manager
8.1
OL629.0
Notes:

V8.0
Student Notebook
Uempty
IBM i query products

IBM i
Query for IBM i

Easy database report writing against database files and tables
Not built on SQL
Programmer or end-user tool
Query Manager
Easy database report writing
Interface for SQL and IBM i Query Management
Creation and maintenance of queries, report forms, and database files
and tables
IBM i Query Management

An application programming interface to the SAA Query CPI
(Common Programming Interface). Application programs use query
management services through a program to program callable
interface using Query for IBM i/OS objects. Not an end-user tool.
Figure 9-68. IBM i query products
OL629.0
Notes:
The DB2 for i Query Manager and SQL Development Kit program contains the following
functions, which assist users and application developers to write SQL queries and
application programs for the database manager:
Query Manager is an interactive query and report generator that allows users to define
and run queries accessing DB2 databases. Data edit and report capabilities are also
provided.
The SQL Development Kit provides precompilers for processing SQL statements
embedded in the following programming languages:
-
COBOL/400 and ILE COBOL

C and C++
RPG/400 and ILE RPG IV
PL/I
REXX (part of IBM i/OS)

9-97
Student Notebook
Interactive SQL is a query environment that allows users and programmers to enter and
start SQL interactively.
SQL statement processor allows SQL statements in a source member to be run.
This product is required only for Query Manager and SQL application development. Once
created, these applications can be run on other i systems without this product installed,
using the database manager support provided with IBM i/OS.
Users of the Development Kit include the following:
An application programmer who codes embedded SQL

A user of the interactive SQL
A user of Query Manager
A user of the Run Structured Query Language Statements (RUNSQLSTM) command

V8.0
Student Notebook
Uempty
Query Manager and Query for IBM i: Similarities

IBM i
Create reports on database files or tables created with DDS,

SQL, or IDDU
Report based on 1-32 tables and files
Selection and sorting of rows and records
Selection and arranging of existing columns and fields
Can compute new fields based on existing fields
Sequence of prompts help user define the report
Can run the report even while defining it
Column totals and subtotals
Output to a display, printer, or new database file or table

Figure 9-69. Query Manager and Query for IBM i: Similarities
OL629.0
Notes:
We will not discuss the details of Query Manager and Query for IBM i/OS in this class.

9-99
Student Notebook
Query Manager and Query for IBM i: Differences

IBM i
Query Manager builds and runs SQL statements.

Query for IBM i can build and run a report completely by
default by omitting the query name.
Query for IBM i object type: *QRYDFN (query definition)
Query Manager object types: *QMQRY (Query Manager
query) *QMFORM (Query Manager report form)
Query for IBM i can perform multiple calculations on a column
of data. Query Manager can only perform one.
Query Manager saves the last query, form, and data in your
Query Manager session for reuse. This saves time but can be
confusing.
Query Manager can create tables and enter and change data
in tables.
Figure 9-70. Query Manager and Query for IBM i: Differences
OL629.0
Notes:
Query Manager can create tables. It can be used to enter and change data in tables.
Query for IBM i is slightly more user-friendly than Query Manager. Occasionally, answers to
the prompts in Query Manager result in a runtime error, while Query for IBM i gives
immediate indication of an error on the prompt display. This is probably because Query
Manager can compose a valid SQL statement, but the statement may cause an error when
run. Query Managers saving of active data report form and query can be confusing.
Finally, Query Manager requires that a query be paired with a form to produce a report. If
one is not aware of which query, set of data, and form are active, it is easy to pair them up
incorrectly and cause errors or unusable reports.

V8.0
Student Notebook
Uempty
QUERY menu: STRQRY or GO QUERY

IBM i
QUERY
Query Utilities

Query for IBM i
1. Work with queries
2. Run an existing query
3. Delete a query
DB2 for IBM i
10. Start DB2 Query Manager for IBM i
Query management
20. Work with query management forms
21. Work with query management queries
22. Start a query
23.Analyze a Query for IBM i definition
System: EDUC3
WRKQRY
RUNQRY
DLTQRY
WRKQMFORM
WRKQMQRY
STRQMQRY
ANZQRY
More. . .
===> 1
F3=Exit F4=Prompt
F13=Information Assistant
F9=Retrieve
F12=Cancel
F16=System Main menu

Figure 9-71. QUERY menu: STRQRY or GO QUERY
OL629.0
Notes:

9-101
Student Notebook
The Query Utilities (QUERY) menu allows you to define and run queries to produce
reports from information gathered from database files. You can also delete a query
definition.
Option 1. Work with queries (WRKQRY): Select this option to do common Query for IBM
i tasks, such as the following:
Create a new query definition
Change, copy, display, or delete an existing query definition
Print the definition of a query
Run a query to select data from files and produce a report using that data
Option 2. Run an existing query (RUNQRY): Select this option to produce a query report
by
Running an existing query with or without changing some of its values
Showing the data in a file without defining a query
Option 3. Delete a query: Select this option to delete a query definition from the system.
Option 10. Start DB2 Query Manager for IBM i (STRQM): Select this option to start
Query Manager to build, manage, and run SQL queries, create reports, and use the table
editing feature of Query Manager.

V8.0
Student Notebook
Uempty
Checkpoint (1 of 2)
IBM i
1.
DFU is a program generator that helps you create programs to:

a.
b.
c.
d.
2.
In order to update an existing file with DFU without having to define a program,
use (blank).
a.
b.
c.
d.
3.
STRDFU
CHGDTA
UPDDTA
DSPDTA
Which function key (Fxx) will delete the currently displayed record from the file?
a.
b.
c.
d.
4.
Enter data into files

Update data in existing files
Make file inquiries
All the above
F11
F10
F21
F23
True or False: RSE filtering provides function similar to PDM libraries, objects,
and members.
OL629.0
Notes:

9-103
Student Notebook
Checkpoint (2 of 2)
IBM i
5. True or False: All IBM i systems access interactive SQL with the
command STRSQL.
6. True or False: A series of SQL statements can be run interactively as
a group using STRSQL.
7. True or False: The SELECT statement is the data retrieval statement
in SQL.
8. True or False: System i Navigator has a GUI interface to SQL as well
as a statement entry screen.
9. True or False: Query for IBM i and Query Manager can both be used
to run queries of data files.
10. True or False: Query Manager does not allow for creating tables.
OL629.0
Notes:

V8.0
Student Notebook
Uempty
Lab exercise
IBM i
Interface to DB2 for i

OL629.0
Notes:

9-105
Student Notebook
Unit summary
IBM i

Access DB2 with:
Data file utility: DFU
Structured Query Language: SQL
Query for IBM i and Query Manager: QRY

OL629.0
Notes:

V8.0
Student Notebook
Uempty
Unit 10. Database performance considerations for

application design
File creation parameters and application considerations for database
performance.

Describe the IBM i database performance considerations for
application design

Accountability
Copyright IBM Corp. 1997, 2013 Unit 10. Database performance considerations for application design
10-1
Student Notebook
Unit objectives
IBM i

application design

OL629.0
Notes:

V8.0
Student Notebook
Uempty
Performance considerations
IBM i
Database design
When joining physical files, the primary file should have less records
than secondary files.
Share the access path.
Use DYNSLT.
Minimize the number of logical files.
Carefully use variable-length fields.
Use multiple logical files versus multiple-format logical files.
File attributes
CRTPF, CHGPF
CRTLF, CHGLF
OVRDBF

Figure 10-2. Performance considerations
OL629.0
Notes:
If the physical files you are joining have a different number of records, specify the physical
file with fewest records first (the first parameter following the JOIN keyword).
Consider describing your join logical file so it can automatically share an existing access
path. Join logical files always have access paths using the second field of the pair of fields
specified in the JFLD keyword. This field acts like a key field in simple logical files. If an
access path does not already exist, the access path is implicitly created with immediate
maintenance.
10-3
Student Notebook
Logical file access path sharing

IBM i
LFB
PFA
R FMTA
DYNSLT
R FMTB
LFD
R FMTD
K CUSNR
S ARBAL COMP(GT 1000)
Description
K CUSNR
LFC
R FMTC
K STATE
Access Path
LFE
K STATE
K ZIP
Member
DYNSLT
R FMTB
Data
Access Path
Create LFC before LFD and LFE.
K STATE
S STATE COMP(EQ 'PA')

Figure 10-3. Logical file access path sharing
OL629.0
Notes:
When you describe a database file to the system, you describe the two major parts of that
file: the record format and the access path. An access path describes the order in which
records are to be retrieved.
DYNSLT increases the likelihood that an access path can be shared, thus potentially
reducing the number of access paths that must be maintained. Similarly, creating access
paths with composite keys makes it more likely that single key access paths created later
will not require their own access path but can share the one built from composite keys.
No specific order for duplicate key fields allows more access path sharing, which can
improve performance.

V8.0
Student Notebook
Uempty
Automatic access path sharing

IBM i
The sharing of the access path is automatic if the following is

true:
New logical file based on same physical file members
Identical key:
Type, length, and decimal positions of key fields
Order of key fields
Partial key OK (FIFO, LIFO, FCFO not allowed)
UNIQUE, LIFO, FIFO, FCFO, DESCEND, ABSVAL,
UNSIGNED, and SIGNED attributes are the same
Select/Omit same unless DYNSLT
The ALTSEQ and TRNTBL keywords are identical

Figure 10-4. Automatic access path sharing
OL629.0
Notes:
When two or more files are based on the same physical files and the same key fields in the
same order, they automatically share the same keyed sequence access path. When
access paths are shared, the amount of system activity required to maintain access paths
and the amount of auxiliary storage used by the files is reduced.
10-5
Student Notebook
When a logical file with a keyed sequence access path is created, the system always tries
to share an existing access path. For access path sharing to occur, an access path must
exist on the system that satisfies the following conditions:
The logical file member to be added must be based on the same physical file members
that the existing access path is based on.
The length, data type, and number of decimal positions specified for each key field must
be identical in both the new file and the existing file.
If the FIFO, LIFO, or FCFO keyword is not specified, the new file can have fewer key
fields than the existing access paths. That is, a new logical file can share an existing
access path if the beginning part of the key is identical; however, when a file shares a
partial set of keys from an existing access path, any record updates made to fields that
are part of the set of keys for the shared access path may change the record position in
that access path.
The attributes of the access path (such as UNIQUE, LIFO, FIFO, or FCFO) and the
attributes of the key fields (such as DESCEND, ABSVAL, UNSIGNED, and SIGNED)
must be identical.
If the new logical file has select/omit specifications, they must be identical to the
select/omit specifications of the existing access path; however, if the new logical file
specifies DYNSLT, it can share an existing access path if the existing access path has
either of the following:
- The dynamic select (DYNSLT) keyword specified
- No select/omit keywords specified
The alternative collating sequence (ALTSEQ keyword) and the translation table
(TRNTBL keyword) of the new logical file member, if any, must be identical to the
alternative collating sequence and translation table of the existing access path.
LFB can share PFA's access path because the DYNSLT keyword removes the selection
criteria from the access path.
If LFC had been created after LFD and LFE, there would be an additional access path.
IBM i/OS will automatically share access paths if it can, regardless of the file's owner of
library, if the conditions on the visual are met.

V8.0
Student Notebook
Uempty
Minimizing logical files

IBM i
HLL can read backwards

OVRDBF...POSITION(*END)
May not need two logical files
One with ascending sequence
The other with descending sequence
One with FIFO processing
The other with LIFO processing

Figure 10-5. Minimizing logical files
OL629.0
Notes:
Perhaps an access path can be avoided if the records are in the exact opposite sequence.
Languages can read backwards.
10-7
Student Notebook
Variable-length fields (1 of 4)
IBM i
Item update
Item No.: 125784
Description:
The quick fox jumped over the dog.
Physical file
R VARREC
ITEMNO
DESC
DATE
Date: 11-21-12
6 A
100 A VARLEN(35)
6 A
OVERFLOWED
Display file uses

maximum length
Physical file
125783 The lazy river flowed slowly south.
125784 The quick fox jumped over the dog.
35
Figure 10-6. Variable-length fields (1 of 4)
OL629.0
Notes:
Variable-length fields are defined with a minimum and a maximum length. The maximum
length is defined in the length field of the DDS statement. The minimum length is defined
with the VARLEN keyword with a default value of 0.
The maximum length is used except when writing to disk. When used in a display file the
maximum length is used. On disk the minimum length is allocated in the record at the point
in the record where the field is defined.

V8.0
Student Notebook
Uempty
IBM i
Item update
Physical file
R
VARREC
ITEMNO
DESC
DATE
6
100
6
A
A
A
OV
ER
F
Date: 11-21-12
VARLEN(35)
LO
WE
D
Item No.: 125784

Description:
The quick fox jumped over the lazy dog.
Physical file

125784
35
OVERFLOW AREA
Record 2 - Fld Desc - The quick fox jumped over the lazy dog.
Linkage data
Overflow data
OL629.0
Notes:
When the data entered into a variable-length field exceeds the minimum size, the data is
written to an overflow area.
The IBM i sets a flag indicating that the minimum size was exceeded so that it knows to
check the overflow area when it reads the record. In the overflow, the system must create
linkage data as well as the data. The linkage is used to tie the data back to the correct
record and field. The linkage data is approximately 25 bytes.
10-9
Student Notebook
IBM i
Physical file
R VARREC
ITEMNO
6A
DESC
100A VARLEN(35)
DATE
6A
Physical file
Date: 11-21-12
VE
RF
LO
W
ED
Item update
Item No.: 125785
Description:
The rain in Spain falls mainly on the plain.

125784
X
125785
X
35
Record 2 - Fld Desc The quick fox jumped over the lazy dog.
X
Record 3 - Fld Desc The rain in Spain falls mainly on the plain.
OVERFLOW AREA

OL629.0
Notes:
Data is written in the overflow area (VARLEN Overflow Area) in arrival sequence.
The system allocates space as needed in the overflow. The system considers only the
overflowed data and the linkage data when allocating space. The maximum size is not
considered except to make sure it is not exceeded.

V8.0
Student Notebook
Uempty
IBM i
Physical file
R VARREC
ITEMNO
6A
DESC
100A VARLEN(35)
DATE
6A
LO
W
ED
Item update
Item No.: 125784
Description:
The quick brown fox jumped over the lazy dog.
Physical file
VE
RF
Date: 11-21-12

125784
125785
X
X
35
OVERFLOW AREA
Record 2 - Fld Desc The quick brown
fox jumped over the lazy
X
Record 3 - Fld Desc The rain in Spain falls mainly on the plain.
Record 2 - Field Desc dog. -

OL629.0
Notes:
If a field that has overflowed is updated and the new length of the data in the field exceeds
the previous length, the system will split the overflow data. All overflow data that will fit is
written to the original overflow area for that record and field. The excess is then written to a
new overflow area.
The original overflow area is flagged as overflowed. The excess is then written at the
current end of the overflow area with new linkage data.
10-11
Student Notebook
Variable-length field recommendations

IBM i
Keep overflowed records to less than 10%

Maximum length: 50 bytes more than allocated length
RGZPFM after updating consolidates overflow fragments

Figure 10-10. Variable-length field recommendations
OL629.0
Notes:
Records exceeding minimum length should not exceed 10% of the file.
The maximum length should exceed the minimum length by 50 or more characters.
Reorganize the file after updating records with variable-length fields.

V8.0
Student Notebook
Uempty
File attributes
IBM i
DSPFD
FILEA
MAINT
FRCRATIO
SHARE
CRT
CHG
DSP01
)( )
PF
LF
OVRDBF
CALL PGMA
3
ODP: FILEA
PGMA
Open FILEA
R FMTA
FLD1
FLD2
PAG
DSP01/USER/123456
DSPFFD
Figure 10-11. File attributes
OL629.0
Notes:
The DSPFD command shows one or more types of information retrieved from the file
descriptions.
The DSPFFD command shows file field information.
File name, library, type, member, creation date, number of records, record format name,
format level identifier, text, record length, and number of fields in format
Field name, type, length, edit code, edit word, column headings, and validity checking
information
For fields referencing other fields, the name of the referenced file, record format, and
field. If any attributes of the referenced field were changed the attribute type is given.
10-13
Student Notebook
Compile and compile listing options

IBM i
( )
(
CRT
PF
LF
OPTION
GENLVL
FLAG
*SOURCE
*NOSECLVL
*SECLVL
*LIST
*NOSOURCE
20 Severity - Level
0 Severity - Level
*NOLIST

Figure 10-12. Compile and compile listing options
OL629.0
Notes:
OPTION
Specifies the type of output produced
GENLVL
Level at which the create operation fails
FLAG
Minimum severity level of messages to be listed in the DDS

source listing

V8.0
Student Notebook
Uempty
CRTPF: Space allocation parameters

IBM i
CRT
( PF
LF )
CONTIG *YES
*NO
CRTPF only:
ALLOCATE *NO - System determines size
( *YES - SIZE parameters determines size )
SIZE
DLTPCT
10000
no.- records
REUSEDLT
1000
increment
3
no.-increments
*NONE
deleted records threshold percentage
*YES
*NO
)
)

Figure 10-13. CRTPF: Space allocation parameters
OL629.0
Notes:
CONTIG
Whether records in the initial allocation are stored contiguously
ALLOCATE
Whether storage is allocated for the initial number of records

(SIZE parameter)
SIZE
Initial number of records, the number of records in each

increment that can be automatically allocated, and the number
of times the increment can be automatically applied
DLTPCT
Maximum percentage of deleted records
REUSEDLT
Whether space used by deleted records is reclaimed by future

record inserts
10-15
Student Notebook
CRTPF and CRTLF: Availability and recovery

parameters
IBM i
CRT
PF
( LF
)
*IMMED
*REBLD
*DLY
MAINT
RECOVER
FRCACCPTH
FRCRATIO
*NO
*AFTIPL
*IPL
*YES
*NO
)
)
( *NONE
number - of - records - before - force )

Figure 10-14. CRTPF and CRTLF: Availability and recovery parameters
OL629.0
Notes:
MAINT
Type of access path maintenance for keyed sequence access

path
RECOVER
For MAINT(*IMMED) or MAINT(*DLY) files when recovery of

the file is performed after a system failure occurred while the
access path was being changed
FRCACCPTH
For keyed access path files, whether access path changes are
forced to auxiliary storage along with the associated records
whenever the access path is changed
FRCRATIO
The number of inserted, updated, or deleted records that are

processed before they are forced to auxiliary storage

V8.0
Student Notebook
Uempty
CRTPF and CRTLF: Change control parameters

IBM i
CRT
z
( PF
LF )
LVLCHK
( *YES
*NO )
Record format level identifier

Hash total reflecting the record's I/O buffer
Copied to *PGM at create time
y EXPDATE
*NONE
( expiration-date
)
y ALWUPD
( *YES
)
*NO
y ALWDLT
*YES
( *NO
)

Figure 10-15. CRTPF and CRTLF: Change control parameters
OL629.0
Notes:
LVLCHK
Whether the record format level identifier in the program is

checked against the one on the file when the file is opened
EXPDATE
Expiration date. The file cannot be overwritten until the

expiration date.
ALWUPD
Whether records can be updated in the file
ALWDLT
Whether records can be deleted from the file
10-17
Student Notebook
CRTPF: Application performance parameters

IBM i
SHARE
*YES
*NO
Open data path (ODP)

How opened
Buffer
Cursor
SHARE applies to the second and subsequent file.

It opens to the same file in the same job.
WAITFILE
WAITRCD
*IMMED
*CLS
number - of - seconds
60
*IMMED
*NOMAX
At file open

Figure 10-16. CRTPF: Application performance parameters
OL629.0
Notes:
When a file is opened, the attributes in the database file description are merged with the
parameters in the program. Normally, most of the information the system needs for your
program to open and process the file is found in the file attributes and in the application
program itself.
Sometimes, however, it is necessary to override the processing parameters found in the
file and in the program. For example, if you want to process a member of the file other than
the first member, you need a way to tell the system to use the member you want to
process. The Override with Database File (OVRDBF) command allows you to do this. The
OVRDBF command also allows you to specify processing parameters that can improve the
performance of your job, but that cannot be specified in the file attributes or in the program.
The OVRDBF command parameters take precedence over the file and program attributes.

V8.0
Student Notebook
Uempty
It is time to look at OVRDBF parameters.

SHARE
Whether the open data path (ODP) is shared with other

programs in the same routing step
WAITFILE
Number of seconds a program waits for file resources and

session resources when the file is opened
WAITRCD
Number of seconds a program waits for a record to be updated

or deleted or for a record read in the commitment control
environment with LCKLVL(*ALL) specified
10-19
Student Notebook
OVRDBF parameters (1 of 5)
IBM i
FILE: File name in program

TOFILE: File you want program to open
MBR: Member you want program to open
POSITION
RCDFMTLCK
*NONE
*START
*END
*RRN relative - record - number
Key search arguments
record - format - name *SHRRD
*SHRNUP
*SHRUPD
*EXCLRD
*EXCL

Figure 10-17. OVRDBF parameters (1 of 5)
OL629.0
Notes:
The Override With Database File (OVRDBF) command is used to do the following:
Override (replace) the file named in the program
Override certain parameters of a file that are used by the program
Override the file named in the program and override certain parameters of the file
processed
To override (replace) a file named in the program, specify the name of that file in the FILE
parameter, and specify the name of the file that overrides it (the file to be processed by the
program) in the TOFILE parameter. The other parameters of this command can be used to
override parameter values contained in the file description of the overriding file.
To override only certain parameters of the file named in the program, instead of replacing
the entire file, specify the name of the file in the FILE parameter, and specify the *FILE
value for the TOFILE parameter. Then use the other parameters of this command to
override specific parameters of the file. Parameters that are not specified do not affect
parameters specified in the file description, in the program, or in other previously issued file
override commands.

V8.0
Student Notebook
Uempty
POSITION
Specifies the starting position for retrieving records from the

database file. The first record to get can be at the beginning
(*START) or at the end (*END) of the file, the nth record in the
file (*RRN), or the record indicated by a key field value and one
of the key-search values (*KEY, *KEYA, *KEYAE, *KEYB, or
*KEYBE). This parameter overrides the value specified in the
program or in other called OVRDBF commands.
RCDFMTLCK
Specifies the lock state of the named record format while it is

used by the program. The lock state indicates how the data
associated with each format is locked.
10-21
Student Notebook
IBM i
IBM i lock states for database

User A
successfully
obtains lock state
Operations
allowed
for user A
Operations
allowed for
user B
User B may now

obtain this lock
state
*EXCL
ALL
NONE ALLOWED
NONE
*EXC
ALL
*SHRRD
READ
*SHRUPD
ALL
*SHRNUP
READ
*SHRRD
*SHRRD
*SHRUPD
READ
*SHRNUP
READ
*SHRRD
READ
READ
READ, ADD,/DEL/UPD
*EXCLRD
*SHRUPD
*SHRNUP
*SHRRD
READ, ADD, /DEL/UPD

READ, ADD, /DEL/UPD
READ
READ

OL629.0
Notes:
This visual shows the lock states that are specified for each record format and the
operations allowed to other programs when the lock is in effect.
Note 1: For SHRUPD, IBM i/OS enforces a lock at the record level if multiple users try to
read the same record.
Note 2: RPGIV requests SHRRD when opening a file for input. RPGIV requests SHRUPD
when opening a file for update/add.
Note 3: ALCOBJ can also be used to lock a file.

V8.0
Student Notebook
Uempty
IBM i
( *NO ) Inhibit Write (Testing)
INHWRT *YES
( *YES )
EXPCHK *NO
NBRRCDS No. - of - records
Between auxiliary storage

and system database main storage area
SEQONLY *NO
*YES No. - of - records
Between PAG and

system database main storage area. File opened
for Input-Only or Output-Only

OL629.0
Notes:
INHWRT
Whether the processed records are written, deleted, or

changed in the file; this parameter tests a program without
storing the records back in the database.
EXPCHK
Whether the expiration date is checked
10-23
Student Notebook
IBM i
Main storage
NBRRCDS and SEQONLY
PAG: DSP01/USER1/123456
ODP
NBRRCDS
SEQONLY
System main storage

database area

OL629.0
Notes:
NBRRCDS
Number of records moved as a unit from auxiliary storage to

main storage
SEQONLY
For files processed sequentially, whether sequential only

processing is used; it also specifies the number of records
transferred as a group to or from the database if sequential
processing is used.

V8.0
Student Notebook
Uempty
IBM i
( *NONE
EOFDLY number - of - seconds
( *NO
SECURE *YES
) *YES - Ignore OVRDBF in calling programs.
OVRDBF parameters
FRCRATIO
WAITFILE
WAITRCD
LVLCHK
SHARE
Temporary change
Allows program to wait

for additional records
CHG
CRT
PF
LF
( ) parameters
FRCRATIO
WAITFILE
WAITRCD
LVLCHK
SHARE
Permanent

OL629.0
Notes:
EOFDLY
Number of seconds to delay when end-of-file is reached before

trying to retrieve additional records
SECURE
Whether the file is safe from the effects of previously called file
override commands
10-25
Student Notebook
Parallel, concurrent, and interruptible reorganize

(1 of 2)
IBM i
Typical reorganize styles

Copy
In place
Concurrency
Exclusive lock required for

short duration at either the
end of a reorganize or at
the beginning of the next
reorganize to truncate
space
If LOCK(*EXCL) is not
chosen, the reorganize will
be close but not
guaranteed to be exact
This is the style used

with the new support.

Figure 10-22. Parallel, concurrent, and interruptible reorganize (1 of 2)
OL629.0
Notes:
The Reorganize Physical File Member (RGZPFM) command compresses (removes deleted
records from) one member of a physical file in the database, and it optionally reorganizes
that member.
If a keyed file is identified in the KEYFILE parameter, the system reorganizes the member
by changing the physical sequence of the records in storage to either match the keyed
sequence of the physical file member's access path or to match the access path of a logical
file member that is defined over the physical file. Reorganization can decrease file
processing time when a program is reading sequentially through a keyed physical file or
through a keyed logical file.
When the member is reorganized and the KEYFILE parameter is specified, the sequence
in which the records are actually stored is changed, and any deleted records are removed
from the file. If the KEYFILE parameter is not specified, the sequence of the records does
not change, but deleted records are removed from the member. Optionally, new sequence
numbers and zero date fields are placed in the source fields of the records. These fields
are changed after the member has been compressed or reorganized.

V8.0
Student Notebook
Uempty
Parallel, concurrent, and interruptible reorganize

(2 of 2)
IBM i
Parallel processing
Requires DB2 UDB Symmetric multiprocessing option
Specify an explicit parallel degree using CHGQRYA or Change
Query Attributes from System i Navigator
Index rebuild
New index rebuild options (both for old and new reorganize)
Unique and referential integrity indexes must be maintained
Warning: like other reorganize operations, reorganizing in the
presence of LIFO, FIFO, or DATEFO indexes will change the
order of duplicates unless that index is used as the KEYFILE.

Figure 10-23. Parallel, concurrent, and interruptible reorganize (2 of 2)
OL629.0
Notes:
There are two basic methods for reorganizing data.
ALWCANCEL(*NO): This is the traditional type of reorganize. A full copy of the data might
be made, so you need up to two times the amount of space. This option cannot be
canceled (suspended) and cannot fully run in parallel. It requires exclusive use of the file.
ALWCANCEL(*YES): The data rows are moved within the file so that a full copy of the data
is not required. The file must be journaled, however, so storage is necessary for the journal
entries. You can use the journal receiver threshold to minimize the amount of storage used
in a specific journal receiver. This option can be canceled (suspended) and restarted.
Reorganize can run in parallel if the DB2 UDB SMP option is installed. To control the
amount of resources used by the reorganize operation, you may want to change the query
attributes using the Change Query Attributes (CHGQRYA) CL command or Change Query
Attributes from System i Navigator.
The reorganize option requires exclusive use for only a few seconds after the reorganize is
complete to return storage to the system. If the exclusive lock cannot be acquired, a
10-27
Student Notebook
warning message is sent to the job log indicating that space cannot be recovered. To
recover the space, you can issue the reorganize again when no concurrent users are
accessing the file. The reorganize operation then immediately attempts to recover the
space before starting the reorganize. If concurrent data changes have occurred since the
initial reorganize, only a portion of the space might be recovered.
If LOCK(*EXCLRD) or LOCK(*SHRUPD) is specified, the result of the reorganize is not
guaranteed to be exact because concurrent users may be locking rows or changing rows in
the file. For example, if another user has row 43 locked, the reorganize will not be able to
move it, so it is not necessarily in the right position at the end of the reorganize. In many
cases, this is fine. In other cases, the applications depend on exact positions and should
use *EXCL. If you specify LOCK(*EXCL), the lock is kept for the duration. If you specify
LOCK(*EXCLRD) or LOCK(*SHRUPD), you keep that lock for the duration. In addition, you
need an exclusive lock for a very brief period.
The RBDACCPTH parameter specifies whether to rebuild or maintain any valid access paths
(other than an access path specified as the KEYFILE or a MAINT(*REBLD) access path)
over the member.
RI and unique indexes are always maintained regardless of the index option.

V8.0
Student Notebook
Uempty
Checkpoint (1 of 2)
IBM i
1. When does automatic access path sharing occur?

a. When two or more files are based on the same physical files and the
same key fields in the same order.
b. When a logical file with a keyed sequence access path is created and
an access path exists on the system that satisfies the same criteria.
c. When a new logical file has select/omit specifications that are identical
to the select/omit specifications of the existing access path.
2. Which of the following file attribute parameters can positively

affect applications that utilize the files?
a.
b.
c.
d.
SHARE( )
DLTPCT( )
SIZE( )
RECOVER( )

OL629.0
Notes:
10-29
Student Notebook
Checkpoint (2 of 2)
IBM i
3. True or False: If using a variable length data field, be sure to

keep records with overflowed field data to less than 10% of
the total number of records.

OL629.0
Notes:

V8.0
Student Notebook
Uempty
Unit summary
IBM i

application design

OL629.0
Notes:
10-31
Student Notebook

V8.0
Student Notebook
Uempty
Unit 11. Referential integrity

DB2 for i referential integrity allows the establishment of relationships
between files that are maintained by the database rather than by
application programs. An example of such a relationship is ensuring
that a transaction record (including a customer number) cannot be
added to the database unless the master customer record exists.

Describe the considerations for using DB2 for i referential integrity

Accountability
Machine exercise

11-1
Student Notebook
Unit objectives
IBM i

Describe the considerations for using DB2 for i referential
integrity

OL629.0
Notes:

V8.0
Student Notebook
Uempty
DB2 referential integrity (1 of 2)

IBM i
Referential integrity
encompasses all of the
mechanisms and techniques
that you use to make sure that
your database contains only
valid data.

Figure 11-2. DB2 referential integrity (1 of 2)
OL629.0
Notes:
You can use referential constraints in IBM i databases to enforce the referential integrity of
your system. Referential integrity is a set of mechanisms by which the database
management system (DBMS) keeps the data values in a state that makes sense to the
customer's business. When referential integrity is active, the system will automatically
maintain certain basic relationships between the data in different files no matter what kind
of operations the applications perform over the database.

11-3
Student Notebook
DB2 referential integrity (2 of 2)

IBM i
Customer file
Invoice file
Primary key
Constraint: CUSTNO
CUSTNO CUSTNAM
Referential constraint
...
INVNR
CUSTNUM
100
ABLE
2001
105
105
ADAMS
2002
115
110
BAKER
115
BRINK
...
Rules: No duplicate CUSTNO in customer file

No unmatched CUSTNUM in invoice file
Enforced by database management.
Figure 11-3. DB2 referential integrity (2 of 2)
OL629.0
Notes:
You might want, for example, all records in your invoice file to have a customer code
matching an existing customer in your customer's file. For this reason, you do not want that
customer removed when there are some invoices related to that particular customer. If your
DBMS does not provide you with a referential integrity function, the applications must
enforce these rules, and there is no protection against accidental updates made through
other interfaces, like DFU, Interactive SQL, and so forth.
Using referential integrity lets the system enforce these common rules and provides your
database with robust consistency checking, which will take place whenever and no matter
how a database change is performed. Application developers will focus on defining the
referential constraints and will not have to worry about checking for dependencies and
consistency in the application code, which will be easier to maintain and expand.
Referential integrity can be beneficial also from a performance standpoint. The integrity
checks will be performed much quicker at the operating system level rather than by an
application program.

V8.0
Student Notebook
Uempty
Referential integrity benefits

IBM i
Without referential integrity

The rules must be implemented at application level
Could not enforce rules across applications
With referential integrity

The rules are implemented by DB2 at IBM i/OS level
Benefits
Independent of application programs
Continuous enforcement of referential constraints
Easier application coding
Better performance

Figure 11-4. Referential integrity benefits
OL629.0
Notes:
Before Version 3 Release 1, the referential integrity checking had to be performed by the
application program. Even though the application programs did some checking, other
interfaces (like DFU or Interactive SQL) or even other applications without this logic
implemented could violate the referential integrity of the files. Now, you can let DB2 for i
ensure your data integrity through the referential integrity constraints.
Referential integrity may improve your application performance because the integrity
checks are much more efficient and quicker when performed at the operating system level
rather than by an application. RI enforcement is performed at all times on all interfaces.
Once a programmer has defined referential constraints to the DBMS, however, the existing
integrity checks should be removed from the application program. Otherwise, the
application performance will degrade because the same checking is being performed twice
at the application level and the system level.

11-5
Student Notebook
Referential integrity: Concepts (1 of 4)

IBM i
Parent file
CUSTNO CUSTNAM
...
Dependent file
INVNR
...
CUSTNUM
100
ABLE
2001
105
105
ADAMS
2002
115
110
BAKER
115
BRINK
Foreign key
Primary
key
Referential
constraint
Parent key

Figure 11-5. Referential integrity: Concepts (1 of 4)
OL629.0
Notes:
The concepts of referential integrity are explained in detail in the following visuals.
The customer file has a primary key constraint on CUSTNO. The invoice file has a
referential constraint between its field CUSTNUM and the customer file field CUSTNO.
CUSTNO is the parent key, and the customer file is the parent file. CUSTNUM is the
dependent key, and the invoice file is the dependent file. The referential constraint is
always stored in the dependent file.

V8.0
Student Notebook
Uempty

IBM i
Unique key constraint

Fields in a physical file that are unique, ascending, and may be null
May be multiple per file
May be used as a parent key in referential constraint
Primary key constraint

Unique key without nulls or fields in a physical file that are unique,
ascending, and not null
Only one per file
May be used as a parent key in a referential constraint

OL629.0
Notes:
A Unique Key Constraint is the rule which identifies a unique key in a database file. A
unique key is a field or a set of fields in a physical file that must be unique, ascending, and
can contain null capable fields. For example, you can specify a customer number as a
unique constraint in your database. If anyone attempts to create a new customer with the
same customer number, an error message is sent to the database administrator. A file can
have multiple unique constraints, but you cannot duplicate unique constraints. The same
key fields, regardless of order, constitute a duplicate constraint. Unique constraints can be
used as the parent key when adding a referential constraint.
A primary key constraint is a unique key with special attributes that make the key the
primary access path for the file. Primary key constraints identify a field or set of fields in a
database file whose values must be unique across records in the file. The field must be in
ascending order and can be null capable. If it is null-capable, a check constraint is implicitly
added so that null values cannot be entered in the field. You can define only one primary
key constraint for a file. A primary key constraint can be used as the parent key when
adding a referential constraint.

11-7
Student Notebook
The primary access path for a database file on the i is the access path used to access the
file when OPNDBF command is issued and generally coincides with the key specified in the
DDS at the moment the file layout is defined.
The primary key is a good candidate for becoming a parent key. Actually, when you design
your database, you might choose your parent key to match the primary key or any unique
key. Multiple parent keys can be defined on the same file at the same time.

V8.0
Student Notebook
Uempty

IBM i
Relationship between records identified by parent keys and records
identified by foreign keys
Parent key
Either a unique key or a primary key referenced in a referential
constraint
Foreign key
Fields whose values (if not null) must match those of a parent key

OL629.0
Notes:
A referential constraint defines a relationship between the records identified by the parent
keys and the records identified by the foreign keys. Because the dependent file is always
dependent upon the parent file, the referential constraint is defined from the dependent
file's perspective.
A parent key is a field or a set of fields in a physical file which must be unique, ascending,
and might or might not contain null values. The parent key of the parent file is used to add
a referential constraint to the dependent file. The parent key must be either a primary key
or a unique constraint.
A foreign key is a field or set of fields in which each non-null value must match a value in
the parent key of the related parent file. The attributes (data type, length, and so forth) must
be the same as the parent key of the parent file.
When the referential constraint is added, the primary key CUSTNO is specified as the
parent key, and CUSTNUM is specified as the foreign key.

11-9
Student Notebook

IBM i
Parent file
File containing parent key in a referential constraint
Dependent file
File containing foreign key in a referential constraint
State of a database in which each non-null foreign key value must
have a matching parent key value

OL629.0
Notes:
The parent file is the file that contains the parent key in a referential constraint.
The dependent file is the file that contains the foreign key in a referential constraint.
Referential integrity is the state of a database in which the values of the foreign keys are
valid. That is, each non-null foreign key value must have a matching parent key value.
When referential integrity is established, the database management system DB2 for i will
take care that any attempt to update the database does not violate the referential
constraints. This objective can be pursued in several ways, depending on the rules you
choose. We will see these rules on the next visual.
When the referential constraint is added, the primary key CUSTNO in the parent file is
specified as the parent key, and CUSTNUM in the dependent file is specified as the foreign
key.

V8.0
Student Notebook
Uempty
Referential constraint: Rules

IBM i
Parent file
Dependent file
Primary key constraint

CUSTNO CUSTNAM
100
ABLE
105
ADAMS
110
BAKER
115
BRINK
...
Parent key enforcement:

Deletes
Updates
*RESTRICT
*CASCADE
*SETNULL
*SETDFT
*NOACTION
Update rule
Delete rule
INVNR
CUSTNUM
2001
105
2002
115
...
Foreign key enforcement:

Automatic *NOACTION on
inserts and updates
*RESTRICT
*NOACTION

Figure 11-9. Referential constraint: Rules
OL629.0
Notes:
The delete rule is a definition of what action the database should take when there is an
attempt to delete a parent record. The following actions can be taken:
Cascade: If you want to delete a record from the parent file and its parent key matches
some records in a dependent file, the DBMS will delete all the matching records of the
dependent file.
Set null: If you delete a record from the parent file and its parent key matches some
records in a dependent file, the DBMS will set to null the matching keys in the
dependent file. At least one field in the foreign key has to be null-capable, otherwise the
key values will not be changed.
Set default: Like the previous case but matching occurrences in the foreign key are set
to their default values. The default value for the foreign key has to match a record in the
parent file.
Restrict: The DBMS will prevent any attempt to delete records in the parent file if its
key matches some records in the dependent file.

11-11
Student Notebook
No Action: Has the same meaning as restrict but different timing. When you use
*NOACTION and an invalid delete operation is about to take place, DB2 for i will delay
any error message until the end of the operation itself, allowing, for instance, the
activation of a before trigger attached to the physical file. If *RESTRICT is in use, the
exception message is sent immediately.
Deleting records in a dependent file is always permitted.
The update rule is a definition of what action the database should take when there is an
attempt to update a parent record. The following actions can be taken:
Restrict: You cannot change the values in a parent key if the old values match some
records in the dependent file. The remaining portion of the record can always be
updated. You cannot update a foreign key in a dependent file if the new value for the
key is not null and does not match any value of the parent key.
No Action: Same as *RESTRICT but with different timing considerations. See above
where we described no action for delete operations.
Inserts: There is no insert rule to be chosen, but referential integrity prevents any insert
in the dependent file if the new record has no match in the parent file and its foreign key
is not null.
Inserting records in a parent file is always permitted.

V8.0
Student Notebook
Uempty
Referential integrity: An example

IBM i
Customer file: CUSTOMER

(Parent file)
CUSTNO CUSTNAM
105
...
Invoice file: INVOICE

(Dependent file)
INVNR
CUSTNUM
2001
105
2022
105
...
ADAMS
Parent key
Foreign key
ADDPFCST FILE(CUSTOMER)
TYPE(*PRIKEY)
CST(a_name)
KEY(CUSTNO)
ADDPFCST FILE(INVOICE)
TYPE(*REFCST)
CST(another-name)
KEY(CUSTNUM)
PRNFILE(CUSTOMER)
PRNKEY(CUSTNO)
UPDRULE(*RESTRICT)
DLTRULE(*CASCADE)

Figure 11-10. Referential integrity: An example
OL629.0
Notes:
The visual shows a typical simple referential integrity scenario. The customer master file
has been defined to be the parent file, and the customer number is the primary and parent
key. This constraint has been added to the file by using the command ADDPFCST and
specifying that we want CUSTNO as the primary key. The dependent file is the invoice file
where the foreign key is, again, the customer code. The referential constraint has been
added by ADDPFCST, specifying delete and update rules. In our example, we do not want
updates to the parent key to make the database inconsistent. We want to propagate a
delete operation on the parent file to the dependent file.

11-13
Student Notebook
Referential integrity: Requirements (1 of 2)

IBM i
Basic requirement
Parent key and foreign key must have matching fields attributes.
Parent and dependent files must be

Single member physical files
Externally described
On the parent file you can create the following:

One primary key
Multiple unique and parent keys

Figure 11-11. Referential integrity: Requirements (1 of 2)
OL629.0
Notes:
The basic requirement is that your parent key and foreign key have matching field
attributes and definitions.
When defining a referential constraint, the foreign key and parent key field null attributes do
not have to match exactly. When a foreign key contains null capable fields, DB2 for i treats
the entire foreign key value as null.
Performance is better when foreign key fields and parent key fields have identical null
attributes. In fact, the non-null field attributes will deliver the best performance.
A parent and dependent file must be physical files and must have a maximum of one
member.
Only externally described files are allowed in referential constraints. Source files and
program described files are not allowed.
There are a maximum of 300 constraint relations per file. This maximum is a sum of all
the constraint definitions over a file.

V8.0
Student Notebook
Uempty
A file can have a maximum of one primary key but may have many unique keys.
Therefore, a parent file may have many parent keys.
A constraint can be defined when both or either of the dependent and parent files have
no members. A constraint cannot be established unless a file has a member.
Constraint names must be unique in a library.
Constraints cannot be added to files in the QTEMP library.

11-15
Student Notebook
Referential integrity: Requirements (2 of 2)

IBM i
Constraint
Not an object
But name unique within physical files library
Update and delete rules: *RESTRICT

Journal not required
Update or delete rules: *NOACTION, *CASCADE, *SETNULL,

and *SETDFT
Parent and dependent files journaled to same journal
Implicit commitment control

Figure 11-12. Referential integrity: Requirements (2 of 2)
OL629.0
Notes:
A constraint can be defined when both or either of the dependent and parent files have no
members. A constraint cannot be established unless a file has a member. Constraint
names must be unique in a library. Constraints cannot be added to files in the QTEMP
library. Constraints where the parent file is in one ASP and the dependent file is in a
different ASP cannot be added.
When a referential constraint is defined with a delete or update rule other than RESTRICT,
the system has to perform some actions on the corresponding foreign keys each time a
delete or an update of the parent key takes place. In the delete case, for example, it will
delete the matching dependent records when the delete rule is CASCADE. The DBMS
must ensure that the parent key record and all matching dependent records are deleted. All
of these record deletions must be considered as one logical operation.
To complete this operation, the system requires journaling and commitment control in some
cases. If the delete or the update rule is other than RESTRICT, both the parent and the
dependent files must be journaled to the same journal. DB2 for i starts an implicit
commitment control cycle for I/O operations resulting from the referential constraint
enforcement.

V8.0
Student Notebook
Uempty
Creating primary key constraint

IBM i
Over an existing file

CUSTOMER file
CUSNBR
CUSTNAM
CUSTADR
Primary key
Using CL
ADDPFCST
FILE(mylib/CUSTOMER)
TYPE(*PRIKEY)
KEY(CUSNBR)
CST(customer_key)

Figure 11-13. Creating primary key constraint
OL629.0
Notes:
The first step in creating a referential constraint is identifying the parent key. A unique or
primary key constraint can be used to identify the parent key.
Only one primary key constraint can be associated with a physical file, but you can define
multiple unique constraints over the same file. When a primary key constraint is added to a
physical file, the associated access path becomes the primary access path of the file (for
example, the access path used to access the file when a OPNDBF command is issued).
The user can easily add constraints to existing files using the ADDPFCST CL command.
The existing records must not contain any duplicate values for the unique or primary key
fields. If the system does find duplicate values, the constraint is not added, and an error
message is returned.

11-17
Student Notebook
Creating a referential constraint

IBM i
Over an existing file

CUSTOMER file
CUSNBR
CUSTNAM
...
CUSNBR
...
Primary Key
ORDERHDR file
ORHNBR
Foreign Key
Using CL
ADDPFCST
FILE(mylib/ORDERHDR)
PRNFILE(mylib/CUSTOMER)
TYPE(*REFCST)
PRNKEY(CUSNBR)
KEY(CUSNBR)
DLTRULE(*RESTRICT)
CST(orderhdr_cnbr) UPDRULE(*RESTRICT)

Figure 11-14. Creating a referential constraint
OL629.0
Notes:
During the creation of this referential constraint, the DBMS will first try to share an existing
access path for the foreign key. If one cannot be shared, the DBMS will create an access
path. Once the foreign key access path has been identified, DB2 for i will then go through
and verify that every non-null foreign key value has a matching parent key.
If the system finds an invalid foreign key value during creation of the referential constraint,
the constraint is still added to the file, but the referential constraint is automatically
disabled, and the relationship is marked as check pending.
Constraints can also be added and managed using System i Navigator.

V8.0
Student Notebook
Uempty
Building a referential integrity network

IBM i
CUSTOMER file
CUSNBR
PK
...
CUSTNAM
Delete restrict
Update restrict
Note 2
FK
ORDERHDR file
ORHNBR
...
CUSNBR
Note 1
PK
FK
ORDERDTL file
Delete cascade
Update restrict
Note 4
ORHNBR PRDNBR ORDQTY
...
Note 3
PK
Figure 11-15. Building a referential integrity network
OL629.0
Notes:
Let's consider the referential integrity network for the Order Entry application.
The following key fields are defined:
Customer_Number (CUSNBR) has to be unique in the CUSTOMER file.
Order_Number (ORHNBR) has to be unique in the ORDERHDR file.
Order_Number and Product_Number (ORHNBR plus PRDNBR) have to be unique in
the ORDERDTL file. This composite key should be referred to as a parent key in a
dependent feature file (not shown here).
Each of them identifies the primary access path and can potentially be defined as a parent
key.
The following rules apply:
An order should not be inserted into the ORDERHDR file unless it references an
existing customer in the CUSTOMER file. This relationship identifies a referential
constraint between ORDERHDR and the CUSTOMER file (note 1).

11-19
Student Notebook
Customers should not be deleted or have their customer number changed when
outstanding orders for this customer exist in the ORDERHDR file. This relationship can
be enforced with delete and update rules set to RESTRICT (note 2).
An order detail entry should not be inserted into the ORDERDTL file without referencing
a valid order number in the ORDERHDR file. This relationship identifies a referential
constraint between the ORDERDTL and the ORDERHDR files (note 3).
When an order is deleted, all its order detail rows have to be deleted as well. An order
number should not be updated when it has existing detail rows in the ORDERDTL file.
This leads to choosing a delete rule of CASCADE and an update rule of RESTRICT
(note 4).
Since DB2 for i is tightly integrated with the operating system, you can define and exploit
referential integrity using both the native interfaces and SQL.
Once you have created the parent file and the dependent file, you are ready to define the
referential integrity constraints. You must define a primary key constraint or a unique key
constraint for the parent file and then a referential constraint for the dependent file.
If you are using the native database interface, constraints can be added using the Add
Physical File Constraint command (ADDPFCST).
The ADDPFCST will create an access path for the parent file if any of the existing access
paths cannot be shared. If an access path with the required characteristics exists, it will be
used as parent key, and if *PRIKEY was specified, it will become the primary access path
for that file.

V8.0
Student Notebook
Uempty
Displaying constraint information

IBM i
DSPFD FILE(
) Type(*CST)
Primary, unique constraints

Referential constraints (stored in dependent file)
DSPDBR FILE(
If file is parent, dependent file is shown
WRKPFCST FILE(one or many)

Type of constraint
Status

Figure 11-16. Displaying constraint information
OL629.0
Notes:
A user can display or output the constraints and their related attributes and states for a file
in the following ways:
Displaying the physical file description (DSPFD) command
Displaying the data base relations (DSPDBR) command
Querying the system catalog tables
The DSPFD command provides a complete description of all the constraints defined for a
file. You can select this specific information by specifying the following:
DSPFD FILE(ORDENTL/ORDERHDR) TYPE(*CST)
This will show you which constraints are defined for the ORDERHDR file and their
description. In the Constraint Description section, for each constraint, all the parameter
values set through the ADDPFCST command are listed.
This DSPFD command shows a referential constraint only in the dependent file description.
In order to determine which referential constraints refer to a parent file, you must use the
DSPDBR command on that file. It lists these constraints in the Dependent Files section
where some new information has been added to differentiate among referential constraints,
logical files, SQL indexes, or views.

11-21
Student Notebook
Constraint states
IBM i
ENABLED
DISABLED
DEFINED
Will remain enabled

when moved to
established
Will remain disabled

when moved to
established
ESTABLISHED
constraints enforced
constraints not
enforced

Figure 11-17. Constraint states
OL629.0
Notes:
When a constraint definition exists but is not enforced, it is in the defined state. A constraint
goes to the defined state if
It is defined over files with no members.
It is a referential constraint built on a dependent file, and the parent file does not exist
yet.
In the established state, the foreign key attributes match those of the parent key.
Check pending is the condition of a constraint relationship when potential mismatches exist
between parent and foreign keys. When the system determines that referential integrity
may have been violated, the constraint relationship is marked as check pending.

V8.0
Student Notebook
Uempty
Verifying constraints
IBM i
Referential integrity is enforced by DBDM below application

level.
Constraints will be verified.
At creation time
When state goes to established/enabled
After a file has been restored
This process might take some time for large files.

Constraints will be enforced when an I/O occurs.
Delete from a parent file
Insert into a dependent file
Update on either a parent or a dependent file

Figure 11-18. Verifying constraints
OL629.0
Notes:
Constraints will be verified.
At constraint creation time, depending on what information is checked as well as the
constraints between parents and dependent records. If mismatches occur, the
constraint will be put in a status called check pending. The state remains enabled.
When the state goes to established/enabled. This condition is reached after the normal
creation of a constraint or after removing data that caused a check.
After file restore, DB2 for i verifies the constraint.
These processes might run a long time if the files are very large. You should always
consider this before starting operations that affect constraint checking.
The enforcement of referential constraints is performed during any update or delete of
parent records and any time a dependent record is updated or inserted.
Any inconsistency is always detected by the database manager, even if you restore the
database from a tape or temporarily suspend the enforcement of the rules. Other
implementations are not as safe as declarative RI. On some platforms, for instance, RI is
implemented by means of trigger programs, but this does not always allow the database
manager to detect a violation after certain operations, such as a restore.

11-23
Student Notebook
Access paths and referential integrity

IBM i
DB2 for i needs access paths or indexes for constraint

enforcement.
At constraint creation time, the system will do the following:
Share an existing access path with matching attributes
Create a new access path if sharing is not possible
An access path created to satisfy a primary key constraint is

accessible by users.
Other access paths created to satisfy a constraint are not
accessible by the user.

Figure 11-19. Access paths and referential integrity
OL629.0
Notes:
DB2 for i uses access paths to perform the referential constraint enforcement as efficiently
as possible. The DBMS, however, does not require its own access path for this
enforcement. When a constraint is added to a physical file, the system will first try to share
an existing path. If one cannot be shared, a new access path will be created. This sharing
is similar to the sharing performed for logical files.
When a constraint is added to a physical file and an access path matching the constraint
criteria exists, this access path is shared, and the ownership of the access path itself is
transferred to the physical file. Likewise, if a logical file access path is shared, access path
ownership is transferred from the logical file to the physical file. If an existing access path
cannot be shared, a new one will be created and owned by the physical file.
Similarly, when a logical file or an SQL index is created on a physical file with existing
constraints, the system will try to share the constraint access paths as well.

V8.0
Student Notebook
Uempty
Physical file constraints are not separate objects like logical files and SQL indexes.
Referential integrity constraints and their associated access paths are part of the file
description. When a physical file is saved, the system also saves all the constraints and
their associated access paths.
If the existing access path has more than one key field, the constraint will only share that
access path if they are defined with the same key fields in the same sequence. Partial
sharing is not allowed.

11-25
Student Notebook
Journaling and commitment control

IBM i
.......
Commit
1
Update... 3
Insert...
Delete from TEST/ORDERH

where
ORHNBR='77120'
remove 77120 from ORDERH

remove 00200 from DETAIL
remove 00420 from DETAIL
remove GK004 from FEATURE
remove RF321 from FEATURE
remove RD441 from FEATURE
remove YH532 from FEATURE
Automatic
rollback
If no error
COMMIT
Else
ROLLBACK
Application
Figure 11-20. Journaling and commitment control
OL629.0
Notes:
In order to ensure the completion of this operation, the system requires journaling and
commitment control in some cases. If the delete or the update rule is other than restrict,
both the parent and the dependent files must be journaled to the same journal.
Since the restrict and no action rules cause similar rule enforcement, the restrict rule will
provide better performance since journaling and commit are not required.
Furthermore, the system will implicitly start a commitment control cycle for the user when
the delete or update rule requires commitment control.
This implicit commitment control cycle will be transparent to the user and application
program. If any failure occurs before the update or delete operation has been carried out by
the system, all the changes related to the database operation will be rolled back
automatically. Other changes previously made by the application will not be affected by this
automatic rollback.
In order to ensure the highest integrity level and control of your database, a user may want
to consider having their application start its own commitment control cycle.

V8.0
Student Notebook
Uempty
In the visual
The application in this figure starts its own commitment control cycle.
When the DELETE operation is performed, records are removed from three files
(ORDERH, DETAIL, and FEATURE) because of delete cascade rules. DB2 for i will
activate an implicit commitment control cycle.
If a failure occurs, the records removed will be placed back into the files.
This automatic rollback does not affect the changes marked with four which will be
rolled back under explicit application control.

11-27
Student Notebook
Monitoring exceptions in applications

IBM i
CPF messages
CPF502D
Notify
Unmatched parent key
CPF502E
CPF503A
Notify
Notify
Record/file lock
Update/Delete with RESTRICT or NO ACTION
CPF523B
Escape
Files not journaled (or not to the same journal)
RPGIV
Error indicators
File status 01299
COBOL: File status Code 90

ILE RPG
Error indicators
New file status codes 01222 and 01022
ILE COBOL: File status Code 9R

ILE C: Mapped to existing error codes
SQL: SQL CODES 530, 531, 532
Figure 11-21. Monitoring exceptions in applications
OL629.0
Notes:
Some new error messages have been defined to handle the errors occurring during
referential integrity enforcement. Instead of coding specific integrity checks into your
application programs, applications can handle the new RI error conditions that can be
raised by DB2 for i during referential constraint enforcement as a usual exception status
handling.

V8.0
Student Notebook
Uempty
Check pending: Unmatched foreign keys

IBM i
How
ADDPFCST to existing files
Files not journaled and abnormal system end
Restore of files
APYJRNCHG or RMVJRNCHG
Resolve
CHGPFCST . . . STATE (*DISABLED)
Find records in violation: DSPCPCST
Correct records
CHGPFCST . . . STATE (*ENABLED)

Figure 11-22. Check pending: Unmatched foreign keys
OL629.0
Notes:
A referential constraint is placed in check pending status if the DB2 for i determines that
mismatches might exist between the parent and foreign keys. The check pending status
only applies to referential constraints in the established/enabled state.
When a referential constraint relationship has been marked as check pending, the
associated parent and dependent files can be opened, but the system imposes some
restrictions on the I/O operations to those files.
Only read and insert operations are allowed on the parent file.
No I/O operations are allowed on the dependent file.
The system imposes these restrictions to ensure that applications and users are not
accessing and changing records that are possibly inconsistent and violating referential
integrity.

11-29
Student Notebook
There are several operations which can cause a check pending condition.
Adding referential constraints to existing files with invalid data
Abnormal system failures
Partial restore or restore of files at different data levels
Apply/remove journal changes
To move a constraint relationship out of check pending, you must use CHGPFCST to
disable the constraint. This will allow any I/O operations to be performed on the parent and
dependent file. You can then correct your parent and foreign key values so that they again
meet referential integrity. Once the data corrections have been completed, you can enable
the constraint which causes DB2 for i to process and verify that every non-null foreign key
value is valid. If this verification finds mismatches, the relationship is again marked as
check pending and the process repeats itself.
The check pending status of a file can be determined with the WRKPFCST command.

V8.0
Student Notebook
Uempty
Work with Physical File Constraints: WRKPFCST

IBM i
Work with Physical File Constraints

Type options, press Enter.
2=Change 4=Remove 6=Display records in check pending
Opt Constraint
_ CUSTOMER_K >
_ ORDDTL_KEY
_ ORDDTL_HOR >
_ ORDERHDR_K >
_ ORDERHDR_C >
_ SALESREP_K >
_ SALESREP_C >
_ STOCK_KEY
_ STOCK_SNBR
_ SUPPLIER_K >
File
CUSTOMER
ORDERDTL
ORDERDTL
ORDERHDR
ORDERHDR
SALESCUS
SALESCUS
STOCK
STOCK
SUPPLIER
Library
ORDENTL
ORDENTL
ORDENTL
ORDENTL
ORDENTL
ORDENTL
ORDENTL
ORDENTR
ORDENTR
ORDENTR
Type
*PRIKEY
*PRIKEY
*REFCST
*PRIKEY
*REFCST
*PRIKEY
*REFCST
*PRIKEY
*REFCST
*PRIKEY
State
Check
Pending
EST/ENB
No
EST/ENB
Yes
EST/ENB
No
EST/ENB
No
Parameters for options 2, 4, 6 or command
F3=Exit
F4=Prompt
R16=Repeat position to
F5=Refresh
F17=Position to
Bottom
F12=Cancel
F15=Sort by
F22=Display constraint name

Figure 11-23. Work with Physical File Constraints: WRKPFCST
OL629.0
Notes:
The WRKPFCST command is similar to the other i work commands. This command
accesses most of the constraint operations from a single screen. The WRKPFCST command
lets you see one or all of the physical file constraints defined over one or more files,
depending on the values you set for the WRKPFCST parameters.
From this screen you can do the following:
Change the state of constraints (Option 2: CHGPFCST)
Remove a constraint (Option 4: RMVPFCST)
Display constraints in check pending status (Option 6: DSPCPCST)
The state column lists the states of the referential constraints - defined or established and
enabled or disabled. The check pending status column displays which constraints are
currently in check pending.
Disabled constraints are always shown as being in check pending condition, although
check pending does not apply to disabled constraints even if there is actually no record in
the check pending status.

11-31
Student Notebook
Constraint management commands

IBM i
Disable/enable a constraint: CHGPFCST

Show records in possible violation: DSPCPCST
Check pending
Established/disabled
Remove constraints: RMVPFCST

CST
TYPE
*ALL
*CHKPND
Constraint-Name
*ALL
*REFCST
*UNQCST
*PRIKEY
*RESTRICT
*REMOVE
*KEEP
RMVCST
If type (*UNQCST/*PRIKEY) and is a parent key, RMVCST controls

dependent file *REFCST
Figure 11-24. Constraint management commands
OL629.0
Notes:
The Change Physical File Constraint (CHGPFCST) command provides a way to enable and
disable a referential constraint.
Enable a referential constraint. The enable causes the system to verify the data integrity
of the specified constraint. If the verification is successful, the referential constraint will
be enforced by DB2 for i. Remember that the enable process may take a long time if the
files contain a large number of records.
Disable a referential constraint. Disabling a constraint essentially turns off referential
integrity for that constraint relationship. Although the constraint is still defined in the
DBMS, the DBMS will no longer enforce RI for the disabled constraint relationship. Any
I/O operation is allowed on the parent and dependent file, even if that operation violates
referential integrity.
Disabling a constraint can allow faster file I/O operations in performance critical situations;
however, you must consider the trade-off in this situation. While the constraint is disabled,
the referential integrity can be violated.

V8.0
Student Notebook
Uempty
The Display Constraints in Check Pending Status (DSPCPCST) command can be used on
referential constraints that are in the disabled state in order to display records in the
dependent file which do not have matching parent key values and are thereby causing the
check pending condition.
The RMVPFCST command removes a constraint.

11-33
Student Notebook
Edit Check Pending Constraints: EDTCPCST

IBM i
Edit Check Pending Constraints

RCHASMO3
05/24/94 11:14:25
IPL threshold. . . . . . . . . . . . . 50
Type sequence, press Enter.
Sequence: 1-99, *HLD
0-99
----------Constraints----------
Seq
10
20
*HLD
Status
RUN
READY
CHKPND
Cst
ORDER >
SALES >
STOCK>
File
ORDERHDR
SALESCUS
STOCK
Library
ORDENTL
ORDENTL
ORDENTR
Verify
Time
00:45:30
00:01:43
00:00:25
Elapsed
Time
00:05:15
00:00:00
00:00:00

Figure 11-25. Edit Check Pending Constraints: EDTCPCST
OL629.0
Notes:
The EDTCPCST command allows you to manage all the verifications of referential
constraints that have been marked as check pending and are enabled. The system
displays the constraints marked as check pending and the estimated time on how long it
will take the system to verify the constraint once the parent and foreign key data have been
corrected.
From this screen you can set a sequence for the constraints verification. You can also
delay the verify process to a later time, by specifying *HLD on the sequence field. DB2 for i
will start verifying the constraints right after you have specified the sequence. The elapsed
time since the beginning of the process will also be displayed. During this process, the
constraint status will be set to run. Other constraints waiting for verification will be marked
with ready.
The Edit Check Pending Constraints panel is also displayed during a manual mode IPL if
there are constraints in check pending condition. The screen displayed at IPL time has only
one additional piece of information, the IPL threshold value.

V8.0
Student Notebook
Uempty
Check constraint
IBM i
Field validity checking when adding or updating a record

Constraint is part of the database and enforced on all
interfaces.
Unlike DDS keywords (RANGE, COMP, VALUES) which do not
affect logical files and are used by green screen display files
Works like a referential constraint.
Same states (established and enabled and so forth)
Same commands

Figure 11-26. Check constraint
OL629.0
Notes:
You use check constraints to maintain limits on the values of fields so that they conform to
your database requirements. Check constraints assure the validity of data during insertions
and updates by checking the data against a check constraint expression that you define.
For example, you can create a check constraint on a field such that values that are inserted
into that field must be between 1 and 100. If a value does not fall within that range, the
insert or update operation against your database is not processed.
Check constraints are much like referential constraints in terms of their states (defined and
enabled, defined and disabled, and so forth).
A check constraint, like a referential constraint, can have a check pending status. If the
data in any field violates the check constraint expression, the constraint is in check
pending. For the insertion or update of a record, if the data violates the check constraint
expression, the insert or update will not be allowed.

11-35
Student Notebook
Adding a check constraint example

IBM i
ADDPFCST
FILE(PERSONNEL/SALARY)
TYPE(*CHKCST)
CST(Salary_Limit)
CHKCST('EMPSAL <= 100000')

Figure 11-27. Adding a check constraint example
OL629.0
Notes:
The check constraint expression has the same syntax as the SQL WHERE clause.

V8.0
Student Notebook
Uempty
Referential integrity and journal changes

IBM i
Referential constraints are checked but not enforced during

apply or remove journal changes.
Update and delete rules are ignored.
When the referential integrity is violated, DB2 for i sets the
constraint to check pending.
Always apply or remove journal changes.
To all files of the referential integrity network
CMTBDY(*YES)

Figure 11-28. Referential integrity and journal changes
OL629.0
Notes:
When you apply or remove journal changes, DB2 for i does not allow referential constraints
to prevent the recovery of your database files. Although each apply or remove change is
allowed, the associated referential constraints are constantly verified to prevent you from
violating the referential integrity of your database. If the journal change does violate
referential integrity, the constraint is marked as check pending and the system continues
onto the next journal entry.
Moreover, during the process of applying or removing journal changes, update and delete
rules will be ignored. If you have a cascade delete rule, for instance, removing a record
from the parent file will not remove any of the dependent records. This is due to the fact
that the dependent record changes are also recorded in your journal with the side-effect
journal entries discussed in the previous section, and these entries can be applied as well.
This design allows you to use the journal entries to recover your database files to a known
state without violating the integrity of your database.

11-37
Student Notebook
In order to avoid check pending situations, the user must apply or remove journal changes
on all files in the RI network to ensure that their related parent and dependent files are
recovered to the same data level.
The user should also always apply or remove journal entries within commit boundaries
(starting from the beginning of a logical unit of work down to the end of a logical unit of
work) since the system guarantees the data consistency within the commit boundaries.
Therefore, when you apply journal changes you should set the CMTBDY value to *YES in
the APYJRNCHG command.

V8.0
Student Notebook
Uempty
Save and restore considerations

IBM i
SAVE includes constraints and their access paths.

The system cross-reference file maintains constraints when
parent and dependent files are restored.
The order of parent and dependent restore does not matter.
When parent and dependent files are in the same library,
integrity is maintained by saving and restoring together.
When parent and dependent files are in different libraries
Allocate exclusively until both are saved or restored to maintain
integrity.

Figure 11-29. Save and restore considerations
OL629.0
Notes:
When a set of database files is saved, all the physical file constraints and associated
access paths are saved as well. At restore time, the system will attempt to reestablish the
constraints for the user.
During the restore operation, the system verifies if the parent and dependent files
associated with the referential constraints are at the same data level (that is, the same
integrity level according to their constraints). If the system determines that the related files
and constraints are not at the same level, the constraint relationship is marked as check
pending. The system does not spend time verifying every foreign key value during the
restore; it just verifies the data level of the associated files.
Other DBMSs automatically either place the constraints in check pending or verify every
foreign key value when a user loads backup copies of their database files onto the system.
To avoid check pending and the associated recovery work, the users should always save
the referential integrity network in the same save request which will allow them to restore
the network with one request keeping the data levels of the associated parent and
dependent files in sync.

11-39
Student Notebook
When your referential integrity network is split across different libraries, you will not be able
to save and restore the network with a single request. To prevent other jobs from changing
your file data levels during your multiple request save or restore operation, use the ALCOBJ
command to lock up your referential integrity network.
When a dependent file is restored and the parent file is still missing, the constraint will be
left in defined/enabled state. As soon as the parent file is restored, the constraint will be
established and the data levels immediately verified. Thus, the parent and dependent files
can be restored in any sequence while still avoiding check pending.

V8.0
Student Notebook
Uempty
Checkpoint
IBM i
1. When defining a referential constraint

a. The parent and dependent files must be physical files with one member.
b. There is no maximum number of constraint relations per file.
c. Only program described files are allowed.
d. Files must be in the QTEMP library.
2. A user can display or output constraints and the related attributes for a
file with (blank).
a. The DSPFD TYPE(*CST) command
b. The WRKPFCST command
c. DSPDBR command
3. True or False: When a set of database files is saved, all the physical
file constraints and associated access paths are saved as well.

OL629.0
Notes:

11-41
Student Notebook
Lab exercise
IBM i

OL629.0
Notes:

V8.0
Student Notebook
Uempty
Unit summary
IBM i

Describe the considerations for using DB2 for i referential
integrity

OL629.0
Notes:

11-43
Student Notebook

V8.0
Student Notebook
Uempty
Unit 12. Triggers

DB2 for i triggers enable the user to establish automatic actions to
occur when an add, update, or delete is made to a database file. Thus,
the database not the application programs enforce the business rule
(action) to take place.

Describe the considerations for using DB2 for i triggers

Accountability
Machine exercise

Unit 12. Triggers
12-1
Student Notebook
Unit objectives
IBM i


OL629.0
Notes:
Triggers are user written programs that are identified in a file's description. When a
database add, delete, or change occurs, a program (trigger) associated with any or all of
the events (add, delete, or change) runs. The system passes relevant information, such as
the file name and record image, to the trigger program. The trigger program runs as part of
the job that caused the originating database event.

V8.0
Student Notebook
Uempty
DB2 for i triggers: Benefits

IBM i
Faster application development. Triggers enforce business

rules, not application programs.
Global enforcement of business rules. Trigger execution is
independent of which user, program, or utility made a change
to the database.
Easier maintenance. Business rule changes can be made by
changing one trigger program.
Improve performance in client/server environment. Triggers
run in the server.

Figure 12-2. DB2 for i triggers: Benefits
OL629.0
Notes:
Triggers offer the following benefits to your business:
Faster application development. Because the database stores triggers, you do not have
to code the trigger actions into each database application.
Global enforcement of business rules. Define a trigger once and then reuse it for any
application that uses the database.
Easier maintenance. If a business policy changes, you only need to change the
corresponding trigger program instead of each application program.
Improve performance in client/server environment. All rules run in the server before the
result returns.

Unit 12. Triggers
12-3
Student Notebook
Triggers: Introduction
IBM i
Triggers are user-written programs.

Associated with a physical file
Activated by DB2 for i before or after a database change
Independent from applications
Can be developed with any supported compiler
Part of the job that caused the trigger to run

Figure 12-3. Triggers: Introduction
OL629.0
Notes:
If your application environment needs to enforce particular business rules before or after
changes to the database take place, DB2 for i offers you the ability to automatically activate
a user written program (a trigger) which will perform any action you consider appropriate.
These programs can be almost independent from the applications affecting the contents of
the database. When a trigger is run, the application that fired the trigger will wait for its
completion, as if the trigger had actually been called by the application itself. Triggers are
associated with physical files and will be activated no matter how the database change
took place.
There is a broad range of situations where you might want to use triggers. They represent
a powerful tool to ensure that your database will always comply with your business needs,
providing consistent checking and taking the appropriate actions every time data is
changed. You can use them to monitor your critical files.

V8.0
Student Notebook
Uempty
Triggers: An example
IBM i
Orders file
Input Parameter
JOHN
Order entry
CUST
JOHN
FAX
558723
ORDER AAAA
QTY
40
558723 AAAA 40
WRITE DOC.
SNDFAX for
confirmation
DB2 for i
Fax machine
When a new order is inserted, a trigger starts.

The trigger gets information about the order and the
customer.
A confirmation fax is automatically sent.
Figure 12-4. Triggers: An example
OL629.0
Notes:
The visual shows an example of how triggers can be used to integrate a traditional
application, such as order entry, with advanced technologies. This could be the very
common case of a company acquiring orders over the phone, validating them, and sending
a confirmation fax to their customer afterwards. Using triggers, the fax could be
automatically sent to the customer as soon as the order is inserted into the database file
without changing the order entry application. The insert trigger is invoked every time an
order enters the orders file. The new record is automatically passed to the trigger program
as an input parameter. The program might produce a predefined document with the new
order data and customer data and send a fax to the customer.
On the i, triggers can be written in any supported compiled language, and there is virtually
no limitation to the functions that can be implemented by a trigger program. DB2 for i
triggers can take full advantage of any product, utility, or feature supported on the i system.

Unit 12. Triggers
12-5
Student Notebook
Trigger: Concepts
IBM i
Triggers can be activated either before or after the following

record events:
Read
Insert
Update
Delete
Cannot depend on the value of a field

Will be activated whenever the event occurs
Update triggers can be always activated or activated only if
data has changed.

Figure 12-5. Trigger: Concepts
OL629.0
Notes:
DB2 for i allows you to define trigger programs for four categories of events.
Read operations
Insert operations
Update operations
Delete operations
For each of these events, you can define after triggers or before triggers. An after trigger
will be invoked when the data change has already been reported to the database. For
instance, an after insert trigger will be invoked right after the record has been actually
written to the physical file. A before insert trigger will be activated before the record is
actually inserted. Also, a before trigger runs before any referential constraint is enforced,
whereas *RESTRICT rules will be checked before the execution of an after trigger.
A trigger will be activated whenever the record is affected by the I/O operation. If you need
to perform some actions when a certain field in your database has a specific value, you will
need to check for this condition in the trigger program. The current implementation of DB2

V8.0
Student Notebook
Uempty
for i does not allow you to specify a conditional activation of trigger programs depending on
a field's value.
When you evaluate the trade-offs of implementing a function by a trigger rather than within
an application program, always consider that triggers will be called every time the I/O
operation occurs, regardless of the interface that is performing the operation. The only
exception is update triggers, which you can choose to activate only when some field has
actually been changed in the record. In this way, you will prevent triggers from being called
when a program replaces a record with its exact copy without changing any data.

Unit 12. Triggers
12-7
Student Notebook
Execution order
IBM i
1. Before trigger
2. DB change
*RESTRICT
Non Rl errors, such as record not found
3. After trigger
4. Delete *CASCADE
5. Delete *SETNULL/*SETDFT
6. *NOACTION
7. Unique constraint enforcement

Figure 12-6. Execution order
OL629.0
Notes:
Execution order
1. Execute before trigger statements, if there are any.
2. Execute the change statement. If an RI RESTRICT rule (same as NO ACTION except
that enforcement is immediate) is defined for this file, evaluate it now. Detect errors not
associated with the RI constraints, for example, record not found.
3. Execute after trigger statements, if there are any.
4. Enforce all RI delete CASCADE rules (when a record in the primary file is deleted,
delete all records with matching foreign keys).
5. Enforce delete SET NULL (set the value of all nullable foreign key fields to null when the
corresponding primary key record is deleted) and SET DEFAULT (set all foreign key
fields to their default when the corresponding primary key record is deleted) rules.
6. Enforce NO ACTION rules.
7. Enforce unique constraint.
Any error during this execution cycle, such as an error in a trigger program or an RI
constraint violation, terminates the cycle. If there is an error, the system sends a message
identifying the error to the application.

V8.0
Student Notebook
Uempty
ADDPFTRG: Add physical file trigger

IBM i
FILE: *LIBL
*CURLIB
library-name
physical-file-name
TRGTIME: * BEFORE, *AFTER

TRGEVENT:
*INSERT, *DELETE, *UPDATE, *READ
PGM: *LIBL
*CURLIB
library-name
program-name
RPLTRG: *NO, *YES

TRGUPDCND: *ALWAYS, *CHANGE
ALWREPCHG: *NO, *YES
Figure 12-7. ADDPFTRG: Add physical file trigger
OL629.0
Notes:
On the i, a trigger program can be developed using any supported high-level language
compiler.
Triggers can be added to and removed from physical files by using two CL commands.
The ADDPFTRG command associates a trigger program with a physical file. Once this
association is established, DB2 for i will call the trigger program when a change
operation is performed against the physical file. This change could be through a logical
file or a view created by SQL.
When you add the trigger to the physical file, the file description will be updated to
reflect that a trigger has been associated with the file. You can recompile, restore,
rename, copy, and delete the program without affecting the file description. For
instance, when you update the trigger program, you do not need to remove the trigger
and add it again to the physical file. This flexibility allows you to change your business
rules without modifying the applications by just changing and recompiling trigger
programs. All applications accessing this database file will immediately comply with the
new rules.
Unit 12. Triggers
12-9
Student Notebook
If you specify *LIBL when you add the trigger, however, the actual library name will be
resolved and stored in the file description. This may lead to run-time errors if you move
triggers to different libraries.
ALWREPCHG(*YES) affects trigger programs defined to be called before insert and
update database operations. If the trigger program updates the new record in the trigger
buffer and ALWREPCHG(*YES) is specified, the modified new record image is used for
the actual insert or update operation on the associated physical file.
The RMVPFTRG command removes the association of a file and trigger program. Once
you remove this association, no action is taken if a change is made to the physical file.
The trigger program will not be deleted by RMVPFTRG.

V8.0
Student Notebook
Uempty
RMVPFTRG: Remove physical file name

IBM i
FILE:
physical-file-name
TRGTIME:
TRGEVENT:
*ALL, *BEFORE, *AFTER

*ALL, *INSERT,
*DELETE, *UPDATE

Figure 12-8. RMVPFTRG: Remove physical file name
OL629.0
Notes:

Unit 12. Triggers
12-11
Student Notebook
ADDPFTRG and RMVPFTRG considerations

IBM i
Trigger information is stored in the file's description.

An unqualified trigger program name is resolved at
ADDPFTRG time.
Renaming, moving, or deleting a trigger does not change the
file's description. You must use RMVPFTRG and ADDPFTRG.
Trigger programs can be modified, for example, to change
your business rules, without having to RMVPFTRG and
ADDPFTRG.

Figure 12-9. ADDPFTRG and RMVPFTRG considerations
OL629.0
Notes:
Use the Change Physical File Trigger (CHGPFTRG) command to enable or disable a named
trigger or to enable or disable all triggers for a file. Disabling the trigger causes the trigger
program not to be called when a change operation occurs to the physical file. Enabling the
trigger causes the trigger program to be called again when a change operation occurs to
the physical file. You can also enable or disable a trigger using System i Navigator.

V8.0
Student Notebook
Uempty
Trigger parameters (1 of 2)
IBM i
Parameter 1
Offset
Dec
Type
Hex
Field
CHAR(10)
Physical file name
10
CHAR(10)
Physical file library name
20
14
CHAR(10)
Physical file member name
30
1E
CHAR(1)
Trigger event
31
1F
CHAR(1)
Trigger time
32
20
CHAR(1)
Commit lock level
33
21
CHAR(3)
Reserved
36
24
BINARY(4)
CCSID of data
40
28
BINARY(4)
Relative record number
44
2C
CHAR(4)
Reserved
48
30
BINARY(4)
Original record offset
52
34
BINARY(4)
Original record length

Figure 12-10. Trigger parameters (1 of 2)
OL629.0
Notes:
The table in the visual shows the parameter list that DB2 for i will automatically provide to
triggers when they are invoked. You have to take care of defining these parameters when
you code trigger programs. Programmers will use the offset and length information to
decode the original and new record information also contained within Parameter 1 (the
trigger buffer).
Trigger event: This information is particularly useful when the same trigger has been
associated with different events. You might want to develop a common trigger for all
kinds of I/O operations and take the appropriate actions depending on the operation
types.
Commit lock level: Since triggers are application independent, they can be activated
either with or without commitment control, depending on the commit lock level of the
underlying application. This parameter provides a way to determine at runtime whether
the trigger is running under commitment control and what the commit lock level is.
Application programmers should open database files in triggers using the appropriate
commitment control option. Dynamic commitment definition for files is provided by C
and ILE RPG.
Unit 12. Triggers
12-13
Student Notebook
Trigger parameters (2 of 2)
IBM i
Parameter 1 continued
56
38
BINARY(4)
Original record null byte map offset
60
3C
BINARY(4)
Original record null byte map length
64
40
BINARY(4)
New record offset
68
44
BINARY(4)
New record length
72
48
BINARY(4)
New record null byte map offset
76
4C
BINARY(4)
New record null byte map length
80
50
CHAR(16)
Reserved
CHAR(*)
Original record
CHAR(*)
Original record null byte map
CHAR(*)
New record
CHAR(*)
New record null byte map
Parameter 2
BINARY(4)
Trigger buffer length

Figure 12-11. Trigger parameters (2 of 2)
OL629.0
Notes:
Old and new record images: Trigger programs are provided the images of the record
before and after the database change. This information is essential when the trigger
needs to perform data validation.
Old and new record null map: This parameter is an array of as many characters as
the number of fields in the database record. If the corresponding fields are null, the
character will be set to 1.
By changing the trigger buffer (new record), the programmer can modify the data placed in
the physical file on *BEFORE/*INSERT or *BEFORE/*UPDATE provided
ALWREPCHG(*YES) is specified on the ADDPFTRG command.
See DB2 for i Database Programming for additional information.

V8.0
Student Notebook
Uempty
Suppose trigger ends abnormally

IBM i
Trigger program
Application program
DB operation with
associated trigger
Program should check
for error on DB
operation
OS/400
I/O Module
Failure
Error
message
DB operation will fail

SQL: SQLCODE=443
COBOL: File Status 90
RPG: Operation Error Indicator and message RPG1299
CL: Message CPF502B
C: ERRNO set to EIORECERR
Figure 12-12. Suppose trigger ends abnormally
OL629.0
Notes:
When implementing your trigger program, you have to consider that triggers do not have
the ability to pass parameters back directly. This is because trigger programs are activated
by the database manager and are given an input-only parameter list.
If a failure occurs while the trigger program is running, an appropriate escape message
must be signaled before the trigger terminates. The message can be the original message
that is signaled by the system or a user defined message retrieved from a message file by
the trigger program.
If no error message is signaled to the calling program after a trigger has failed, the
database manager will assume that the trigger completed successfully, and the operation
that activated the trigger will be completed as well.
If the trigger fails due to a system-generated exception, such as a lock time-out or a failed
file open, the exception will look for an exception handler in the trigger. If none is found, the
exception percolates back in search of an appropriate exception handler. The exception
might reach the database module which is performing the I/O operation that fired the
trigger. The I/O operation will fail.
Unit 12. Triggers
12-15
Student Notebook
The application should monitor trigger failures the same way you generally monitor
ordinary database failures. The following is a list of the return codes you can rely on for
monitoring trigger failures:
SQL application: SQLCODE = 443 (trigger program or external procedure detected an
error).
COBOL language: File status = 90
RPG language: The indicator will be turned on and you will also get an RPG1299
message.
CL language: A message CPF502B will be received.
C application: The errno variable is set to EIORECERR.

V8.0
Student Notebook
Uempty
Logical trigger failure

IBM i
Application program
DB operation with
associated trigger
Check for error
*ESCAPE
message
OS/400
I/O Module
z Trigger should send on

*ESCAPE message to OS/400
I/O module.
z Non CL programs can use
QMHSNDPM API.
z Application program gets
trigger failure message.
z Originating DB change will fail.
Trigger program
If logical error,
send a message

Figure 12-13. Logical trigger failure
OL629.0
Notes:
If the trigger determines a logical failure, you might want the originating change to fail.
This situation is very common in data validity checking. For example, let's consider the
case of an insert trigger, checking the customer's credit limit on an order being inserted.
When the order is inserted, the i5/OS module QDBPUT will be invoked.
If the trigger determines that the order exceeds the allowed amount, the insert operation
has to be rejected. We can achieve this by sending an escape message to the call stack
entry where QDBPUT is running. For this purpose, use the QMHSNDPM API to signal an
escape message to QDBPUT. The application will receive an error message. See the
previous visual for the error message received by various programming languages.

Unit 12. Triggers
12-17
Student Notebook
Data integrity and trigger failures

IBM i
Application program
Trigger program
update...
Update (file A)
Delete (file B)
Insert (file C)
If insert OK
Commit
Else roll back
Implicit
roll back
insert...
Error
message
Failure
delete
Recommend application and trigger use commitment control

(same definition)
Data integrity maintained between application and trigger
Figure 12-14. Data integrity and trigger failures
OL629.0
Notes:
The preceding two visuals describe under what conditions and how an error message is
sent to the application program.
In order to ensure the best level of data consistency, we recommend you use commitment
control in your applications. If your database design includes triggers, you should be aware
of the implications of using commitment control for the resources accessed by the trigger
programs. To avoid potential exposures to data integrity, triggers and applications should
share the same commitment definition. In this case, all the changes performed by triggers
should be committed or rolled back by the application itself. The safest way to ensure that
this happens is to compile your triggers with ACTGRP(*CALLER). Triggers and
applications should also share the same lock level.
If triggers run in a separate commitment control definition, they must commit or roll back
their changes because the application will not be able to do that. There are potential record
locking and consistency exposures in this situation because if the trigger terminates
normally without committing its changes, the application will not be able to release the

V8.0
Student Notebook
Uempty
locks on those records. Having different commitment definitions for triggers and
applications should be pursued only if strictly necessary.
The visual shows what happens when a trigger terminates abnormally due to an
unmonitored failure and both trigger and application run under commitment control. Both
the changes performed by the trigger and the originating change performed by the
application are rolled back together. This process does not affect other changes previously
done by the application. The application can still choose to commit or roll back those
changes.
If your triggers modify database data, we suggest you use commitment control in both
applications and triggers. This is the safest way to ensure the integrity of your data.

Unit 12. Triggers
12-19
Student Notebook
Additional trigger considerations and

recommendations (1 of 2)
IBM i
Triggers can call other programs.

Triggers can cause other triggers to execute.
SEQONLY(*YES) changed to SEQONLY(*NO) if the file has a
trigger.
Cannot include COMMIT, ROLLBACK, or ENDCMTCTL for the
same commit definition as the original DB change.
There are special considerations and restrictions regarding
triggers changing the record of the original DB change.

Figure 12-15. Additional trigger considerations and recommendations (1 of 2)
OL629.0
Notes:
Refer to DB2 for i Database Programming.
A trigger program can be a high-level language, SQL, or CL program.

V8.0
Student Notebook
Uempty
A trigger program cannot include the following commands, statements, and operations. If
they are used, an exception is returned.
The COMMIT and ROLLBACK operations are not allowed for the commitment definition
associated with the insert, update, or delete operation that called the trigger. A COMMIT
or ROLLBACK operation is allowed for any commitment definition in the job.
The SQL CONNECT, DISCONNECT, SET CONNECTION, and RELEASE statements
are not allowed.
The ENDCMTCTL CL command is not allowed for the commitment definition associated
with the insert, update, or delete operation that called the trigger. An ENDCMTCTL CL
command is allowed for any other commitment definition in the job.
An attempt to add a local API commitment resource (QTNADDCR) to the same
commitment definition associated with the insert, update, or delete operation that called
the trigger will result in an error.
An attempt to do any I/O to a file that has been opened by a trigger program with
*SHAPE and is the file that caused the trigger program to be called will result in an
error.
The commit lock level of the application program is passed to the trigger program. It is
recommended that the trigger program run under the same lock level as the application
program.
The trigger program and application program may run in the same or different activation
groups. It is recommended that the trigger program be compiled with ACTGRP(*CALLER)
to achieve consistency between the trigger program and the application program.
A trigger program can call other programs or can be nested (that is, a statement in a trigger
program causes the calling of another trigger program). In addition, a trigger program may
be called recursively by itself. The maximum trigger nested level for insert and update is
200. When the trigger program runs under commitment control, the following situations will
result in an error:
Any update of the same record that has already been changed by the change operation
or by an operation in the trigger program.
Produce conflicting operations on the same record within one change operation. For
example, a record is inserted by the change operation and then deleted by the trigger
program.
If the change operation is not running under commitment control, the change operation
is always protected; however, updating the same record within the trigger program will
not be monitored.
The allowing of repeated changes when running under commitment control are
controlled by the ALWREPCHG (*NO|*YES) parameter of the Add Physical File Trigger
(ADDPFTRG) command. Changing from the default value to ALWREPCHG (*YES)
allows the same record or updated record associated with the trigger program to be
repeatedly changed.
The ALWREPCHG(*YES) parameter on the Add Physical File Trigger (ADDPFTRG)
command also affects trigger programs defined to be called before insert and update
Unit 12. Triggers
12-21
Student Notebook
database operations. If the trigger program updates the new record in the trigger buffer and
ALWREPCHG(*YES) is specified, the modified new record image is used for the actual
insert or update operation on the associated physical file. This option can be helpful in
trigger programs that are designed for data validation and data correction. You should be
aware that because the trigger program receives physical file record images (even for
logical files), the trigger program is allowed to change any field that of that record image.
The trigger program is called for each row that is changed in the physical file.
If the physical file or the dependent logical file is opened for SEQONLY(*YES) and the
physical file has a trigger program associated with it, the system changes the open to
SEQONLY(*NO) so it can call the trigger program for each row that is changed.

V8.0
Student Notebook
Uempty
Additional trigger considerations and

recommendations (2 of 2)
IBM i
Same library for trigger and file to simplify save, restore, and
CRTDUPOBJ
Special considerations: DLTF, CPYF, CLRPFM, and INZPFM
Trigger: USRPRF(*OWNER)
Journaling
Journal files updated by triggers
APYJRNCHG and RMVJRNCHG
Include trigger files
Trigger suspended
Same commit definition for application and trigger

ACTGRP(*CALLER) for trigger
Same commit lock level
Figure 12-16. Additional trigger considerations and recommendations (2 of 2)
OL629.0
Notes:
Refer to DB2 for i Database Programming.
The following IBM i functions are also impacted by triggers:
Save/Restore Base File (SAVOBJ/RSTOBJ): The save/restore function will not search
for the trigger program during save/restore time. It is the user's responsibility to manage
the program. During run time, if the trigger program has not been restored, a hard error
with the trigger program name, physical file name, and trigger event is returned.
If the entire library (*ALL) is saved and the physical file and all trigger programs are in
the same library and they are restored in a different library, then all the trigger program
names are changed in the physical file to reflect the new library.
Save/Restore Trigger Program (SAVOBJ/RSTOBJ): If the trigger program is restored in
a different library, the change operation fails because the trigger program is not found in
the original library. A hard error with the trigger program name, physical file name, and
trigger event information is returned.
There are two ways to recover in this situation.
Unit 12. Triggers
12-23
Student Notebook
- Restore the trigger program to the same library.

- Create a new trigger program with the same name in the library.
Create Duplicate Object (CRTDUPOBJ): When a trigger program and the base physical
file are originally in the same library, the following applies:
- If the CRTDUPOBJ command is specified with OBJ(*ALL), the new trigger program
is associated with the new physical file.
- If either a trigger program or the base physical file is duplicated separately, the new
trigger program is still associated with the old physical file.
When the trigger program and the physical file are originally in different libraries, the
duplicate trigger program is associated with the same physical file as the original trigger
program. Even though the physical file is duplicated to the same new library, the
duplicated trigger program is still associated with the original physical file.
Delete File (DLTF): The association between the trigger program and a deleted file is
removed. The trigger programs remain on the system.
Copy file (CPYF): If a to-file is associated with an insert trigger, each inserted record
causes the trigger program to be called. If a to-file is associated with a delete trigger
program and MBROPT(*REPLACE) is specified on the CPYF command, the copy
operation fails. Copy with CREATE(*YES) specified does not propagate the trigger
information.
Clear Physical File Member (CLRPFM): If the physical file is associated with a delete
trigger, the CLRPFM operation fails.
Initialize Physical File Member (INZPFM): If the physical file is associated with an insert
trigger, the INZPFM operation fails.
Apply Journaled Changes or Remove Journaled Changes
(APYJRNCHG/RMVJRNCHG): If the physical file is associated with any type of trigger,
the APYJRNCHG and RMVJRNCHG operations do not cause the trigger program to be
invoked. Therefore, you should be sure to have all the files within the trigger program
journaled. Then, when using the APYJRNCHG or RMVJRNCHG commands, be sure to
specify all of these files. This insures that all the physical file changes for the application
program and the trigger programs are consistent.
Note: If any trigger program functions are not related to database files and cannot be
explicitly journaled, you should consider sending journal entries to record relevant
information. You can use the Send Journal Entry (SNDJRNE) command or the Send
Journal Entry (QJOSJRNE) API. You will have to use this information when the
database files are recovered to ensure consistency.
The following suggestions are recommended in a trigger program:
Create the program with USRPRF(*OWNER) and do not grant authorities to the trigger
program to USER(*PUBLIC). Avoid having the trigger program altered or replaced by
other users. The database invokes the trigger program whether or not the user causing
the trigger program to run has authority to the trigger program.

V8.0
Student Notebook
Uempty
Create the program as ACTGRP(*CALLER) if the program is running in an ILE

environment. This allows the trigger program to run under the same commitment
definition as the application.
Open the file with a commit lock level the same as the application's commit lock level.
This allows the trigger program to run under the same commit lock level as the
application.
Create the program in the change file's library.
Use commit or rollback in the trigger program if the trigger program runs under a
different activation group than the application.
Signal an exception if an error occurs or is detected in the trigger program. If an error
message is not signaled from the trigger program, the database assumes that the
trigger ran successfully. This may cause the user data to end up in an inconsistent
state.

Unit 12. Triggers
12-25
Student Notebook
Trigger can perform update cascade (1 of 2)

IBM i
EMPL
DEPT
DEPTNO DEPTNAM
100
Accounting
105
Finance
EMPNO
DEPTNO
TNAM
1001
110
DOUG
1121
100
JUDY
1972
105
ERNEST
110
Shipping
1097
105
GREG
115
Sales
1234
115
DAVE
Referential constraint: UPDRULE (*NOACTION)

ADDPFTRG FILE(DEPT) TRGTIME(*AFTER) TRGEVENT(*UPDATE)
PGM(DEPTTRG)
Desired: If DEPTNO is changed in DEPT file, update corresponding
records in EMPL file.
Figure 12-17. Trigger can perform update cascade (1 of 2)
OL629.0
Notes:
DB2 for i does not support the update cascade rule; however, a trigger program can be
written to produce the same effect.
You can use triggers to enforce referential constraints and business rules. For example,
you could use triggers to simulate the update cascade constraints on a physical file;
however, you would not have the same functional capabilities as provided by the
constraints defined with the system referential integrity functions. The following referential
integrity advantages may be lost if the constraints are defined with triggers:
Dependent files may contain rows that violate one or more referential constraints that put
the constraints into check pending but still allow file operations.
The ability to inform users when a constraint has been placed in check pending.
When an application is running under COMMIT(*NONE) and an error occurs during a
cascaded delete, all changes are rolled back by the database.
While saving a file that is associated with a constraint, all dependent files stored in the
same library in a database network are saved.

V8.0
Student Notebook
Uempty
Trigger can perform update cascade (2 of 2)

IBM i
The following sequence of events is used:

1. Someone changes DEPTNO 105 in DEPT file to 125.
2. After trigger DEPTTRG changes the department number for
ERNEST and GREG to 125.
3. Referential integrity (*NOACTION) is checked. There is no
violation.

Figure 12-18. Trigger can perform update cascade (2 of 2)
OL629.0
Notes:

Unit 12. Triggers
12-27
Student Notebook
Checkpoint
IBM i
1. Triggers are (blank) that are identified in a files description.

a. IBM programs
b. HLL, user written programs
c. SQL
d. RPG IV
2. True or False: When a database add, delete, or change

occurs, a trigger associated with any or all the events runs.
3. True or False: Renaming, moving, or deleting a trigger
program changes the related files file description.

OL629.0
Notes:

V8.0
Student Notebook
Uempty
Lab exercise
IBM i
Triggers

OL629.0
Notes:

Unit 12. Triggers
12-29
Student Notebook
Unit summary
IBM i


OL629.0
Notes:

V8.0
Student Notebook
Uempty
Unit 13. Course summary

This unit will summarize the course.

Summarize the objectives of this course

13-1
Student Notebook
Unit objectives
IBM i

Summarize the objectives of the course

OL629.0
Notes:

V8.0
Student Notebook
Uempty
What can you do now?

IBM i
After completing this course, you should be able to

Create the physical and logical files required to implement a
database design
Design the function of and create a field reference file
Explain how choices made while coding and creating a file
affect performance
Understand the different ways to interface to DB2 for i
Perform database maintenance
Understand the concepts of referential integrity and triggers

Figure 13-2. What can you do now?
OL629.0
Notes:
We have covered a lot of subjects in this class, and you may feel a little overwhelmed;
however, once you return to the office and begin to use what you have learned, you will find
that the information provided in this class has given you a solid foundation of knowledge.
But you have more work to do!

13-3
Student Notebook

V8.0
Student Notebook
Uempty
13.1.Your next step

13-5
Student Notebook
Your next step

IBM i
Programming courses
RPG IV
Version 7 Free Format Coding
AS060/OV600 RPG IV Programming Fundamentals Workshop for IBM i
AS070/OV700 RPG IV Programming Intermediate Workshop for IBM i
AS100/OV100 RPG IV Programming Advanced Workshop for IBM i
Control language programming

OL201/OV201 Control Language Programming Workshop for IBM i

Figure 13-3. Your next step
OL629.0
Notes:
Go to http://www-304.ibm.com/jct03001c/services/learning/.

V8.0
Student Notebook
Uempty
Database courses
IBM i
OL370/OV370
Accessing the i Database Using SQL
OL30/OV380
Developing i Applications Using SQL
OD470/OV470
IBM i DB2 and SQL School
OL390/OV390
DB2 UDB for i SQL Advanced Programming

Figure 13-4. Database courses
OL629.0
Notes:
In order to know how to use SQL, you should definitely attend OL370. OL380 will teach you
how to embed SQL in RPG IV programs and how to code stored procedures (external).As
an alternative, OD470 combines material from OL370 and OL380 into one course.

13-7
Student Notebook
Congratulations!
IBM i
Thanks for
coming
Please come
again

Figure 13-5. Congratulations!
OL629.0
Notes:

V8.0
Student Notebook
Uempty
Unit summary
IBM i
Having completed this unit you should be able to

Summarize the objectives of the course

OL629.0
Notes:

13-9
Student Notebook

V8.0
Student Notebook
AP
Appendix A. Checkpoint solutions

Unit 1, "Introduction to DB2 for i database"
Solutions for Figure 1-10, "Checkpoint," on page 1-11
Checkpoint solutions
IBM i
1. True or False: All data items in a relational database are stored in

base tables.
The answer is True.
2. Which of the following are relational operators?

a. Selection
b. Projection
c. Joins
d. All of the above
The answer is All of the above.
3. True or False: The IBM i implementation of a relational database has

performance advantage over the traditional implementation in that it is
an integrated part of the operating system.
The answer is True.

A-1
Student Notebook
Unit 2, "Physical files"

IBM i
1. True or False: Data description specifications (DDS) describe data

attributes of files to the system.
The answer is True.
2. DDS keywords
a. Enable additional field attributes to be specified
b. Can be specified at the file and record levels
c. Can be specified at the field and key levels
d. All of the above
3. The REF keyword

a. Identifies the record format referenced for the definition of a field
b. Identifies the field referenced for the definition of another field
c. Identifies the file referenced for the definition of a field
d. Identifies only a field reference file
The answer is Identifies the file referenced for the definition of a field.

A-2

V8.0
Student Notebook
AP
Unit 3, "IBM i application development tools"

IBM i
1.
The LPEX Editor can be used to download IBM i source members and maintain
them in disconnected mode from your PC workstation.
a. Isolated
b. Check
c. Disconnected
d. Verify
The answer is Disconnected.
2.
In order to modify existing DDS for a physical file, you can use:
a. PDM/SEU
b. RSE/LPEX
c. REX
d. For all of the above
The answers are PDM/SEU and RES/LPEX.
3.
True or False: RDP and WDS provide an environment where you can
interchangeably maintain source code using workstation tools or host-based tools.
The answer is True.

A-3
Student Notebook
Unit 4, "Adding data to physical files"

IBM i
1.
The format option (FMTOPT) parameter of the CPYF command is required when the from-file does
not exactly match the to-file.
a. Optional
b. Required
c. Specified as *NOCHK
d. Not needed
The answer is Required.
2.
Which of the following methods can be used to add data to a physical file?
a. The CPYF command.
b. A data file utility.
c. An interactive program.
3.
The CPYF command can be used to:

a. Extract sample data from a large file for testing purposes.
b. Produce a list of specific data from a file.
c. Convert data to another file format.
d. Perform all of the above.
The answer is Perform all of the above.
A-4

V8.0
Student Notebook
AP
Unit 5, "Field reference file"

IBM i
1. True or False: A field reference file is a physical file

referenced in other physical files as the place where one or
more fields are defined.
The answer is True.
2. True or False: A field reference file cannot have a data

member nor can it have keyed access.
The answer is False.
3. True or False: Only one file level REF keyword can be

coded.
The answer is True.


A-5
Student Notebook
Unit 6, "Non-join logical files"

Solutions for Figure 6-23, "Checkpoint (1 of 2)," on page 6-25
Checkpoint solutions (1 of 2)
IBM i
1.
A logical file is created to implement which of the following relational database operators:
a. Sequence
b. Selection
c. Format sharing
d. Keyed access
The answers are Sequence and Selection.
2.
True or False: A logical file can convert the data type of a physical file before presenting the data to
a program using the file.
The answer is True.
3.
This logical file is performing the sequencing and projection operators.

R
COUINQ
CRSDSC
CRSPRC
CRSDSC
a. Sequencing and selection

b. Sequencing and projection
c. Union and selection
d. Union and projection
The answers are Sequencing and projection.
A-6

V8.0
Student Notebook
AP
IBM i
4. True or False: A maximum number of 32 files can be named

in a union logical file.
The answer is True.
5. True or False: When defining a union between multiple

physical files with selected fields, only the fields that are
common to all the physical files may be named.
The answer is True.
6. True or False: You cannot change the name of a field in the

logical file from its original name in the physical file.


A-7
Student Notebook
Unit 7, "Join logical files"

IBM i
1. True or False: A join logical file is a logical file that combines

(in one record format) fields from two or more physical files.
The answer is True.
2. True or False: A join logical file is a logical file that can be

used by programs for adding and updating data.
3. True or False: The JREF keyword allows you to specify

which file a field comes from when the same names exist.
The answer is True.

A-8

V8.0
Student Notebook
AP
Unit 8, "Database maintenance considerations"

IBM i
1. True or False: System cross-reference files are automatically updated

by IBM i/OS whenever any database (PF and LF) file changes occur.
The answer is True.
2. Source files can be searched with the FNDSTRPDM command.

a. DSPFFD
b. DSPDBR
c. FNDSTRPDM
d. DSPPGMREF
The answer is FNDSTRPDM.
3. True or False: The CHGPF command causes the data in the existing
file to be associated to a new format (specified with the SRCFILE
parameter) based on field names, allowing data format changes.
The answer is True.

A-9
Student Notebook
Unit 9, "Interface to DB2 for i"

IBM i
1.
DFU is a program generator that helps you create programs to:

a.
Enter data into files
b.
Update data in existing files
c.
Make file inquiries
d.
All the above
The answer is All the above.
2.
In order to update an existing file with DFU without having to define a program, use UPDDTA.
a.
STRDFU
b.
CHGDTA
c.
UPDDTA
d.
DSPDTA
The answer is UPDDTA.
3.
Which function key (Fxx) will delete the currently displayed record from the file?
a.
F11
b.
F10
c.
F21
d.
F23
The answer is F23.
4.
True or False: RSE filtering provides function similar to PDM libraries, objects, and members.
The answer is True.

A-10 Coding Using DDS and CL Commands

V8.0
Student Notebook
AP
IBM i
5.
True or False: All IBM i systems access interactive SQL with the command
STRSQL.
6.
True or False : A series of SQL statements can be run interactively as a group

using STRSQL.
7.
True or False: The SELECT statement is the data retrieval statement in SQL.
The answer is True.
8.
True or False: System i Navigator has a GUI interface to SQL as well as a

statement entry screen.
The answer is True.
9.
True or False: Query for IBM i and Query Manager can both be used to run
queries of data files.
The answer is True.
10. True or False: Query Manager does not allow for creating tables.

A-11
Student Notebook
Unit 10, "Database performance considerations for application

design"
IBM i
1. When does automatic access path sharing occur?

a. When two or more files are based on the same physical files and the same key fields
in the same order.
b. When a logical file with a keyed sequence access path is created and an access path
exists on the system that satisfies the same criteria.
c. When a new logical file has select/omit specifications that are identical to the
select/omit specifications of the existing access path.
2. Which of the following file attribute parameters can positively affect

applications that utilize the files?
a. SHARE( )
b. DLTPCT( )
c. SIZE( )
d. RECOVER( )
The answer is SHARE( ).

V8.0
Student Notebook
AP
IBM i
3. True or False: If using a variable length data field, be sure to

keep records with overflowed field data to less than 10% of
the total number of records.
The answer is True.


A-13
Student Notebook
Unit 11, "Referential integrity"

IBM i
1.
When defining a referential constraint

a. The parent and dependent files must be physical files with one member.
b. There is no maximum number of constraint relations per file.
c. Only program described files are allowed.
d. Files must be in the QTEMP library.
The answer is The parent and dependent files must be physical files with one member.
2.
A user can display or output constraints and the related attributes for a file with
The DSPFD TYPE(*CST) command, The WRKPFCST command, and DSPDBR
command.
a. The DSPFD TYPE(*CST) command
b. The WRKPFCST command
c. DSPDBR command
The answers are The DSPFD TYPE(*CST) command, The WRKPFCST command, and DSPDBR
command.
3.
True or False: When a set of database files is saved, all the physical file
constraints and associated access paths are saved as well.
The answer is True.


V8.0
Student Notebook
AP
Unit 12, "Triggers"

IBM i
1. Triggers are HLL, user written programs that are identified in a files
description.
a. IBM programs
b. HLL, user written programs
c. SQL
d. RPG IV
The answer is HLL, user written programs.
2. True or False: When a database add, delete, or change occurs, a

trigger associated with any or all the events runs.
The answer is True.
3. True or False: Renaming, moving, or deleting a trigger program

changes the related files file description.
Unit 13, "Course summary"

No checkpoint solutions in this unit.

A-15
Student Notebook

V8.0
backpg
Back page

Ol 629 Stud

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ol 629 Stud

Uploaded by

Copyright:

Available Formats

V8.

DB2 for i: DB Coding and

Adobe is either a registered trademark or a trademark of Adobe Systems Incorporated in

June 2013 edition

Copyright International Business Machines Corporation 1997, 2013.

Copyright IBM Corp. 1997, 2013

CRTPF: Create physical file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-32

Coding Using DDS and CL Commands

Copyright IBM Corp. 1997, 2013

Course materials may not be reproduced in whole or in part

Unit 5. Field reference file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

Multiple secondary matches case (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-8

Coding Using DDS and CL Commands

Copyright IBM Corp. 1997, 2013

Course materials may not be reproduced in whole or in part

Run SQL scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-77

Coding Using DDS and CL Commands

Copyright IBM Corp. 1997, 2013

Course materials may not be reproduced in whole or in part

Trigger parameters (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12-14

Coding Using DDS and CL Commands

Copyright IBM Corp. 1997, 2013

Course materials may not be reproduced in whole or in part

Adobe is either a registered trademark or a trademark of Adobe Systems Incorporated in

Copyright IBM Corp. 1997, 2013

Coding Using DDS and CL Commands

Copyright IBM Corp. 1997, 2013

Course materials may not be reproduced in whole or in part

Copyright IBM Corp. 1997, 2013

Coding Using DDS and CL Commands

Copyright IBM Corp. 1997, 2013

Course materials may not be reproduced in whole or in part

Copyright IBM Corp. 1997, 2013

Coding Using DDS and CL Commands

Copyright IBM Corp. 1997, 2013

Course materials may not be reproduced in whole or in part

Unit 1. Introduction to DB2 for i database

What you should be able to do

How you will check your progress

Copyright IBM Corp. 1997, 2013

Unit 1. Introduction to DB2 for i database

Course materials may not be reproduced in whole or in part

After completing this unit, you should be able to:

Copyright IBM Corporation 1997, 2013. All Rights Reserved.

Figure 1-1. Unit objectives

Coding Using DDS and CL Commands

Copyright IBM Corp. 1997, 2013

Course materials may not be reproduced in whole or in part

The relational model

All data items are in base tables.

Copyright IBM Corporation 1997, 2013. All Rights Reserved.

Figure 1-2. The relational model

Copyright IBM Corp. 1997, 2013

Unit 1. Introduction to DB2 for i database

Course materials may not be reproduced in whole or in part

Sequence (row sequence)

Copyright IBM Corporation 1997, 2013. All Rights Reserved.

Figure 1-3. Relational operators

Coding Using DDS and CL Commands

Copyright IBM Corp. 1997, 2013

Course materials may not be reproduced in whole or in part

Copyright IBM Corporation 1997, 2013. All Rights Reserved.

Figure 1-4. Sequence