If you are just getting started with IBM i systems or you need a solid refresher on how the database really works under the hood, you have landed in the right place. Today we are going to walk through the complete hierarchy of IBM i data structures in a clear, step by step way. We will cover libraries, physical files, members, record formats and fields, and exactly how they all fit together. This is the foundation that every IBM i programmer and administrator builds on every single day.
I pulled together some slides that make this easy to follow (they are attached to this post). The powerpoint presentation includes simple diagrams, robot tips, and real world examples. Feel free to download the full deck and keep it handy while you read.
The IBM i Database Hierarchy
Everything on IBM i starts at the top and builds downward in a neat, logical stack. Here is the complete picture:
- Library
- File
- Member
- Record Format
- Fields
Think of it like this:
- 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 get this structure, every command, every DDS source, and every file reference suddenly makes perfect sense.
Libraries: Your Organizational Hub
A library (object type *LIB) is simply a container that holds related files, programs, commands, and other IBM i objects. It keeps your system tidy and makes life easier when you need to manage groups of objects together.
Key points about libraries:
- They act as the top level container.
- You can add libraries to your job’s library list (LIBL) so programs and users can find objects without typing the full qualified name.
- Security can be controlled at the library level if you want to lock things down.
Common commands you will use every day:
- CRTLIB create a brand new library
- DSPLIB see what is inside a library
- ADDLIBLE add a library to your current library list
- RMVLIBLE remove it again
Robot Nick says: Libraries are like labeled boxes. They keep everything tidy.
Physical Files and Members: Where the Actual Data Lives
Now we drop down one level into the files themselves.
A physical file (PF) is the real data container that sits on disk. It stores the actual records you work with, whether that is customer details, transaction history, or inventory levels.
Important facts about physical files:
- Each PF holds real data records.
- It has exactly one record format that defines the layout.
- It can contain up to 32,767 members.
- There is also a special type called a flat file (just one long field with no structure) that is perfect for temporary work or data transfers. Example command: CRTPF FILE(LIB/FLAT) RCDLEN(100)
Members are the clever part. A member is a separate dataset inside the same physical file. All members share the exact same record format, but they can hold completely different sets of data. This gives you a clean way to split information without creating dozens of separate files.
Typical use cases for members:
- Monthly sales data (JAN2024, FEB2024, MAR2024 inside the same SALES file)
- Departmental data
- Archive versus current data
Handy member commands:
- CRTPF (when you create the file you can add the first member)
- ADDPFM add another member later
- RMVM remove a member
- DSPFD display file description to see all members
Robot example: A SALES file might have members JAN2024, FEB2024, MAR2024. Same structure, different monthly data.
Record Formats and Fields: The Blueprint and Building Blocks
Inside every physical file (and every member) sits the record format. This is the named blueprint that tells the system exactly what each record looks like.
A record format:
- 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).
Here is a quick DDS example straight from the slides:
A R CUSTREC
A CUSTID 10A
A NAME 30A
A CITY 20A
A K CUSTIDR marks the record format name, the lines below are the field definitions, and K identifies the key field.
Fields are the individual data elements (the columns) inside each record. Every field has clear attributes:
- Field name (up to 10 characters)
- Length
- Data type (A for alpha, P for packed, S for zoned, B for binary, and so on)
- Decimal positions (for numeric fields)
Key facts you should remember:
- 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 use a field reference file (FRF) so definitions stay consistent everywhere
Robot wisdom: Think of a record format as a form template, and fields as the blank boxes you fill in.
Putting It All Together – The Relationship
So here is the complete relationship in plain English:
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. Once you see it this way, debugging file issues, writing RPG programs, or designing new applications becomes much simpler. You always know exactly where to look.
The attached slides include some nice visuals that show the hierarchy diagram, the robot tips, and the example layouts. They are worth keeping open while you experiment on your own system.
Summary : Key Takeaways
Here is the quick recap:
- 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
Remember the hierarchy and you will never get lost in IBM i data again.
If you have questions or want to see a follow up post on logical files, SQL versus native access, or field reference files, just drop a comment below. Happy coding on IBM i!
(And yes, the full powerpoint slide deck is attached for easy reference.)
