Sie sind auf Seite 1von 36

IBC233 - Class Notes Week 1


please just call me "Tim" if you are comfortable doing so homepage: please make sure your learn email works Note re email: this is not a correspondence course

System i, i5, iSeries, AS/400, System/38 - what is it? OPERATING SYSTEM - i5/OS

called i5/OS. Previously called OS/400 written in C++ virus free secure POSIX compliant (open systems standard) DB2/UDB built in and integrated with all system functions server clustering and central management of other servers on network no MSCE / CNE / CNA /Oracle DB Administrators required ... only normal humans needed for general operations menu and list driven interface on low cost terminals GUI interface for general functions (Operations Navigator) GUI client using WebSphere Studio products for software development Control Language programming for general operations programming languages are integrated with the built in RDBMS - no APIs for normal data processing; minimal APIs for sophisticated error recovery


world's fastest Java server side performance C / C++ COBOL -- the world's most used business programming language RPG -- the world's second most used business programming language ... language of choice for iSeries client server with Java, VB, VRPG, VC++


native object based library system with built in relational data base configurable into multiple virtual schemas Integrated File System (IFS) o supports ASCII stream files for interaction with other systems o QOpenSys - fully UNIX compatible hierarchical file system o QDLS - DOS compatible hierarchical file system o user defined hierarchical file system o use the QSHELL to execute UNIX commands on these file systems


an object has a name and takes up space - each object has a type (*LIB, *PGM, *FILE) some objects have attributes. e.g. *PGM types include RPG, CLP; *FILE types include PF (Physical File [table]), LF (Logical File [view]) all objects are organized in libraries libraries cannot contain other libraries but they do contain all other objects files (*FILE) are a type of object that contain members. A member is an instance of a file that contains data. The file object is the database definition only -- the member(s) hold the actual data. An example is a file called QCLSRC which contains a member for each Control Language program's source code.


standard User ID and password (can be seamless with NT on IPCS) FIRST LOOK at a MENU SCREEN o four(4) parts of screen: screen header menu options command input

function keys MOVING around o commands o menu choices o function keys o GO MAIN -- main menu o GO MAJOR -- major commands menu o GO VERB -- action menu o GO SUBJECT -- objects menu

IBC233 - iSeries Business Computing WHY ARE YOU TAKING THIS COURSE?

single most popular multi-user platform in history o "i" in iSeries means integrated o 800,000+ AS/400s and iSeries platforms out there as of 2001 o iSeries for I/O intensive applications, i.e. commercial transaction processing workloads, and also for non-scientific compute-intensive workloads: e.g. Java and web services o IBM's iSeries division about the same size as Sun Microsystems o world's fastest, most secure, most scalable server-side Java platform (SPECjbb2000 benchmark) o more ERP solutions run on iSeries than any other platform o lowest cost of ownership for ERP o best server for Domino o better alternative than server farms Supports up to 254 partitions running IBM i5/OS, and IBM AIX 5L or Linux. With micropartitioning, allows up to 10 partitions per processor. can run 48 Integrated xSeries (Intel) Servers and 60 Integrated xSeries Adapters on a single iSeries and attach another 16 iSeries together for a total of 1,728 Windows servers managed from a single point. o UNIX almost died in commercial use, then the Internet thing happened. NT could not scale up as a reliable web & email server, AS/400s did not do web serving at the time, so UNIX was the only game for a while. JOBS!!!! o fewer jobs

that pay 10% better than industry average with less people chasing them o one example: TOMMY HILFIGER UNIQUE SYSTEM o IBM's "Future System" project to replace the mainframe o iSeries Proprietary vs UNIX

What is proprietary about a system that ...

runs Linux and Apache is POSIX compliant supports virtually all communication protocols runs SQL, pure Java, ANSI standard C, C++, and COBOL fully supports UNIX and Windows file systems runs FTP, Telnet, NFS, and serves Web pages like UNIX, the iSeries does all this and more.

total cost of ownership (TCO) for enterprise resource management (ERM) applications. IDC, 2001 Users Servers Server Downtime per per IT life Reliability Hours /user /year Small Large server staff (years) 1,435 983 375 201 113 3.5 2.5 1.3 8.0 6.6 4.5 99.98% 99.90% 99.67% 12.4 63.4 202.5 5 yr TCO US$/User


iSeries Unix Wintel

2,741 1,551 2,800 1,691

System i platform

on demand computing environments for IBM i5/OS (the latest generation of IBM OS/400), IBM AIX 5L, Microsoft Windows, Linux (Apache, etc), IBM WebSphere, Lotus Domino and Java solutions scalable ... spans small departmental (server) to enterprise (mainframe) sizes complete 64 bit system since 1995: i.e. RISC processor and OS and ALL application software all 64 bit. POWER5 is the 9th generation 64-bit RISC processor, the world's fastest, and available on the new i5 models systems with 4+ CPUs come with all the possible CPUs (up to 64) but you pay for only what you use

