IBM i Database Basics - Library File Member Record Format Field

Welcome to your first hands-on lesson on IBM i database fundamentals. If you are new to IBM i programming or just need a rock-solid refresher, this lesson will walk you through the complete data hierarchy step by step. By the end you will know exactly how libraries, physical files, members, record formats and fields relate to each other and why that structure matters every time you write RPG code, create DDS or run a query.

I have attached the original slide deck (IBM-i Database Basics.pptx) so you can follow along with the diagrams, robot tips and examples while you read. Keep it open on your second screen and pause whenever you want to try something live on your own system.

What You Will Learn

• The five-level IBM i database hierarchy and how each level builds on the one above it
• What a library really does and why you use a library list
• How physical files store data and why members make life easier
• The role of record formats and fields as the actual blueprint and building blocks
• Real commands you can run today plus a simple mental model that sticks

Ready? Lets dive in.

The IBM i Database Hierarchy

IBM i organizes data in a clear, top-down stack. Here is the complete picture you need to memorize:

1. Library
2. File
3. Member
4. Record Format
5. Fields

Simple analogy that works every time:

• Library = filing cabinet
• File = folder in the cabinet
• Member = section inside the folder
• Record Format = form template
• Fields = individual boxes you fill in on the form

Each level sits inside the one above it. Once you see the relationship this way, every file reference in your RPG programs and every DDS line suddenly makes perfect sense.

Level 1: Libraries - Your Organizational Hub

A library (object type *LIB) is the top-level container that holds related files, programs, commands and other IBM i objects. It keeps your system organized so you are not hunting through thousands of objects every day.

Key points to remember:

• Libraries act as the container for everything.
• Add them to your job library list (LIBL) and programs can find objects without you typing the full qualified name every time.
• You can set security at the library level if you need to lock down access.

Commands you will use constantly:

• CRTLIB - create a new library
• DSPLIB - display everything inside a library
• ADDLIBLE - add a library to your current library list
• RMVLIBLE - remove it when you are done

Robot tip: Libraries are like labeled boxes. They keep everything tidy.

Level 2: Physical Files and Members - Where the Actual Data Lives

Drop down one level and you reach the physical file (PF). This is the real data container that lives on disk and holds the actual records you work with every day.

Important facts:

• A PF stores the real data records (customers, transactions, inventory, whatever).
• Every PF has exactly one record format that defines its layout.
• A single PF can hold up to 32,767 members.
• Flat files are a special type of PF with just one long field and no structure. Perfect for temporary work or data transfers. Example command: CRTPF FILE(LIB/FLAT) RCDLEN(100)

Now for members. A member is a separate dataset inside the same physical file. All members share the identical record format but can contain completely different data. This gives you a clean way to split information without creating dozens of separate files.

Typical real-world use:

• Monthly data (JAN2024, FEB2024, MAR2024 inside the same SALES file)
• Departmental splits
• Archive versus current data

Handy commands for members:

• CRTPF (creates the file and its first member in one go)
• ADDPFM - add another member later
• RMVM - remove a member you no longer need
• DSPFD - display file description to see every member

Robot example: A SALES file might have members JAN2024, FEB2024, MAR2024. Same structure, different monthly data.

Level 3: Record Formats and Fields - The Blueprint and Building Blocks

Inside every member you find the record format. This is the named blueprint that tells the system exactly what each record looks like.

What a record format does:

• Defines which fields are included and in what order.
• Is created with Data Description Specifications (DDS).
• Is limited to one per physical file (logical files can have up to 32).

Quick DDS example you can type yourself:

text

A R CUSTREC
A CUSTID 10A
A NAME 30A
A CITY 20A
A K CUSTID

R marks the record format name, the lines below define the fields, and K identifies the key field.

Fields are the individual data elements inside each record. Every field carries its own clear attributes:

• Field name (maximum 10 characters)
• Length
• Data type (A for alpha, P for packed decimal, S for zoned, B for binary, and so on)
• Decimal positions (for numeric fields)

Key facts:

• Up to 8,000 fields per record format
• Up to 120 key fields per file
• Field names can be reused across different files
• Best practice is to build a field reference file (FRF) so every definition stays consistent system-wide

Robot wisdom: Think of a record format as a form template, and fields as the blank boxes you fill in.

Putting the Relationship Together

Here is the complete flow you need to picture every time you touch data on IBM i:

A library holds one or more physical files. Each physical file contains one or more members. Every member stores records that follow a single record format. That record format is built from a collection of fields.

Library → File → Member → Record Format → Fields

Five clear levels of organization. When you understand this hierarchy, debugging file problems, writing RPG programs or designing new applications becomes straightforward because you always know exactly where to look.

The attached slides show the hierarchy diagram, robot tips and example layouts in a nice visual format. Open them now and trace the levels while you read.

Lesson Summary - Key Takeaways

• Library organizes everything
• File stores the actual data records
• Member separates different datasets inside the same file
• Record Format defines the structure of those records
• Fields hold the individual pieces of data

You now have the complete mental model of IBM i database structure.

Practice Time

1. Create an account on PUB400 
2. Create a test library called MYLIB with CRTLIB.
3. Create a simple physical file with two members (use CRTPF and ADDPFM).
4. Write a tiny DDS source member, compile it, then use DSPFD to explore the record format and fields.
5. Try adding a member called TEST2026 and see the hierarchy in action with DSPLIB and DSPFD.

Happy coding on IBM i. See you in the next lesson.