Table of Contents:
Chapter I :AS/400 Highlights
...
7
Introduction : ... 7
Technology-Independent Machine Interface ... 7
Operating System OS/400 ... 8
Single-Level Storage ... 8
Logical Partitioning (LPAR) ... 9
Objects ... 9
AS/400 Processing Environment ... 12
What is a job? ... 12 Job Description: ... 12 Subsystem ... 12 Job Queues ... 12 Output Queues ... 12 Type of Jobs ... 12 AS/400 Security ... 14
Security at object level: ... 14
Security Functions ... 15
Security Levels ... 16
Application Development Tools (ADT) ... 17
Program Development Manager (PDM) ... 17
Source Entry Utility (SEU) ... 20
Data File Utility (DFU) ... 20
Chapter II –Libraries
...
22
Library Categories ... 22
Library List: ... 23
Library commands: ... 23
Library List Commands: ... 23
Chapter III: AS/400 Database
...
24
File Types: ... 24
Database Files: ... 25
Access paths: ... 25
Physical Files: ... 26
Logical Files: ... 27
Types Of Logical Files ... 28
Join Logical File ... 28
Non - Join Logical File: ... 28
Field Reference Files: ... 29
Importance of using Field Reference Files ... 29
Naming Conventions ... 29
Chapter IV: Data Description Specification (DDS)
...
31
Defining Physical Files ... 31
Components of DDS ... 32
Record Level Keywords ... 33
Field Level Keywords ... 33
Key Field Level Key words ... 35
Defining Logical Files ... 36
Logical file Keywords ... 37
File Level Keywords ... 37
Record Level Keywords ... 38
Join Logical Files ... 39
Join Level Keywords ... 40
Examples of database files in DDS: ... 41
Example of a field reference file: ... 41
Example of a physical file with a new record format: ... 42
Example of a logical file specifying multiple formats and new keys: ... 43
Example of a logical file specifying a new record format: ... 43
Example of a join logical file: ... 44
DDM Files ... 45
Chapter V: SDA and Display Files
...
46
Screen Design Aid(SDA): ... 46
Adding fields. ... 48
Adding constants ... 48
Adding fields from a database file ... 48
Moving, Copying and Shifting fields ... 49
Date and Time keywords. ... 49
Display Files: ... 50
Chapter VI: RPG/400
...
57
RPG/400 Language Concepts ... 57 RPG/400 Specifications ... 58 H CONTROL SPECIFICATION ... 59 F FILE SPECIFICATION ... 59 E EXTENSION SPECIFICATION ... 59
L LINE COUNTER SPECIFICATION ... 59
I INPUT SPECIFICATION ... 59
C CALCULATION SPECIFICATION ... 59
O OUTPUT SPECIFICATION ... 59
RPG/400 Operation Codes (OPCODES): ... 59
Arithmetic Operations ... 60
ADD (Add Statement) ... 60
Z-ADD (Zeroise and add) ... 60
SUB (Subtract statement) ... 61
Z-SUB (Zeroise and subtract) ... 61
MULT (Multiply) ... 61 DIV (Divide) ... 62 MVR (Move remainder) ... 62 SQRT (Square root) ... 62 Move Operations: ... 62 MOVE (Move) ... 62
MOVEL (Move left) ... 63
Compare Operations ... 63
IFxx (If condition) ... 64
DOUxx (Do until) ... 65
DOWxx (Do while) ... 65
WHxx (When) ... 66
COMP (Compare) ... 66
Declarative Operations ... 67
PLIST ( Parameter list) ... 67
PARM (Parameter) ... 67
KFLD (Key Field) ... 67
KLIST (Key list) ... 67
DEFN (Definition) ... 68 TAG(Tag) ... 68 Initialization Operations ... 68 CLEAR (Clear) ... 68 RESET (Reset) ... 69 String Operations ... 69
CAT (Concatenate Two Character Strings) ... 69
CHECK (Check Characters) ... 70
CHEKR (Check Reverse) ... 70
SCAN (Scan Character String) ... 71
XLATE (Translate) ... 71
SUBST (Substring) ... 72
Subroutine Operations ... 72
CASxx (Compare and execute subroutine) ... 72
EXSR(Execute Subroutine) ... 73
BEGSR(Begin Subroutine) ... 73
ENDSR(End Subroutine) ... 73
Indicator Operations ... 74
SETON (Set on indicator) ... 74
SETOF (Set off indicator) ... 74
Structured Programming Operations ... 74
ORxx (Or condition) ... 74
ANDxx (And condition) ... 75
ELSE (Else) ... 75
END (End) ... 75
ENDyy (End Condition) ... 75
DO (Do Iteration) ... 76 SELEC (Select) ... 76 OTHER (Other) ... 77 ITER (Iterate) ... 77 LEAVE (Leave) ... 77 File Operations ... 78
SETLL (Set Lower Limits) ... 79
SETGT (Set Greater Than) ... 80
READ (Read a Record) ... 80
READE (Read Equal Key) ... 80
READP(Read a Previous Record) ... 81
REDPE (Read Prior Equal) ... 81
CHAIN (Random Retrieval from a File) ... 82
WRITE (Create New Records) ... 82
UPDAT (Modify Existing Record) ... 82
DELET (Delete Record) ... 83
Calling Operations ... 83
CALL (Call a Program) ... 83
PARM (Identify Parameters) ... 84
PLIST (Identify a Parameter List) ... 85
Branching Operations ... 86
GOTO(Go to) ... 86
ITER (Iterate) ... 86
LEAVE (Leave) ... 86
Array Operations ... 86
MOVEA (Move array) ... 86
XFOOT (Array Total) ... 87
LOKUP (Lookup) ... 87
SORTA (Sort array) ... 88
Data Area Operations ... 88
Commitment Control Operations ... 88
COMIT (Commit) ... 88
ROLBK (Roll Back) ... 88
Examples For File processing: ... 89
RPG syntax to process an externally defined Physical File: ... 89
RPG syntax to process a Program defined Physical File: ... 89
Chapter VII: Subfiles
...
91
Components of Subfile ... 91
Subfile Data Description Specification : ... 93
Handling Subfiles in RPG Programs ... 94
Multi page subfiles: ... 95
Subfile Load Options- Pros and Cons. ... 95
Load all Subfile: ... 95
... 96
Expanding Subfile: ... 98
Single Page Subfile: ... 100
Fold and Drop capabilities : ... 102
Other interesting Subfile Keywords: ... 103
Additional Recommended Reading Material ... 103
Chapter VIII: Arrays, Tables and Data structures
...
104
Arrays: ... 104
Loading of an array: ... 105
Compile time array: ... 105
Prerun time Array: ... 106
Run time array: ... 107
Searching Arrays ... 109
Searching an Array without an Index ... 109
Searching an Array with an Index ... 110
Specifying an Array in Calculations ... 111
Tables : ... 113
Data Structures: ... 113
Format of Data Structure Subfields in Storage: ... 113
Data Structure Statement Specifications: ... 114
Examples: ... 115
Multiple Occurrence Data Structure: ... 116
Data Areas : ... 117
Implicitly retrieved and written: ... 117
Explicitly retrieved and written: ... 117
Data Structures For Exception/Error Control ... 119
File Information Data Structures (INFDS): ... 119
Program Status Data Structure: ... 120
Chapter IX: RLU and Printer Files
...
122
Report Layout Utility (RLU) ... 122
Report Line ... 122
Report Prototype ... 122
Printer File Keywords ... 122
Processing Printer Files in RPG Programs: ... 125
Chapter X: Introduction To Control Language
...
126
Command Structure ... 126
Positional Form ... 126
Keyword form ... 127
Both positional and Keyword form ... 127
Command Continuation ... 128
Variable naming syntax ... 128
Concatenation ... 128
Relational Expressions ... 129
Logical Expressions ... 129
Substring expressions ... 129
Using variable in a CL program ... 130
Using files in CL program ... 130
File Operations ... 130
Error Handling ... 131
Assigning Values ... 131
Logical Operations ... 131
Steps involved in a typical OPNQRYF program: ... 135
Example: ... 135
Chapter XII: Message Subfiles in RPG
...
136
Message Subfiles ... 136
Steps Involved : ... 136
Example : ... 137
Appendix A : RPG Opcodes
...
142
Appendix B : AS/400 Data Limits
...
147
Chapter I :AS/400 Highlights
Introduction :
AS/400 is designed as an entire system ,taking into account all the layers that were added to systems over last 30 years as we discovered one after another while the computer industry matured. Current mature operating systems were originally batch processors , many times patched to accommodate interactive and database use with many faster ,roomier drives. The user sees these systems today through various and complicated interfaces and paths.
On the other hand , AS/400 design engineers created the layers of the onion from the outside in – the opposite of the design of older machines. First the functions that we all wanted, then user level interfaces that would make that function easy and accessible. Then the layers below those interfaces that would shield us from the intricacies of getting the function; finally a layered and queued system beneath the software in hardware(putting much software function of today into microcode). Paths among the layers were made standard and therefore movable and
changeable.
Technology-Independent Machine Interface
The AS/400 is a typical in that it is defined by software, not by hardware. In other words, when a program presents instructions to the machine interface for execution, it "thinks" that the interface is the AS/400 hardware. But it is not! The instructions, presented to that interface, have to pass through a layer of microcode before they can be understood by the hardware itself. This design insulates application programs and their users from changing hardware characteristics through this comprehensive layer of microcode. When a different hardware technology is deployed, IBM rewrites sections of the microcode to absorb the fluctuations in hardware characteristics. As a result, the interface presented to the customer remains the same.
This interface is known as the Technology-Independent Machine Interface (or TIMI). The microcode layer is known as the System Licensed Internal Code (or SLIC). The brilliance of this design was dramatically illustrated when the AS/400 changed its processor technology from CISC (Complex Instruction Set Computing) processors to 64-bit RISC (Reduced Instruction Set Computing) processors in 1995. With any other system, the move from CISC to RISC would involve recompiling (and possibly some rewriting) of programs. Even then, the programs would run in 32-bit mode on the newer 64-bit hardware. This is not so with the AS/400, because of TIMI. Customers were able to save programs off their CISC AS/400s, restore them on their new RISC AS/400s, and the programs would run. Not only did they run, but they were fully 64-bit programs.
As soon as they made this transition, customers had bit application programs that ran on a 64-bit operating system containing a 64-64-bit relational database that fully exploited the 64-64-bit RISC hardware.
Operating System OS/400
One of the single most dramatic things about AS/400 is that its operating system, OS/400, is a single entity. This section describes the meaning of this concept.
Once you buy an AS/400, you do not have to continue shopping for system software components before it is ready to run your business. All of those software components, for relational database, comprehensive security, communications with a broad range of diverse systems, including Internet capabilities, and many more, are already there.
They are all fully integrated into OS/400 (AS/400 operating system). By "fully integrated", we mean fully tested, too. All those components, prerequisites for running business applications in the 1990s, work together and are fully tested together, so that OS/400 operates as a single entity. An ordinary machine does not have this approach to its operating system design.
Single-Level Storage
Just as application programs on an AS/400 are unaware of underlying hardware characteristics because of the TIMI. They are also unaware of the characteristics of any storage devices on the AS/400, because of single-level storage.
As with TIMI, the concept of single-level storage means that the knowledge of the underlying characteristics of hardware devices (in this case, the hardware storage devices-- main storage and disk storage) reside in the SLIC. All of the storage is automatically managed by the system. Programs work with objects, and objects are accessed by name, never by address. No user intervention is ever needed to take full advantage of any storage technologies.
The AS/400's address size is vast.
Single-level storage enables another extremely important AS/400 benefit--object persistence.. Object persistence means that the object continues to exist in the memory system forever. An
ordinary machine requires that information be stored in a separate file system if the information is to be shared or if it is to be retained for a long time. Persistence of objects is extremely important for future support of object-oriented databases. Objects need to continue to exist even after their creator goes away. The AS/400 is uniquely positioned to exploit this characteristic of object persistence, where ordinary systems use a less-elegant mechanism that requires them to store their persistent objects in a separate file system, with all the attendant performance implications.
Logical Partitioning (LPAR)
As the performance of an enterprise class server grows, so does the requirement to divide that performance to run multiple workloads independently. Partitioning enterprise servers has become commonplace in the mainframe market since its introduction the mid-1980s. Typically, separate partitions are used for test releases of applications or to service multiple business units or companies from a single server.
Logical partitions (LPAR) enable multiple independent OS/400 instances or partitions in an n-way symmetric multiprocessing. Each partition requires its own processor(s), memory, disk(s), system console, with a CD-ROM and tape drive that can be allocated to each LPAR. With LPAR, you can address multiple system requirements in a single machine to achieve server consolidation, business unit consolidation, mixed production/test environments, integrated clusters, and more.
Objects
An object is a container. Everything the system uses--user and system data structures--is
packaged in one of these containers. The objects are encapsulated, which means that you cannot see inside. Inseparable from an object is the list of valid ways in which that object can be used. All objects are structured with a common object header, and a type-dependent functional portion. Therefore, on the AS/400, instructions can only work on what they are supposed to work on. You cannot have data treated as executable code (so that the processor tries, for example, to execute someone's shoe-size), or executable code treated as data, (by having something written into the middle of it). Certain instructions apply to all objects, while other instructions work only on specific types of objects. It is not possible to misuse an object, unlike the situation that exists other systems without an object-based approach.
There are two important consequences of an object-based design. The first is that a system built around an object model supports machine independence. This means that technology changes can be made in the environment without affecting application programs. The second
consequence is that an object-based design delivers a high level of system integrity. Components of an object
• Name –Generic name
• Type – attribute that defines the purpose of an object within the system. Each type has an associated set of commands that is used to process that object type.
• Attribute-An additional characteristic of an object within the object type.
• Owner-Name of the user who owns the object.
• Creation date /time.
• Save date /time.
• Restore date /time.
• Volume identifier for save.
• Free storage indication – Indication whether the object storage was freed when the object was saved.
• Size-Number of bytes allocated to the object in auxiliary storage.
Examples of Objects
CMD Command
Basic form of high level instruction to the system
DEVD Device Description
An information set describing the physical and logical attributes of a device connected to the system.
DTAARA Data area : A data store
DTAQ Data Queue
FILE File
JOBD Job desription
Information describing environment in which a job would be executed
JOBQ Job Queue
Queue where the jobs wait for execution.
JRN Journal:Object which controls storing of application data that needs to be recovered in case of a system failure.
JRNRCV Journal Receiver:File in which application data that needs to be recovered in case of a system failure is stored. A journal receiver is always associated with a journal.
LIB Library
MSGF Message File
A database file where messages are stored.
MSGQ Message Queue
Queues where messages wait to be passed or displayed.
OUTQ Output Queue
Queue where the system output waits to be viewed printed or transferred
AS/400 Processing Environment
What is a job?
A job is the basic unit of work on the AS/400.Every activity on the AS/400 is done as part of a job. Each job is a single , identifiable sequence of processing actions that represent a single use of the system.
Attributes of a job:
Job number:The job number is a unique system generated sequential number
Job Name :Job name is any user defined name. For certain jobs, the system assigns a job name which is usually the name of the corresponding job description.
User Name:User name attributed with a job is the name of the user who initiated the job. The combined usage of the job number, job name and user name uniquely identifies a job in the system.
Job Description:
A job description is a collection of parameters that control the job when it is started in the subsystem. The advantage of using a job description is that once it is defined you can use it anywhere just by referring to the job description name whenever you want to start job. Subsystem
A subsystem is single predefined operating environment in which the system coordinates the work flow and resources. Subsystems are specific user defined job partitions of the CPU where various jobs may be executed. The system is shipped with a set of IBM supplied subsystems which may be modified if required. One subsystem may have more than one job active at a time. Job Queues
Job Queues are streams where jobs wait for execution. Job queues are attached to specific subsystems. One subsystem may have more than one jobq attached to it.
Output Queues
Output queues are streams where output from the jobs wait to be processed. It is a place to hold the output spooled files created by jobs.
Type of Jobs
An interactive job starts when the user signs on to the machine and lasts until user signs off. A job is created by the system to interactively react to the users responses and thus is called an interactive job.
Batch jobs:
A Job is called a batch job when a series of actions submitted to a job queue for execution in one single job stream.
Spooling job:
A spooling job can be for input or output.In an input spooling job ,a system program called a reader transfers job from the input device such as a diskette or database file. For output spooling , the job puts the output from a program into a spooled file , later the spooled file can be written to an external device such as a printer.
Autostart job:
A autostart job is always associated with the subsystem , and whenever the subsystem is started the autostart job is started as well.
Additional Recommended Reading Material :
AS/400 Security
The Security is unbreachable because it is not a layer added on top of an interface , which , after being unlocked provides complete access. Rather, it is a check built in every step the system takes for you (once again , with this system you only request work to be done for you , you do not actually do it yourself). It is built into both the hardware and the software and it has to do with function ,location, user type and type of use.
On the AS/400 all information is stored in objects. Access to that information is through hardware instructions that ensure object integrity . Any attempt to misuse an object detected, causing the system to terminate the instruction and signal an exception condition.
Security at object level:
Object ownership:
All objects have owners. Initially , the user who creates the object is the owner. However, the owner, the Security officer, or a user with Object existence rights can transfer ownership to another user.
Public or Private authority over an object:
Object use can be authorized privately or publicly. ‘Private’ means to specific users; ‘Public’ means to all users.
Looking at Security from the object outward:
The owner of the object has authority to do all things possible to it.
• *ALLOBJ authority can be granted to a user , which gives this user ‘ all things possible’ authority. Now the grantee can further grant authority and revoke it as well, even from the original owner.
• *PUBLIC authority reaches everybody and can be granted by the owner at some command level to all system users.
Security over libraries can be defined at these levels:
• *EXCLUDE – Users Can’t get it all(only the owner and security officer can use it)
• *USE – A user can DISPLAY the content of the library ,use commands to find objects ,put the library in LIB list, and save the library.
• *ALL- Users have all the object authorities and all the data usage level authority on the contents of this library on the library itself.
Object Authority:
Object authority is used to control access to an object including the ability to see an object description, control read and write access to an object, or control an object's existence.
• *OBJMGT : provides the authority to specify the security (grant/revoke object authority), move or rename the object, and add members to database file.
• *OBJEXIST: provides the authority to control the object existence and ownership. The user with this authority can delete, save, and transfer ownership of the object.
• *OBJOPR : provides the authority to look at the description of an object and use the object as determined by the data authority that the user has to the object.
Data Authority:
Data authority is the authority to access data contained in an object, for example records in a database file. This includes the ability to view, update, add, or delete records.
• *READ :provides the authority to get the contents or an entry in an object or to run a program.
• *ADD :provides the authority to add entries to an object.
• *UPD :provides the authority to change the entries in an object.
• *DLT :provides the authority to remove entries from an object. Combinations of Object and Data Authorities
These are keywords, each representing predefined combination of object and data authorities. They reduce the time required to assign specific authorities to users.
*ALL
allows the user to perform all authorized operations (object and data) on the object. *CHANGE
provides *OBJOPR authority and all data authority. *USE
provides *OBJOPR authority and data read authority. *EXCLUDE
authority prevents the user from accessing the object even if *PUBLIC is authorized. In addition to these, users can create customized combinations of object and data authorities
Security Functions
Setting the security levels for the system
The system can be set to various security levels. The system is shipped with a ‘minimum’ security level, which means that any user can sign on and use any data or programs on the system. If your system has more than just ‘minimum’ security officer controls, who has access to the system and its data.
Security Levels
The AS/400 system allows to select the level of security needed to use on your system. The different levels provide varying degrees of security, which are as follows:
Level 10
The system is not secured. No password is required to signon. No resource security is used, so all users can access and use all system resources.
Level 20
The system has limited security. A password is required to signon, but no resource security is used. All users can access and use all system resources.
Level 30
The system is designed to be fully secured. A password is required to signon.Resource security is used , which means that system resources are available to users depending on what objects they have authority to use and what special authorities they have.
Level 40
The system is designed to be fully secured, as it is for level 30.In addition, the system is protected from access by unsupported interfaces.
Application Development Tools (ADT)
Program Development Manager (PDM)
Program Development Manager is a complete development tool which allows the programmer to perform all programming related activities under one single menu driven easy to use and comprehensive environment.
Functions of PDM
• PDM allows the user to work with the libraries and objects in terms of performing the following functions among others.
♦ Create ♦ Change ♦ Display ♦ Delete ♦ Rename ♦ Move
• Work with members namely Edit / Rename / Clear / Remove
• Find strings, that is to find a character or string in a source or data file.
• Define Commands to perform repetitive actions on objects from a list
• Call the other Application Tools mentioned Below : Source Entry Utility (SEU)
Screen Design Aid (SDA) Data File Utility (DFU) Report Layout Utility (RLU)
Invoking PDM
Program Development Manager can be invoked in any one of the following ways :
1. Take option ‘5’ for the programmers menu from the AS/400 main menu.Then take option ‘2’ for PDM from the programmer’s menu
2. Enter command ‘STRPDM’ from any command entry line
AS/400 Programming Development Manager (PDM) Select one of the following: 1. Work with libraries 2. Work with objects 3. Work with members 9. Work with user-defined options Selection or command ===>______________________________________________________________________________ F3=Exit F4=Prompt F9=Retrieve F10=Command entry F12=Cancel F18=Change defaults (C) COPYRIGHT IBM CORP. 1981, 2000.
3. Enter command ‘WRKLIBPDM” – Work with Libraries in PDM – from any command entry line to work with libraries
Work with Libraries Using PDM List type . . . *LIBL Type options, press Enter. 2=Change 3=Copy 5=Display 7=Rename 8=Display description 9=Save 10=Restore 12=Work with ... Opt Library Type Text - RBTSYSLIB *PROD-SYS ROBOT SYSTEM LIBRARY - QSYS *PROD-SYS SYSTEM LIBRARY - QSYS2 *PROD-SYS SYSTEM LIBRARY FOR CPI'S - QHLPSYS *PROD-SYS - QUSRSYS *PROD-SYS System Library for Users - SYSTEM *PROD-SYS EHQ System Software - XCOM2 *PROD-SYS CA-XCOM software library - QMQM *PROD-SYS MQSERIES FOR AS/400 - QSYS2924 *PROD-SYS More... Parameters or command ===> ______________________________________________________________________________ F3=Exit F4=Prompt F5=Refresh F6=Add to list F9=Retrieve F10=Command entry F23=More options F24=More keys
4. Enter command ‘WRKOBJPDM” – Work with objects in PDM – from any command entry line to work with objects
Work with Objects Using PDM Library . . . TSTLIB Position to . . . ________________ Position to type . . . ________________ Type options, press Enter. 2=Change 3=Copy 4=Delete 5=Display 7=Rename 8=Display description 9=Save 10=Restore 11=Move ... Opt Object Type Attribute Text - XMSGDTARFP *FILE PF-DTA MDL Message Physica - YABOABARFP *FILE PF-DTA yaboabarfp Physical fi - YABOABAXXP *FILE PF-DTA Contains YABOABARFP deleted model dat - YABOABA00L *FILE LF MDL Abo update (@@ABOABA) - YABOABA01L *FILE LF MDL Abo action rtv (@@ABO/@@CHC/@@ABO - YABOABA02L *FILE LF MDL Abo action rtv (@@ABO/@@ABOABA_P) - YABOABA03L *FILE LF MDL Abo action rtv (@@ABO/@@REFCND > - YABOABA04L *FILE LF MDL Abo update (@@ABO/@@ABOABA) More... Parameters or command ===>______________________________________________________________________________ F3=Exit F4=Prompt F5=Refresh F6=Create F9=Retrieve F10=Command entry F23=More options F24=More keys
5. Enter command ‘WRKMBRPDM” – Work with members in PDM – from any command entry line to work with members
Work with Objects Using PDM
Library . . . TSTLIB Position to . . . ___________ Position to type . . . _____________
Type options, press Enter. 2=Change 3=Copy 4=Delete 5=Display 7=Rename 8=Display description 9=Save 10=Restore 11=Move ... Opt Object Type Attribute Text XMSGDTARFP *FILE PF-DTA MDL Message Physica YABOABARFP *FILE PF-DTA yaboabarfp Physical fi YABOABAXXP *FILE PF-DTA Contains YABOABARFP deleted model dat YABOABA00L *FILE LF MDL Abo update (@@ABOABA) YABOABA01L *FILE LF MDL Abo action rtv (@@ABO/@@CHC/@@ABO YABOABA02L *FILE LF MDL Abo action rtv (@@ABO/@@ABOABA_P) YABOABA03L *FILE LF MDL Abo action rtv (@@ABO/@@REFCND > YABOABA04L *FILE LF MDL Abo update (@@ABO/@@ABOABA) More... Parameters or command ===>______________________________________________________________________________ F3=Exit F4=Prompt F5=Refresh F6=Create F9=Retrieve
PDM is terminated by pressing EXIT (F3) function key
Source Entry Utility (SEU)
Source Entry Utility is a development tool that allows the entry, review and display of program source statements and date descriptions specification for various specification types.
Functions of SEU
SEU function is allow the user to:
♦ Create / add new members
♦ Revise existing members
♦ Browse / Copy the existing members
SEU can be invoked through one of the following methods: 1. Select option ‘5’ from the programmers menu
2. Select option ‘2’ from the Work with members display in PDM to browse through the source members
3. Select option ‘5’ from the Work with members display in PDM to edit source members 4. Enter command ‘STRSEU’ from any command entry line.If the command is Invoked
without a qualified member name, a list of all the members in the file is displayed.
Data File Utility (DFU)
Data File Utility (DFU) is a development tool that allows the entry, revision and browse of data records from the database files.
Functions of DFU
DFU functions are to allow for the creation of applications for the manipulation of data records. These applications can then be executed to manipulate data records.
Manipulation of data records includes adding or inserting new records and changing, deleting or displaying existing records
AS/400 security allows for the restriction of access to the selected files bound by the user Securiry.
Additional recommended reading Material:
1. SC09-1338-02 SEU User’s Guide and Reference.
2. SC09-1339-02 PDM User’s Guide and Reference.
3. SC09-1340-02 SDA User’s Guide and Reference.
4. SC09-1416-02 RLU User’s Guide and Reference.
Chapter II –Libraries
A Library is an AS/400 object that serves as a repository for other objects. It is not a parititioned data set but rather an index to other objects. The library can never become ‘full’ as it has no definite size. Generally a library can contain any set of objects grouped for a specific purpose.
Library Categories
The libraries can be categorised ac IBM supplied libraries, user-defined libraries . IBM Supplied Libraries are:
1. QSYS Contains IBM supplied programs and data.This library cannot be deleted or renamed. This library is owned by system security officer. 2. QSYS36 Contains objects required to run software developed on the
System/36.The software would then be executed in ‘System/38 mode’.
3. QSYS38 Contains objects required to run software developed on the System/38. The software would then be executed in ‘System/38 mode’
4. QGPL Contains IBM supplied objects for general use. This library is present in every library list unless explicitly removed.
5. QTEMP Created automatically for every job. The library hold temporary objects such as work files. This library can be accessed by the job that created it. This library would be deleted when the job is terminated.
6. QSRV Service engineer library.
7. QRCL Reclaim storage library .It is created when a Reclaim Storage command(RCLSTG) is executed and would contain objects that were purged by the command.
8. QRPG Report Program Generator library. It contains RPG compiler and the objects required to enter,edit and compile RPG programs.
9. QCBL COBOL/400 library.It contains COBOL compiler and the objects required to enter, edit and compile COBOL/400 programs.
10. QIBU Interactive data base utilities library.
11. QINS Interactive workstation support library that contains all IBM supplied objects that are required to transfer data between AS/400 and PCs. User-defined libraries
These libraries are created by users for specific application and uses.User-defined library name may be use-defined alphanumeric name not more than 10
characters. Library names may not have embedded blanks and must not begin with a number.
Library List:
It is a list of libraries associated with each job which defined the operational boundaries of a job. Each job has a default library list which may be modified if required.Each library list consists of four parts. They are:
System library section - This section consists the libraries containing objects used by the system for regular processing functions. The number of libraries in this section cannot exceed 15.
Product library section - This section contains libraries that are required to support high level languages and utilities other than QSYS.
Current library section – This section contains the ‘current library’ as identified by the job.
User library section – This section contains libraries required by system users and applications such as non-IBM application solutions.The number of libraries in this section cannot exceed 25.
Library commands:
Common commands associated with libraries are: CRTLIB Create library
DSPLIB Display library DLTLIB Delete library
ADDLIBLE Add library list entry RMVLIBLE Remove library list entry RPLLIBL Replace library list CHGCURLIB Change current library
Additional Recommended Reading Material
1. GC41-9802-01 AS/400 System Concepts.
Chapter III: AS/400 Database
In AS/400, the data base is integrated into the operating system and is the licensed internal code of the AS/400 system. There is no requirement to install or maintain a separate database
management product. Any program that wants to store or use data on the AS/400 system uses integrated database
File Types:
1. Database files arefiles (including distributed files) whose associated data is stored permanently in the system.
i. Physical files 1. Data files 2. Source files ii. Logical files
2. Device files are files that provide access to externally attached devices such as displays, printers, tapes, diskettes, 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
– Diskette files, which provide access to data files on diskette devices
– Intersystem communications function (OS/400-ICF) files, hereafter referred to as ICF files, which allow a program on one system to communicate with a program on the same system or another system
3. Save files are files that are used to store saved data on disk (without requiring diskettes or tapes).
4. Distributed Data Management files (DDM files) are files that allow access to data files stored on remote systems.
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. This information is designed to help you understand the common characteristics of all file types so you can use the files to their full capabilities.
Database Files:
• The Object type is *file
• It contains description of how input data is to be presented to programs from internal storage and how output data is to be presented to internal storage from a program
Access paths:
Arrival Sequence Access Path :
• It is based on the order in which the records arrive and are stored in the file
• Sequentially, where each record is taken from the next sequential physical position in the file
• It is based on the contents of the key fields as defined in DDS
• This type of access path is updated, whenever records are added or deleted.
Physical Files:
• A description of how data is to presented to or received from a program and how data is actually stored in the database
• A Physical file contains one record format and one or more members Components of a Physical File
• Object Header This contains the regular object information
• Record Format Describes the format in which the records are stored • Access Path Describes the order in which records are to be retrieved • Data Member Contains data
Data Description Specification for a Physical File: • File Level entries (optional):
File level entries give the system information of the entire file including whether the key is unique
• Record Level entries :
Give the system information about the specific record format in the file • Field Level entries :
The field names and field lengths are specified along with an optional text description for each field
• Key Field Level entries :
The field names used as key fields specified DDS Keywords:
• File Level : Unique, LIFO, FIFO, FCFO, Ref • Record Level : Format, Text
• Field Level : Alias, Reffld, Text, Edtcde, Datfmt, Datsep, Alwnull, Check(AB, ME, MF), Cmp/Comp, ColHdg, Dft, Range, Timfmt, Timsep, Values
• Key-field Level : Absval, Descend, Signed, Unsigned Characteristics of a Physical File
• Maximum no. of fields that can be defined in a PF is 8000 • Maximum no. of members that a single PF can have is 32,766 • Maximum size of a member in a PF is 32,766 bytes
• Maximum length of a file name is 10 characters
• Maximum length of a record format name is 10 characters • Maximum length of a field name is 10 characters
• Maximum number of key fields in a PF is 200 View of a Physical File:
File Level Unique
Record Level R Recfmt
Field Level Name 20
Age 10 P
Phone 10 P 3
Logical Files:
• Logical File is an AS/400 object of type *file and attribute LF
• Used to arrange data from one or more physicals into different formats and sequences • Logical file does not contain any data, but provides ‘VIEWS’ of the data to satisfy
end-users’ needs
• A logical file can contain up to 32 record formats and can obtain data from 2 to 32 physical files
Components of a Logical File:
• Object Header This contains the regular object information
• Record Format Describes the format in which the records are stored • Access Path Describes the order in which records are to be retrieved • Data Member Contains Data
Data Description Specification for a Logical File: • File Level entries (optional):
File level entries give the system information of the entire file including whether the key is unique
• Record Level entries :
Give the system information about the specific record format in the file • Join Level entries :
Give the system information about physical files used in JOIN Logical File (Not applicable for Non-Join Logical File)
• Field Level entries :
The field names and field lengths are specified along with an optional text description for each field
• Key Field Level entries :
The field names used as key fields specified • Select / Omit Level entries :
Give the system information about, which records are to be returned to the program when processing the file
DDS Keywords:
• File Level : Unique, LIFO, FIFO, Jdftval(JLF)
• Record Level : Jfile (Join File), Pfile (Physical file), Text
• Join Level : Jdupseq, JFld, Join
• Field Level : Alias, Reffld, Edtcde, Datfmt, Datsep,
Check(AB, ME, MF), Cmp/Comp, ColHdg, Dft, Range, Timfmt, Timsep, Values, JRef
• Key-field Level : Absval, Descend, Signed, Unsigned • Select/Omit Level : Comp, Range, Values, All
View of a Logical File:
Types Of Logical Files
• Non - Join Logical Files • Join Logical Files
Join Logical File
• Join logical files are READ only files and may not be used in UPDATE or DELETE processing
• Support only Inner and Left Outer Joins. Outer Join processing is not supported • They may refer 2 to 32 physical files
• Any key field specified must be included in the primary file
• Select / Omit criteria may be specified for any field in a Join Logical File Data Description Specification for Join Logical Files:
• File Level entries • Join Level entries • Record Level entries • Field Level entries • Key Field Level entries
• Select and Omit Field Level entries View of a Join Logical File:
R Joinrcd JFILE(PF1 PF2) J JOIN( 1 2 ) JFLD( ENO ENUM ) Enum JREF(1) Ename JREF(1) Dept JREF(2) K Enum S Enum comp GT 1010
Types of Join Logical File: There are 3 types of Logical Files
1. Natural Join or Inner Join : When this type of a JLF is read only the matching records of both the files appear
2. Left Outer Join : All the records from the primary file appear. Missing secondary records (records for which no match is found) are filled with default values. This is enforced by using JDFTVAL keyword
3. Self Join: Joining a file to itself
Non - Join Logical File:
• A Non-Join logical file can either be a simple logical file which contains only one record format or a multiple format logical file which contains more than one record format
• Non-Join logical files can be used for READ, WRITE and UPDATE processing • Can join a maximum of 32 Physical files
•
Data Description Specification for Non-Join Logical Files: • File Level entries
• Record Level entries • Field Level entries • Key Field Level entries
• Select and Omit Field Level entries
Repeat steps 2 through 5 for each record format in the file
View of a Non-Join Logical File:
Record Level R PFRecfmt1 PFILE(PF1)
Field level Cust#
Key-field Level K Cust#
Record Level R PFRecfmt2 PFILE(PF2)
Field level Cust#
Key-field Level K Cust#
Field Reference Files:
• A physical file that contains no data, but only description of fields. • It is used as a reference for the field descriptions of other files
Importance of using Field Reference Files
It enforces the naming convention
• Reduces programmer’s work load (define once, use often)
• It defines in one place all data elements used in the application for all users
Naming Conventions
• The file name, record format name, field name cannot be more than 10 character’s • The first character should be alphabetic
• Field names should be unique in a record format
• Record format names and member names should be unique in a file • File names should be unique in a library
Additional Recommended Reading Material
1. SC41-9659-02 AS/400 Database Guide
Chapter IV: Data Description Specification (DDS)
Data Description Specifications(DDS) defines all attributes of a file and which are coded in a system-defined format. These definitions or specifications can be maintained
externally and independent of programs or other dependent files. These statements are
entered into a system-defined format as a source file which is created or compiled as a file.Data records are then written into or retrieved from this file using certain Application
Development Tools or though use-defined application programs.
DDS are coded and entered into a system-defined format known as ‘A’ specifications. Each file is coded as a separate source member.’A’ specifications are used to code the following types of files.The positions and entries are unique and may differ for the different files.
Physical files. Logical files
Display (or workstation) files and Printer files
Defining Physical Files
The Data Description Specifications(DDS) for Physical Files are defined in data specifications in the following layout:
Positions Name Entry Explanation
1-5 Sequence
number
None This is an optional column and may be used to identify, mark or tag source statements.
6 Form type ‘A’ Denotes ‘A’ Specification
7 Comment ‘*’ Denotes a comment line. Comments may be entered
betweenpositions 8 and 80.
8-16 Reserved Blank This position Is not used for physical files and
must be blank.
17 Type of Name ‘R’
‘ ‘ ‘K’
Record format name. Field name.
key field name.
19-28 Name Record name or field name or key field name.
29 Reference R Denotes that a definition and attributes of the
Positions Name Entry Explanation
30-34 Length Length of the field.
The following are the valid lengths for various types of fields. Character 1 to 32766 Hexadecimal 1 to 32766 Binary 1 to 9 Numeric 1 to 31 35 Data Type P S B F A H L T Z Packed decimal Zoned decimal Binary Floating point Character Hexadecimal Date Time Timestamp. 36-37 Decimal
position Number of decimalpositions
38 Usage ‘B’
‘ ‘
Both input and output Defaults to B
39-44 Location This column is reserved and is not used by physical
files.
45-80 Keywords.
Components of DDS
DDS definitions are a serious of statement that are entered as source statements. These statements may be entered in to the following levels of definitions.
File level keywords are entered at the file qualify the named file and are applicable to all the record and field definition that follow.
Record format level keywords are entered at the record format level qualify the named record format and are applicable to all the field definitions contained within the record format.
Join level keywords are used to specify parameters that are used to join one or more files in to a single record format. These keywords are valid only in join logical files.
Field level keywords are used to qualify the named field.
Key field level keywords are used to qualify the key or the access sequence of a file. For example, UNIQUE can be specified to prevent existence of duplicate key values in a file. Select/Omit level keywords are used to specify rules for the selection of records from a
physical file, these keywords are valid only in logical files. Naming Conventions
The normal rule for naming of files, record formats and fields is a 10 character alphanumeric value which does not contain embedded blanks and does not start with a numeric value. However, some high level languages like RPG/400 supports only 8 character file and record format names and 6 character field names.
Physical File Keywords
Keywords used in physical files are vided into 4 parts. They are: File level Keywords
Record level Keywords Field level Keywords Key-field level Keywords
There are in all over 35 keywords associated with physical files.These keywords are used to provide further qualification to the file, record format, field or key field.Some of the more commonly used keywords are:
File Level Keywords
FCFO First Changed First Out
When duplicate key exists in a file this keyword is used to specify that the record that was changed earliest is to be retrieved.
FIFO First In First Out
When duplicate key exists in a file this keyword is used to specify that the record that was written earliest is to be retrieved.
LIFO Last In First Out
When duplicate key exists in a file this keyword is used to specify that the record that was written most recently is to be retrieved.
REF Reference
Used to indicate the name of another file from which field references wherever indicated are to be retrieved.
UNIQUE Unique Key
Used to indicate that records with duplicate key values will not be allowed in this file.
Record Level Keywords
TEXT Text
Used to assign descriptive text for the record format.
Field Level Keywords
ALIAS Alias Name
Used to indicate the alias name for the named field.
CHECK Check values
Used to provide certain validity rules for the named field.The values associated with this keyword are as follows:
AB Allow blanks
ME Mandatory Entry
MF Mandatory Full
M10 Modulus 10 validation
M10F Modulus 10 validation(IBM variation) M11 Modulus 11 validation
M11F Modulus 11 validation(IBM variation) Example, CHECK(ME)
CMP/COMP Compare Value
Used to provide validation to specify that the named field must contain value specified in this parameter. Example, COMP(*EQ ‘A’)
COLHDG Column Heading
Used to provide descriptive text about the named field. This text is used when the field is used in certain application development tools such as Data File Utility(DFU) and Query. Up to three strings of 20 characters each can be specified.
DATFMT Date Format
Used to define the format (namely one of either, YY/MM/DD or MM/DD/YY or DD/MM/YY) in which date is to be stored in the named field.
DATSEP Date separator
Used to identify the character used to separate the elements of a date.
DFT Default Value
Used to nominate a default value when the record is written.
EDTCDE Edit Code
Used to identify a system-supplied editing rule for the named field. Rules could include zero suppression, zero balance, sign etc.
RANGE Range
Used to specify a range of values that are allowed to be input in to the named field.
REFFLD Referenced Field
Used to reference a field from an earlier referenced file whose length and attributes are to be attached to the named field.
REFFLD(FLDA) REFFLD(RECFMT01/FLDA) REFFLD(RECFMT01/FLDA FILEA) REFFLD(RECFMT01/FLDA *LIBL/FILEA) REFFLD(RECFMT01/FLDA LIBA/FILEA) TEXT Text
Used to assign descriptive text to the named field to be used in all future references of the named field. Example, TEXT(‘Customer code’).
TIMFMT Time Format
Used to define the format in which time is to be stored in the named field.
Used to identify the character to be used to separate the elements namely hour,minute and second of time.
VALUES Values
Used to assign one or more values that are allowed as valid input in to the named field. Example, VALUES(‘A’, ‘B’, ‘C’, ‘D’, ‘E’).
Key Field Level Key words
ABSVAL Absolute Value
Used to indicate that when retrieving records from the named file, the sign of the key field is to be ignored and only the absolute value of the field is to be used for purposes of ordering sequences.
DESCEND Descending Sequence
Used to specify an ordering sequencing for the retrieval of records from the named file.when retrieving records from named file, the records would be sequenced in the descending order of the named key field.
SIGNED Signed
Used to specify that the sign of the named key-field is to be considered for purposes of ordering sequence when retrieving records from the named file.
Defining Logical Files
The Data Description Specifications(DDS) for Logical Files are defined in data specification in the following.
Positions Name Entry Explanation
1-5 Sequence
Number
None This is an optional column and may be
used to identify mark or tag source statements.
6 Form Type ‘A’ Denotes ‘A’ specification
7 Comment ‘*’ Denotes a comment line .Comments may
be entered between positions 8 and 80.
8-16 Conditioning Blank This position is not used for logical files
and must be blank
17 Type of Name ‘R’ J ‘ ‘ ‘K’ ‘S’ ‘O’
Record format name Join Specification Field name Key field Name Select Criteria Omit Criteria
18 Reserved Blank This position is not used for logical files
and must be blank
19-28 Name Record name or field name or key field
name
29 Reference R Denotes that a definition and attributes of
the named filed are to be referenced from a previously defined field.
30-34 Length Length of the field the following are the
valid lengths for various types of fields. Character 1 to 32766 Hexadecimal 1 to 32776 Binary 1 to 9 Numeric 1 to 31 35 Data Types P S B F A H L Packed decimal Zoned decimal Binary Floating point Character Hexadecimal Date Time
Positions Name Entry Explanation T Z Timestamp 36-37 Decimal Position
Number of decimal positions.
38 Usage ‘B’ Both input and output
Default to B
39-44 Location Blank Thos column is reserved and is not used by
logical files.
45-80 Keywords
Logical file Keywords
Keywords used in logical files are divided into four parts, namely , File level keywords
Record level keywords Field level keywords Key-field keywords
There are in all over 45 keywords associated with logical files .These keywords are used to provide further qualification to the file , record format, field or key fields. Some of the more commonly used keywords are explained in the subsequent section.
File Level Keywords
DYNSLT Dynamic Select
Used to instruct that selection of records according to the criteria specified in the file must be maintained dynamically as and when records are written into or retrieved from the database file that is pointed to by the logical file.
FCFO First Changed First out
When duplicate key exists in a file this keyword is used to specify that the record that was changed earliest is to be retrieved.
FIFO First In First Out
When duplicate key exists in a file this keyword is used to specify that the record that was written earliest is to be retrieved.
LIFO Last In First Out
When duplicate key exists in a file this keyword is used to specify that the record that was written most recently is to be retrieved.
UNIQUE Unique Key
Record Level Keywords
PFILE Physical File
Used to name the physical file that is being pointed to by the named logical file .This keyword is mandatory for every logical file definition.
TEXT Text
Used to assign descriptive text for the record format. Field Level Keywords
ALIAS Alias Name Used to indicate the alias name for the named field . CHECK Check Values
Used to provide certain validity for the named field. The value associated with this keyword are as follows:
AB Allow Blanks ME Mandatory Entry MF Mandatory Full M10 Modulus 10 Validation
M10F Modulus 10 Validation(IBM variation) M11 Modulus 11 Validation
M11F Modulus 11 Validation(IBM variation) Example,CHECK (ME).
CMP/COMP Compare Value
Used to provide validation to specify that named field must contain value specified in this parameter.Example,COMP(*EQ’A’)
COHDG Column Heading
Used to provide descriptive text about the named field.This text is used when the field is used in a certain application development tools such as Data File Utility(DFU)and QUERY.Upto three strings of 20 characters each can be specified .
DATFMT Date Format
Used to define the format (namely one of either ,YY/MM/DD or MM/DD/YY or DD/MM/YY)in which date is to be stored in the named field.
DATSEP Date Separator
Used to identify the character used to separate the elements of a date. EDTCDE Edit Code
Used to identify a system-supplied editing rule for the named field.Rules could include zero suppression,zero balance ,sign,etc.
TEXT Text
Used to assign descriptive text to the named filed to be used in all future references of the named filed.Example ,TEXT(‘Customer Code’).
TIMFMT Time Format
Used to define the format in which time is to be stored in the named field. TIMSEP Time Separator
Used to identify the character to be used to separate the elements namely hour,minute and second of time.
VALUES Values
Used to assign one or more values that are allowed as valid input into the named field. Example,VALUES(‘A’’B’’C’”D’’E’).
Key Field Level Keywords
ABSVAL Absolute Value
Used to indicate that when retrieving records from the named file the sign of the key-field is to be ignored and only the absolute value of the field is to be used for purpose of ordering sequences.
ALL All
Used in conjunction with Select and Omit criteria specification to indicate that all records not fulfilling the Select or Omit criteria must be selected or omitted as the case may be.
DESCEND Descending Sequence
Used to specify an ordering sequence for the retrieval of records from the named file.When retrieving records from the named file,the records would be sequenced in descending order of the named key-field.
SIGNED Signed
Used to specify that the sign of the named key-field is to be considered for purposes of ordering sequence when retrieving records from the named file.
UNSIGNED Unsigned
Used to specify that the sign of the named key-field is to be ignored for purposes of ordering sequence when retrieving records from the named file.
Join Logical Files
A join logical is a logical file which contains definitions required to join two or more different files based on certain user-defined join conditions.
The first file being joinng is called the ‘Primary file’ while the other are called ‘Secondary files’.The primary file and atleast one of the secondary files must be a physical file.
When accessing a join file record, the system internally reads a record from the primary file and picks up the corresponding record from the secondary file based on the user-defined join criteria and then presents the combined data to the accessing program in one consolidated record.
If required, when specifying the primary file and secondary file ,only certain fields from either file may be selected for join file record format rather than all the fields from both the files. But all the fields indicated in join criteria must be selected .
Special consideration
* You cannot change a physical file using a join logical file. * You can specify only one record format in join logical file. * Commitment control cannot be used with join logical files.
Join Level Keywords
The keywords used in join logical files are:
JFILE Join File
Identifies the names of the two files being joined.This keyword is specified at the record level.
JFLD Join Field
Used to name the fields that are to be used for purposes of joining the primary file and secondary file.Join fileds must have the same attributes.This keyword is specified at the record level.
JOIN Join
Identifies the names of the two files being joined.This keyword is specified at the join level.
JREF Join Reference File
Identifies the file from which the named fields is to be retrieved from.This keyword is specified at the field –level.
Examples of database files in DDS:
Example of a field reference file:
This example defines all of the fields used in an application and refers to fields only within the field reference file itself. The following keywords are important in the example:
COLHDG EDTCDE(Z) REFFLD REFSHIFT TEXT
The following field reference file (MLGREFP) describes all fields used by any program in the application. The other files use the fields in this file.
Figure 1. DDS for a Field Reference File
00010A** FLDREF MLGREFP MAILING LIST FIELD REFERENCE FILE
00020A (1)R MLGREFR TEXT('Mailing List Field Reference') 00030A ACTNUM 5 0 COLHDG('Account' 'Number') 00040A EDTCDE(Z)
00050A ACTTYP 1 0 COLHDG('Acct' 'Type')
00060A TEXT('Acct Type 1=Bus 2=Gvt + 00070A 3=Org 4=Sch 5=Pvt 9=Oth') 00080A NAME 18 COLHDG('Name')
00090A REFSHIFT(X)(4) 00100A ADDR R (2) (2)REFFLD(NAME)
00110A COLHDG('Address')(3) 00120A CITY R (2) (2)REFFLD(NAME)
00130A COLHDG('City') (3) 00140A STATE 2 COLHDG('State') 00150A ZIP 5 0 COLHDG('ZIP' 'Code') 00160A EDTCDE(X)
00170A BATNUM 6 0 COLHDG('Batch' 'Number') 00180A EDTCDE(Z)
00190A TRNTYP 1 COLHDG('Trans' 'Type') 00200A TEXT('Trans Type A=Add + 00210A C=Change D=Delete') 00220A XACTNM R REFFLD(ACTNUM) 00230A XACTTTP R REFFLD(ACTTYP) 00240A XNAME R REFFLD(NAME) 00250A XADDR R REFFLD(ADDR) 00260A XCITY R REFFLD(CITY) 00270A XSTATE R REFFLD(STATE) 00280A XZIP R REFFLD(ZIP)
00290A TRNNUM 5 0 COLHDG('Transaction' 'Number') 00300A EDTCDE(Z)
00310A MLGLK1 3 0 COLHDG('Lock' 'Control') 00320A TEXT('Control Number Used for + 00330A record locking')
(1) Like all physical files, a field reference file has only one record format. The R in position 17 specifies that MLGREFR is the record format name.
(2) The Rs in position 29 and REFFLD in positions 45 through 80 specify that the fields ADDR and CITY are to have the same attributes as NAME.
(3) Specifying COLHDG for ADDR and CITY overrides the COLHDG attribute for NAME, which otherwise would have been in effect.
(4) Specifying REFSHIFT for NAME will cause the keyboard shift specified (X) to be used when this field (NAME) is referred to in a display file.
Example of a physical file with a new record format:
The REF keyword is important in the following example. This file has one record format. The names of all fields in the record format are specified. This example uses fields in a reference file (REF keyword) and uses a keyed-sequence access path.
The following physical file (called CUSMSTP for customer master physical file) describes the fields physically present in the database.
Figure 2. DDS for a Physical File 00010A*
00020A* SAMPLE PHYSICAL FILE(CUSMSTP) 00030A*
00040A (1) REF(MLGREFP)
00050A (2) R CUSMST TEXT('Customer Master Record') 00060A ACTNUM R (3) 00070A NAME R (3) 00080A ADDR R (3) 00090A CITY R (3) 00100A STATE R (3) 00110A ZIP R (3) 00120A (4) SEARCH 10 0 00130A (4) CRDLMT 8 2 00140A (5) K ACTNUM Legend:
(1) At the file level, the REF keyword refers the OS/400 program to the physical file MLGREFP, which is a field reference file for this database.
(2) At the record level, R in position 17 specifies that CUSMST is the record format name of the record in this file. (There can only be one record format in a physical file.)
(3) At the field level, Rs in position 29 specify that the attributes of fields of the same name in the REF file are to be used as attributes of these fields.
(4) The fields SEARCH and CRDLMT are not defined in MLGREFP; therefore, their field attributes are specified here.