-- Capacity Upgrade on Demand is available with a phone call to IBM for short term rental or purchase of (i.e. activate) more CPUs as needed super-computer memory architecture integrated PC Server(s) available to run Microsoft server applications sharing iSeries resources RAID 0 and/or RAID 5 for disk multi-level RAID 0 mirroring for bus, I/O controller, disk drives 'clustering' for non-stop systems electronic customer support from the best customer support in IT the smallest unit costs US$10,000 configured with hardware, software, database, and development tools for a small company (similar to the total installed cost of a similar Microsoft server or Linux system. Yes, Linux: software=$0, hardware=$4,000, labour=$6,000 unless you work for free) current largest iSeries (i5 595) supports: o 375,000 Mail and Calendar Users o has 4 times the performance of the previous largest system i890 o has 330 times the performance of the smallest i5/iSeries th o up to 64 CPUs which are 9 generation 64-bit RISC 1.5 - 1.9 GHz CPU frequency, 1.9 - 36MB L2/L3 cache o 2 TB of main memory o 190 TB of disk o disk controllers with 1GB read & 757MB write caches o Up to 60 I/O expansion towers/drawers via High Speed Links (2GBps) o Up to 840 PCI-X slots, up to 160 LANs o Up to 60 Integrated xSeries Servers o Up to 57 Integrated xSeries Adapters o Redundant, hot-plug components for additional reliability previous largest iSeries (i890) supported: o 150,000 Domino users with a response time of 272 milliseconds o 40,200 iNotes Web Access users with 58 millisecond response time o 283,000 active connections on the VolanoMark chat-room benchmark o top three spots in benchmark testing for numbers of Web connections and response time of a Web server (Standard Performance Evaluation Corporation's SPECweb99 benchmark for Web serving) th o 32 8 generation 64-bit RISC CPUs controlling over 600 other processor chips for I/O o 256 GB memory o 144 TB disk (with no disk drive letters to keep track of) o 128 LAN ports o 480 comm lines

o o o o

over 10,000 terminals (7,200 5250 and 3,150 ASCII) 48 Integrated xSeries (Wintel) Servers 52 CD-ROM, DVD-RAM, and tape drives cost is around US$1.7M

iSeries Navigation and Commands

Lab 1

iSeries User IDs are yours for the term User Profile is an iSeries object that identifies you and things about you that help start up an Interactive Job. GO to the SENECA menu for information on fixing your user profile if you cannot sign on. Four parts of a menu screen: 1. screen header (menu ID/name, description/title, system name) 2. menu options 3. selection and/or command line input (===>) 4. function keys Four types of interactive terminal screens: 1. menu (e.g. GO MAIN) - system knows what to do with a menu item selection 2. entry (e.g. iSeries sign on screen) - system is waiting for you to enter data - common subtype is a command prompt screen (e.g. WRKOBJPDM + F4) 3. information (e.g. F1) - displays help window on top of any screen 4. list (e.g. DSPLIBL) - shows list of variable information some screen types have attributes of other types o menu screens allow entry o list screens allow entry and options against list items see "definitions" on web page

Command STRPDM

Some commands so far Description start P.D.M.


create source physical file change password display user profile display message work output queue work spool file (in all output queues) retrieve job attributes retrieve user profile send message to a message queue send message to program's message queue

Some commands so far Com mand STR PDM CRT SRCPF CHG PWD DSP USRPRF SND MSG DSP MSG WRK OUTQ WRK SPLF RTV JOBA RTV USRPRF SND PGMMSG Description start P.D.M. create source physical file change password display user profile send message to a message queue display message work output queue work spool file (in all output queues) retrieve job attributes retrieve user profile send message to program's message queue

CL Commands

i5/OS and OS/400 Control Language primary interface to operating system functions The bad news: 1,500+ commands and thousands of parameters The good news: it is a language! Knowing a little, you can do a lot. More good news: 1,500+ commands and thousands of parameters so you don't have to create a UNIX-like script almost every time you want to do something

Command Names

command-name is composed of Verb and Subject Verb or function is first 3 characters

CL Verb English CPY CRT DSP STR WRK Copy Create Display Start Description Copies a file Creates an object Displays something about an object Start a utility or system function

Work With Works with an object

Notable Verb exceptions o CALL -- executes a program o GO -- displays a menu

Subject follows the verb with a noun or qualified noun

CL Noun English LIB LIBL OUTQ JOBQ F FD Library Library List Description Object that holds Objects List of Libraries for a Job

Output Queue Object that stores Spool Files Job Queue File File Desc Object that stores Batch Jobs to be processed Object that stores data Description of file Object that lists attributes about a User ID

USRPRF User Profile

Notable one letter nouns:

Noun meaning example



CL Syntax using Keyword Notation

structure is command-name and parameter(s) a parameter is a Keyword with its value or values syntax is COMMAND KEYWORD1(value) KEYWORD2(value value) DO NOT leave a space between the KEYWORD and its "(" left parentheses the delimiter is a space...leave at least one space between the command and each parameter, i.e. the keyword with its value between parentheses the "+" is the continue-on-the-next-line character keywords can appear in any sequence e.g. CRTLIB LIB(PAYROLL) TYPE(*TEST) TEXT('Payroll Dept.') o CRTLIB TEXT('Payroll Dept.') TYPE(*TEST) + LIB(PAYROLL) keywords have default positions following the command o called positional notation: parameter values without the keywords o e.g. CRTLIB PAYROLL *TEST o does not work for all parameters if the positional list may be ambiguous o parameters are prompted for in their relative positions on the command prompt screens or can be seen using F9 from the command line for completed commands or can be

Navigating a sea of commands

Menus on iSeries o GO MAIN -- main iSeries menu (F16) o GO MAJOR -- major commands menu (F4) o GO VERB -- action menu o GO SUBJECT -- objects menu

o GO CMDxxxx (verb, noun, function) guess at the command by combining a verb and noun partial guessing using wild card character: ==> CPYS* [displays a list of all commands beginning with CPYS...] ==> GO CMDC* [displays a list of all menus beginning with CMDC...] Prompt a command before running it: * instead of pressing Enter, press F4 to prompt the command * or instead of F4, key a question mark "?" in front of the command and press Enter just press F4 (or key "?") anywhere you would like a prompt: on the command line or in a command entry screen prompt field

Library Lists

like a UNIX/DOS $Path it is the list of libraries a job searches when looking for commands, programs, files, or other iSeries objects. each job (batch or interactive) has its own LIBL (library list) LIBL created from system values, user's profile, default job description may be modified by commands and CL programs libraries within a type are accessed in simple list order as determined by the System Values: QSYSLIBL (System portion of LIBL) and the programmer (USR type).

Parts of Library List in access order by type 1. System (SYS) o IBM supplied o e.g. QSYS (OS/400 system library) o defined in system values (DSPSYSVAL QSYSLIBL) by the iSeries administrator 2. Product (PRD) o automatically added to the library list when an IBM product is used o e.g. QRPG when compiling an RPG program e.g. QPDA when running Programming Development Manager 3. Current (CUR) o defined in your user profile: see Current Library (CURLIB) o searched before other user libraries

o o

only one LIB is current do not rename or delete your Dx233snn current library

4. User (USR) o non-IBM libraries o defined in system values (DSPSYSVAL QUSRLIBL) by the iSeries administrator o used to organize program libraries, files libraries o e.g deptFILE -- files unique to a department's job deptPGM -- programs unique to a department's job divFILE -- files common to a division's jobs divPGM -- programs common to a division's jobs COMPANY -- utility programs and files used system wide
Library List organization Dept. Files: Dept. Programs: Division Files: Division Programs: Company Wide: Accounts Payable APFILE APPGM General Ledger GLFILE GLPGM Sales & Marketing SMFILE SMPGM DISTRIBFIL DISTRIBPGM



all libraries have unique names all objects reside inside libraries all objects have unique names/types within a library only the QSYS *LIB can contain other *LIB objects File objects contain zero or more members where the members have unique names within the file
object_name *type e.g. PROGRAM1 *PGM QxxxSRC *FILE DA233snn *OUTQ members spooled files

OS/400 library *LIB QSYS *LIB

UNIX root


.exe or file or sub-directory

source/text files

iSeries Objects
Todays Agenda

Review - the difference between libraries (LIB) and library lists (LIBL) Use of wildcards * and '?' on the iSeries iSeries Architecture Object Types Storing Objects Manipulating Library Lists Spooled Files Work with Jobs Commands

Libraries and Library lists Remember libraries are like Windows/UNIX directories... -- they exist whether you have authority to them or not, -- whether they are in your library list (path) or not. try DSPLIB *ALLUSR to see all the non-IBM libraries you have authority to. Use the *ALL parameter to see every library you have authority to. Your library list is a search list which is a selection of all possible libraries you have access to. e.g. our course library, IBC233LIB, is not in your library list when you sign on but you can add it to your list. Note the difference between running the DSPLIB *ALLUSR (or *ALL) and the DSPLIBL commands. Note the similarity when running the DSPLIB *LIBL and DSPLIBL commands. Wildcards * and '?' * (Asterisk or Star) When'*' is used before a parameter value, it indicates a "special value" or an OS/400 "predefined value" (do not confuse with system values). eg. DSPLIB *ALL displays all libraries in the system, but DSPLIB ALL tries to display a library named "ALL"

When'*' is used after a parameter value, it indicates a generic value; eg. WRKOBJ Dx233snn* (note that WRKOBJ is similar in function to the UNIX ls command.) The WRKxxxPDM commands allow '*' at either end of the generic value; WRKMBRPDM FILE(IBC233LIB/REVIEWS) MBR('*1*') Use the ? for prompting instead of F4 * key a question mark "?" in front of the command and press Enter Enter ?WRKOBJ to prompt the command (same as WRKOBJ + F4). Enter ? in a field on a command entry screen to see all possible values for a parameter. Same as using F4 while cursor is positioned in a field. Good for lising the possible special values. iSeries Architecture

all objects (and almost everything is an object) are encapsulated. They are protected by their object specific interface -- an application relates to an object through the interface and never deals with hardware-specific details. You can't corrupt an object! o Layered Machine Architecture
Application software Logical machine OS/400

Machine Interface (MI) Physical machine

physical hardware

Why is this architecture good? o programs are not dependent on the hardware o consistent approach to object management and security o reference an object by its simple name o protects the knowledge investment of programmers and users o no binary compatability problems, no slow emulation, no recompilation, no rewrites

backward compatability with older versions of OS/400 Software Applications do not have to be changed or recompiled when the operating system changes or when the hardware changes. o The move to pure 64 bit computing takes a weekend conversion. o Programs over 20 years old are running in native 64 bit mode and have never been recompiled. Single level storage o main and secondary memory (RAM & disk) are treated as a single address space o no hardware oriented storage considerations (e.g. managing disk drives or mounting volumes) o memory management is a function of internal code, not applications. o allows same object to be shared by different jobs. e.g. a single program object is loaded in memory with each user having their own variable space
o o

What is an Object?

Takes up space on the system Resides in a Library Has a Name (1-10 characters) Has an Object Type

Object Type is assigned to the Object at time of creation by the command you run e.g. CRTLIB creates objects with a type of *LIB The object type defines how an object is used on the system. Library is a like a directory in which programmers group related objects. When system checks the type and authorization for an object, the library knows -system does not have to locate and load the target object to check things out. This results in fast performance even with sophisticated security. How does the iSeries find Objects? Simple object name: e.g. CALL ASSIGN1

command knows what type of object to search for system searches library list for the object name/type in this case, a program object *PGM because the CALL command runs programs authorization: must be able to use a library if it is in your library list and you must be able to use the object itself

Qualified Names: i.e. Library/Object


must be authorized to use the library and the object itself in order to use the object used to address objects with the same name and type existing in more than one library in your library list. i.e. needed to get the object in the library which is further down the list used to check the existence of an object whether you have authority to it or not

Commands used to find common types of objects across your library list:

WRKPGM - Work with Programs WRKF - Work with Files WRKOUTQ - Work with Output Queues WRKOBJ - the generic Work with Objects

How and where does the iSeries store new objects? There is a specific CRTxxx (Create) command for each object type CRTxxx librname/objname ==> objname created in librname CRTxxx objname ==> objname created in *CURLIB However, if there is no current library (CHGCURLIB *CRTDFT), then the objname is created in QGPL Note: Libraries (*LIB), User Profiles (*USRPRF) and Device Descriptions (*DEVD) object types are stored in QSYS. These CRTxxx commands do not ask which library to store the new object in. All other Object Types can be stored in any library. Library List Commands

Display Library Lists (DSPLIBL) check your list Change Current Library (CHGCURLIB) Add to the Library List (ADDLIBLE) change the list one library at a time Change the Library List (CHGLIBL) change the list (and/or current library) all at once Edit Library List (EDTLIBL) interactive LIBL maintenance -- easily resequence the user section of your library list

GO CMDLIBL the menu with all the commands you can do to a LIBL

What is a Spooled File?

Spooled files are printed output -- files that contain data for printing (an instance of the printer file which was used to create it) Are stored in Output Queues To print a Spooled file, the file must be moved to an Output Queue which is attached to a printer via a printer writer. more about this topic next week

Get a Job Work with Jobs Command

To display information about your current Interactive job, simply type: WRKJOB To display information about any other job, use the Work With Job and enter the Job Name and User. Number is Optional. To display your Batch Jobs, use the Work with Submitted Jobs Commands (WRKSBMJOB)

iSeries Printing & Spooling and Files

Chapter 4 & 5 Todays Agenda

class list - make sure you are on it! Printing & Spooling Database files

Printing & Spool Files Printer Spooling

application and system programs use a printer device file which defines the report layout (e.g. size of the paper). A printer device file is an object type

*FILE, sub-type or attribute PRTF. e.g. QGPL/QPRINT*FILE, QSYS/QSYSPRT*FILE display all the commands for Printer Files and use the Change command to view one of those files (don't worry, we cannot actually change those files). Spooled files are printed (or report) output -- system files that contain output data formated for printing (i.e. an instance of the printer device file which was used to create it) spooled files are stored in Output Queues (an object type *OUTQ in a library)
output Output Queue report formatted Printer File spooled file(s) data data (e.g. QPRINT) ========> ========>


a printer writer is a system utility which connects an OUTQ to a printer device description to actually put a spooled file onto paper. a printer device description is a printer sub-type of object type *DEVD in QSYS library which describes the physical hardware printer. To print a Spooled file, the file must be moved to an Output Queue which is attached to a printer via a printer writer. Usually the name of the OUTQ and the printer DEVD are the same, e.g. PRT01. each spooled file is assigned a unique file number within the job. An AS/400 job is identified by Job Name, User Name, Job Number. The JOB identification and spooled file number uniquely identifies any spooled file on the system. This is why you can transfer spooled files between OUTQs without worrying about name conflicts. You can identify a spooled file without knowing which OUTQ it is in. WRKOUTQ lists all users' spooled files within a single OUTQ WRKSPLF lists spooled files across OUTQs according to selection criteria by User

The example given on page 108 of the text regarding the use of OUTQs is not very good. The AS/400 is much smarter than described. OUTQs are typically used to keep printed output away from printers. E.G. To let you review your output before sending it to a printer. A company might use certain OUTQs to segregate very large reports which are to be printed overnight.

Database Files
Each file type has its own set of unique characteristics that determines 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, for some file types, the data itself. A database file on the AS/400 is like a table file in another DBMS. Tables contain columns and rows. On the AS/400 files contain fields and records. Fields/columns define the kind of data (e.g. field name, data type, field length for things like Name, Address, Phone Number). Rows contain an instance of each data record (e.g. one record per name).
Generic RDBMS Schema Table Rows DB2/400 Library *FILE PF-DTA Records

Columns Fields

A DB table/file is similar to a spreadsheet file where all the columns are the same and all the rows are different. What is different about database files and why they are so fast is that all the records and fields in a table/file contain exactly the same number of bytes. This means that the DBMS can address each record and field within the database using mathematical formulae (e.g. the beginning of record number 1,234 with a record length of 80 bytes is byte number (1234 - 1) X 80 +1=98,641. Stream files with variable length records and fields require a byte by byte search from the beginning of the file to find anything.

*FILE Varieties

PRTF: Printer files format output from programs to create spooled print files in OUTQs DSPF: Display files format data for display screens. Programs read from and write data to display files. PF: Physical files have two sub-types. o "database" subtype (PF-DTA attribute) holds and organizes user data. - created by the CRTPF command.

"source" subtype (PF-SRC attribute) organizes source code for programmers. - created by the CRTSRCPF command. LF: Logical files o created over physical database files to define access paths o can filter and/or provide special "views" of the data in PF-DTA o often used simply to sort data (but functionally much more than that)

Program Described Files

like "flat" files contains a single field name equal to the record length have no detailed field information programmer subdivides the record inside the program this is tedious and prone to error used to convert old files to AS/400 DB files used to send AS/400 data to another system which is not as smart as the AS/400

Externally Described Files

like database tables definition is external to programs which use them contain detailed field-level descriptions of their records within the object itself standardize record formats for consistent use effective use of AS/400 utilities less tedious programming...programmer names the file, the integrated HLL compiler uses record format/field definitions from the file object itself -- very fast, no source code required, no APIs, no SQL, automatic variable definition/declaration of the file's fields within the program. DSPFFD RPG544TM/WUSTDP RUNQRY *N RPG544TM/WUSTDP RCDSLT(*YES)

Methods of Describing Database Files

o o

Structured Query Language Resource intensive on the AS/400 (but getting much better)


o o o

Interactive Data Definition Utility inherited from the S36 preserved on the AS/400 for IBM customers' investment protection

DDS Data Definition Specifications o is a small language used to code source descriptions for the file varieties noted above Utilities o SEU - Source Entry Utility for PF, LF, programs o SDA - Screen Design Aid for DSPF o RLU - Report Layout Utility for PRTF o PDM - Programming Development Manager for almost everything

iSeries Files
Chapter 5 -- Describing a Database File

Database Files *FILE Varieties

PF: Physical files have two sub-types. o "database" subtype (PF-DTA attribute) holds and organizes user data. - created by the CRTPF command. o "source" subtype (PF-SRC attribute) organizes source code for programmers. - created by the CRTSRCPF command. LF: Logical files o LF attribute, defines access paths to physical database file(s) o can filter and/or provide special "views" of the data in PF-DTA o often used simply to sort data (but functionally much more than that) DSPF: Display files o DSPF attribute, defines screen o user interface o program interface

Methods of Describing Database Files


Data Definition Specifications a form is used to code the descriptions for physical and logical files Utilities o SEU - Source Entry Utility for DDS (PF, LF), programs (CLP, RPG, COBOL, C, C++) o SDA - Screen Design Aid for DSPF (SDA generates the DDS for DSPF) o PDM - Programming Development Manager for almost everything Source code is contained in source physical files (type: PF-SRC) naming convention is QxxxSRC where xxx is the kind of members in the source file
o o

o o o o

QDDSSRC -- Data Description Specifications source code for physical, logical, display, and printer files QRPGSRC -- RPG program source code QCBLSRC -- COBOL program source code QCLPSRC - Control Language Program source code also known as QCLSRC

Three Steps of Physical File Building 1. describe the data record and fields using SEU for source type PF 2. create the file (compile the DDS source) [Chapter 6] 3. load the file by keying data using DFU [Chapter 6] Demonstration of SEU while creating a DDS. 1. create a source physical file to hold our DDS source: CRTSRCPF QDDSSRC (one time only) 2. Start the programming editor, SEU (Source Entry Utility) STRSEU or use PDM's F6 to create or option 2 to change 3. assign a source type -- very important it helps SEU prompt us and check our language syntax it tells PDM which CRTxxx command to use when compiling the source Compile errors * See the FAQ link on the course home page - The PDM user option, SP (WRKSPLF), shows your spooled compile listing and, if there are errors, a job log - Return to Editing your source member... * Use Browse/Copy option (F15), then option 2 for spool files -- take the defaults and

the system will show your last compile listing in a split window * on the lower window's SEU command line, enter F *ERR (Find Errors) * place the cursor on the bottom line where the error message is and press F1 for help, * use F12 to return to the browse window and press F16 to repeat the Find Errors command - Warning messages: pay attention, ensure there is no problem

iSeries DB Files
Chapter 6 -- Externally described database files Chapters 5 & 6

READ THEM. They offer a step by step explanation of describing, compiling and loading data files. Review the chapters while on the iSeries. Get a hands-on feel for things.

Database Files *FILE Varieties

PF: Physical files have two sub-types. o "database" subtype (PF-DTA attribute) holds and organizes user data. - created by the CRTPF command. o "source" subtype (PF-SRC attribute) organizes source code for programmers. - created by the CRTSRCPF command. LF: Logical files
o o o o

defines access paths to physical database file(s) can filter and/or provide special "views" of the data in PF-DTA often used simply to sort data (but functionally much more than that) created by the CRTLF command

Methods of Describing Database Files

o o

Data Definition Specifications is a small language used to code the descriptions for physical files (also logical, display and printer files)

Utilities o SEU - Source Entry Utility for DDS (PF, LF), programs (RPG, COBOL, C) o SDA - Screen Design Aid for DSPF o PDM - Programming Development Manager for almost everything Source Code

Source code is the specifications for programmable objects, e.g. database files, CL, COBOL programs Source code is contained in source physical files (type: PF-SRC) naming convention is QxxxSRC where xxx is the kind of members in the source file Standards:
o o o o

QDDSSRC -- Data Description Specifications source code for physical, logical, display, and printer files QRPGSRC -- RPG program source code QCBLSRC -- COBOL program source code QCLPSRC - Control Language Program source code - also known as QCLSRC

Three Steps of Physical File Building 1. describe the data record and fields using DDS and SEU 2. create the file (compile the DDS source) [Chapter 6] 3. load the file by keying data using DFU [Chapter 6] Cooking up a File

DDS is the recipe for the file, not the file itself QDDSSRC is like a cookbook containing many recipes, i.e. many DDS source files CRTPF or CRTLF "cooks" the recipe, i.e. it compiles the DDS source into a *FILE object before you can CRTPF again, you must clean out the pot first, i.e. delete the old *FILE object before it can be recreated. Use SEU to specify a DDS

1. create a source physical file to hold the DDS source: CRTSRCPF QDDSSRC (one time only) 2. Start the programming editor, SEU (Source Entry Utility) STRSEU or use PDM's F6 to create or option 2 to change an existing source member 3. assign a source type (PF or LF) -- very important * it helps SEU prompt us and check our language syntax * it tells PDM which CRTxxx command to use when compiling the source 4. specify the DDS statements PDM

use PDM's built in features to create the file object (CRTPF) using option 14. use option 18 for instant DFU access to the data member to load data. Changing a PF definition with CHGPF

Note that removing or changing field names, attributes, or sizes can have a major impact on LFs and existing programs or utilities which use a file. if you change a file's DDS source code and compile it, you create the *FILE object again. The system will ask you if you want to delete the old *FILE object before it creates the new one. Be careful. ==> if the source type is PF, you will lose the data records the physical file previously contained! Since the member contains the data, and the object contains the member and the object is being deleted, you should be careful here. (If the source type is LF, you are just recreating the access path to the data in the based on PF. No worries here.) ==> if the physical file (PF) has dependent logical files (LF), the LFs must be deleted before the PF can be deleted and rebuilt. After all, LFs are access paths to PF data -- if there is no PF, then there is nothing the LF could point to. The system will not allow orphan LFs. the system provides a command to change a PF without losing data or worrying about dependent logicals: CHGPF -- CHanGe Physical File CHGPF will change the PF you specify based on your revised DDS specs only if you provide the name of your DDS source file (QDDSSRC) to the command. Try it out and you will see how the command defaults will find the file's member name. the change will be successful in most cases where field names have not been changed. Check the messages the system puts in the job log. If the system cannot complete the CHGPF command (because it would have to guess or compromise data integrity), please read on.

Tthe steps to change a *FILE definition without using CHGPF are: 1. Rename or copy your PF-DTA *FILE to another name in order to preserve the data if you rename a PF, any LFs based on the old file name are now pointing to the new file name...what else would those LFs point to? That's OK but you may want to delete the LFs first. if you copy a PF, the old PF (and any LFs based on it) is unchanged. The new PF has no LFs pointing to it. CRTDUPOBJ (WRKOBJPDM option 3) makes a clone of an object and requires certain authorities ... no problem if you created it. 2. change the DDS source 3. delete any LFs which are based the PF 4. recompile (CRTPF) the DDS 5. use CPYF to copy the data from the renamed/copied file (in step 1.) to the newly recreated file. If the record format did not change, e.g. you just changed some column headings or an editing keyword but did not change the field names, lengths or data types, then a simple CPYF will move your data from the old file to the new. (So would using the CHGPF command -- see above) Copying records whose from-file and to-file record formats are different needs the Format Options, FMTOPT, parameter... If, and only if, you just changed one or more field names, you can use the FMTOPT(*NOCHK) option to copy data left to right, buffer position by buffer position between files disregarding any differences in the DDS specifications. Be careful with this. When using the *NOCHK option, change only the field names. Do not change any field lengths or data types. Do not add or delete any fields. Buffer locations (column positions) in the two files must match. Data types must be compatible -- they will not be converted. When record formats are different for reasons other than simple field name changes, you can use ForMaT OPTions to: *MAP fields whose names are the same in the two files and whose field attributes are compatible. Data conversions will be done where possible. *DROP fields in the from-file record format that do not exist in the to-file record format. Dropped fields are not copied. Data in these fields is lost.

The dropping and mapping of fields is based on a comparison of field names. Unless all the fields in the from-file have the same name in the to-file, you must specify *DROP. If the names are the same, but the attributes or position within the record is different, you must specify *MAP. There must be at least one like-named field in both record formats to do mapping. See the AS/400 "Data Management" manual for more information, especially chapter/section: Copying between Different Database Record Formats (FMTOPT Parameter). 6. Now that your new PF-DTA *FILE has been created and repopulated with data: delete the old, original PF-DTA file if it is no longer needed change the DDS (as required) of LFs to be based on the new PF and recompile them (CRTLF) 7. you probably need to recompile programs and queries that use the recreated PF and LFs so those objects will know about the new version of those files.

Introduction to Query/400

READ THE CHAPTER. It offers a step by step explanation of building a Query/400. Review the chapter while on the AS/400. Get a hands-on feel for things. Create your own query as per the text. Use the IBC233LIB/EMPPF and ZIPPF files for the textbook's query to see how Query/400 builds join logical files on demand. see our own Lab notes from the course home page to do the query with our data files


report generator or query utility object type is *QRYDFN obtains information from an externally described database file on the iSeries. (Even from flat files if you work at it using substring function.) generate screen or paper reports or new DB files from 1-32 different files.

Query/400 puts a nice face on SQL. Pay attention. SQL will make a lot of sense after this. the most useful thing on the iSeries for ad hoc management reporting and analysis. Produces Q&D reports (Quick and Dirty). the most useful thing on the iSeries for systems development testing and checking. i.e. how do you know your program is producing the right answer? Use Query/400. Query/400 satisfies the 80/20 rule: It does 80% of the job using only 20% of other more sophisticated query package features (e.g. MRC-query, Sequel, Cognos Impromptu). Query/400 features:

select and sort records * select and sort records based on fields or calculated field contents * e.g. Select Course EQ 'IBC233' and Section LIST ('E' 'F' 'G') * Sort by UserID report/screen layout control * choose fields in the sequence you want, create/calculate new fields from record fields, control editing, spacing, headings, etc. report breaks to group records (programmers call them "control breaks"). * up to six levels to count, total, find minimum / maximum / average. * e.g. CS Dept. report by Professor / Course / Section listing student records and showing at each level a count of students and their average mark. online, interactive development and previewing of processed data. Run with PDM: * use option 16 on *QRYDFN object to run a query * use option 12 to work with this and other queries in the library Start Query command (STRQRY) or GO QUERY WRKQRY is very useful for query development.

Date processing in Query

See the IBM Query manual on Date, Time, and Timestamp Arithmetic Operations Incrementing and Decrementing Dates Durations

Query demo: iSeries commands can create a wealth of system information for high level use. Many iSeries commands output to a database file (look for the *OUTFILE option) -- from there, you can write your own reports

Try keeping track of all your objects: To start, capture information about objects in your default library ===> DSPOBJD OBJ(DB233snn/*ALL) OBJTYPE(*ALL) OUTPUT(*OUTFILE) OUTFILE(DSPOBJD) then, run the following to add info on objects in other libraries you may have ===> DSPOBJD OBJ(DB233snnA1/*ALL) OBJTYPE(*ALL) OUTPUT(*OUTFILE) OUTFILE(DSPOBJD) OUTMBR(*FIRST *ADD) Now, develop a query on the DSPOBJD to help you keep track of all your stuff. If you do not like the presentation of the DSPFFD command's output, why not send its output to a file and create your own query to show it the way you want.

Logical Files
Chapter 8 -- Using Logical Files Physical Files review

physical files define the format of the data (as per DDS) PF member(s) contain a data set of data for the file's format PF has only one record format PF are the basis for Logical Files Access Paths

arrival sequence * the order in which records are added to a file * Sequential access is first to last record in the file (the way a default Query displays records) * Direct access is random retrieval by relative record number e.g. *RECNBR in a DFU program. Retrieve the first record, the tenth record, the fifth record. This is not very useful for data files. How do we know what is in the nth record? Keyed-Sequence * field(s) in the record format are designated as key fields in the DDS * Sequential access is in key field order * Direct access is look up by key value e.g. employee master file by SIN, Student file by name Key Fields

specified in DDS after the field level specs code a "K" in the Name Type Field and the field name Composite Keys are coded in sequence from High to Low Order e.g. LNAME then FNAME to sequence by surname, then given name records with a unique identifier: o primary key field(s) contain data that will not be duplicated e.g. SIN number or Student number or Bank Account number o most data base designs have primary keys in the PFs o DB2/400 enforces this rule o UNIQUE keyword at file level duplicate keys are also allowed * optionally specify FIFO or LIFO to control sequence of duplicates e.g. Student File with access path by Name is usually FIFO e.g. Sales records by Customer Code are often LIFO Logical Files

access paths to physical file data system builds indexed pointers to the data records in the PF like views and/or indexes in SQL simple logical files: alternate key over a PF can have many logical files based on the same physical file programs and utilities access the data through the logical access path allow joining and merging of multiple files - the relational aspect of DB selection of records (rows) for ease of use and security projection of fields to limit availability of data (columns) there is no sorting in a RDBMS, only access paths. DDS source member type is LF compile with CRTLF command Select / Omit

use the DB to filter data needed for an application Why read 100,000 records to find 50? For good performance, use the DB, not a program. protect data from users who are authorized to only some records in a file (OS/400 security can restrict them from the PF, allow access only to the LF) key field(s) are optional but are usually present Select/Omit by: * VALUES( list of values to match ) * RANGE( low high ) * COMP(op comparison-value ) op is EQ/NE/LT/GT/LE/GE

Select: code an "S" in the Name Type Field Omit: code an "O" in the Name Type Field multiple Select/Omit lines: * blank Name Type means AND condition * S/O in Name Type means OR condition e.g. Select Dept = 'Research' AND Salary >= $45,000:
S DEPT SALARY COMP(EQ 'Research') COMP(GE 45000) COMP(EQ 'Research') COMP(GE 45000)

e.g. Select Dept = 'Research' OR Salary >= $45,000:


Omit statements are typically used before Select statements to remove a group of records from further consideration.

Some examples may help to understand Selection. Imagine a company's employee file. There is one record per employee and, among other information, there are fields for the Salary the employee makes and the Department the employee belongs to. See the following charts that illustrate employee records that would be selected according to the DDS Select/Omit statements. It is usually best to use Select statements only ...
Select if Salary >= $45,000 AND Dept = 'Marketing'
[and exclude everything else] S SALARY DEPT COMP(GE 45000) COMP(EQ 'Marketing')

Salary \ Dept. 0 - 24,999 25,000 - 34,999 35,000 - 44,999 45,000 - 54,999 55,000 - 64,999 65,000 +

Marketing 2. excluded

Human Res



2. excluded 1. Select

Either / Or criteria look like this ...

Select if Dept = 'Marketing' OR if Salary >= $45,000
[and exclude everything else] S DEPT COMP(EQ 'Marketing')


COMP(GE 45000)

Salary \ 0 - 24,999



Human Res



25,000 - 34,999 35,000 - 44,999 45,000 - 54,999 55,000 - 64,999 65,000 + 1. Select

3. excluded

2. Select

Combining Select and Omit statements can be confusing ...

Select if Dept = 'Marketing' OR Omit if Salary < $45,000
[and include everything else] S DEPT COMP(EQ 'Marketing') O SALARY COMP(LT 45000)

Salary \ Dept. 0 - 24,999 25,000 - 34,999 35,000 - 44,999 45,000 - 54,999 55,000 - 64,999 65,000 +


Human Res 2. Omit



1. Select 3. Included by default (i.e. not Omitted)

Reverse the sequence of Select/Omit and you get a different selection of records.
Omit if Salary < $45,000 OR Select if Dept = 'Marketing'
[and exclude everything else] O SALARY COMP(LT 45000) S DEPT COMP(EQ 'Marketing')

Salary \ Dept. 0 - 24,999 25,000 - 34,999 35,000 - 44,999 45,000 - 54,999 55,000 - 64,999


Human Res 1. Omit



2. Select

3. Excluded by default (i.e. not Selected)

65,000 +

Another example from the textbook...two Select statements (Select record if either first or second statement is true...
Select if Dept =( 'Human Res' OR 'Sales') OR Select if ($35,000 >= Salary <= $54,999)
S DEPT S SALARY [and exclude everything else] VALUES(EQ 'Human Res' 'Sales') RANGE(35000 54999)

Salary \ Dept. 0 - 24,999 25,000 - 34,999 35,000 - 44,999 45,000 - 54,999 55,000 - 64,999 65,000 +

Marketing 3. excluded 2. Select 3. excluded

Human Res


IT 3. excluded

1. Select

2. Select 3. excluded

Change the criteria to a single Select statement...

Select if Dept =( 'Human Res' OR 'Sales') AND ($35,000 >= Salary <= $54,999)
S DEPT SALARY [and exclude everything else] VALUES(EQ 'Human Res' 'Sales') RANGE(35000 54999)

Salary \ Dept. 0 - 24,999 25,000 - 34,999 35,000 - 44,999 45,000 - 54,999 55,000 - 64,999 65,000 +


Human Res 2. excluded



2. excluded

1. Select 2. excluded

2. excluded

LF Projection

limits access to fields - restricted fields are excluded from the LF definition must name only the fields to be included in the DDS Security

combine projection with selection to restrict sensitive information in PFs adjust OS/400 security to exclude users from the PFs and allow access to selected LFs security at the Field level is supported (no need for LF projection) but is administered only through SQL statements or AS/400 Operations Navigator (GUI) Join LF

joins records of two or more PF together based on related fields for display only, cannot be used for updating data Inner join - matching fields in all file records Left Outer join - primary file records plus secondary file data where matches are found (default blanks/zeros if not found). Multiple-format LF

for display and update of data in two or more PF merges records, each record remains in its own record format must be keyed all record format specify at least one, same high-order key e.g. Orders file o Header record. Key: Order Number o Line Item records. Key: Order Number, Type, Line Number o Comment records. Key: Order Number, Type, Line Number Access Path Maintenance

*IMMED -- Immediately - required for online master/transaction files - required for UNIQUE key files *DLY -- Delayed A temporary space is maintained with all of the changes made to the physical file, but pending in the logical file Changes are applied to the Logical only when it is used. - opening file takes a little longer as access path is updated. - OK for small files - OK for large files that are used infrequently by patient users *REBLD -- Rebuild Access path is rebuilt every time its used. - OK for batch programs run during off hours - e.g. transaction file report run during day end processing

option is determined by a parameter in the Create Logical File (CRTLF) command and can be changed by the Change Logical File (CHGLF) command. factors are: high data volatility and number of access paths o volatility: the rate records are added/deleted or data in key fields is changed o a single record transaction can cause many access paths to be maintained trade offs: system overhead and response time Database commands

DSPFD - Display File Description: shows the Access path and which PF(s) a LF accesses DSPFFD - Display File Field Description: displays a file's Field Level Information DSPPFM - Display Physical File Member: displays a member's data in arrival sequence by column (buffer position) CLRPFM - Clear Physical File Member: deletes all records in a member RUNQRY *N filename : runs an instant query on the file in key sequence by field DSPDBR - Display Data Base Relations: provides relational information about database files; e.g. all LFs based on a PF

introduction to security
Object Level Security

iSeries uses object level authority for high security. Authority applies to everything within the object. Objects exist in a library. A library is an object. Therefore, you need authority to both the object and the library it resides in. every object has an owner who has, by default, all authority to it then, there is everyone else: *PUBLIC security defines what anyone besides the owner can do to an object in the case of a file, we are especially concerned with Data Authorities: Read data records, and/or Add, Update, Delete records. Users can be given any or all of these authorities to a data file. Object Authorities govern what you can do with or to the object: o Operational - look at the object's attributes; use the object as per Data Authorities

Management - needed for CRTDUPOBJ (PDM object option 3), to specify security, to move or rename the object, and to add members if the object is a database file. o Existence - needed to control the object's existence and ownership (e.g. Delete) o Alter - Add, Clear, Reorganize DB file members; run the CHGPF command o Reference - needed to specify the object as the first level in a referential constraint Field level authorities are now supported for database files and are administered through SQL statements or iSeries Operations Navigator (GUI)

Hierarchy of Authorization Checking

Using the job's User ID, the system checks for sufficient authorization to use an object. It checks security in this order: 1. object's owner or a user with all object (*ALLOBJ) special authority (i.e. a "super-user") 2. explicit authority by User (Private Authority) o list of User IDs with their private authorities to the object o authority specified object by object, user by user o difficult to manage: most iSeries have many users who access many objects (this becomes an N2 problem) o least efficient, most flexible 3. Authorization List (AUTL) o identifies a list of User IDs and their individual authority levels o one authorization list can be specified per object o useful when a collection of people need differing authorities to a number of objects o each object just refers to the Authorization List name, e.g. IBCPRF o changing the AUTL object changes the users and authorities for every object that references the list o medium efficiency, very good flexibility 4. explicit authority by Group Profile o list of one or more Group IDs with their private authorities to the object o if the user is a member of a specified group profile, the user has the authority the group profile has been granted o Group ID is a user profile created only for the purpose of assigning regular user profiles to it

not as flexible as an Authorization List since all members of a group profile get the same authority o a user can belong to up to 16 group profiles o if a user belongs to multiple groups and multiple groups have authority to the object, the user gets the sum of those groups' authorities o high efficiency if a Group ID is nominated the primary group for the object 5. *PUBLIC authority o applies to everyone else o most efficient but least flexible

Security commands

===> GO SECURITY for the Security menu ===> GO CMDAUT for the Authority Commands menu EDTOBJAUT Edit Object Authority o EA user option within Work with Libraries/Objects using PDM GRTOBJAUT Grants Object Authority to many objects at a time RVKOBJAUT Revokes Authority to many objects at a time DSPOBJAUT Displays Authority to an object CHGOBJPGP Change Object Primary Group CALL IBC233LIB/DSPOBJAUT program to display authority of all objects in your current library.