About DDS: Data Description Specifications
Welcome to the quirky and fascinating world of IBM i development. Today, we’re diving into one of the platform’s oldest yet still highly relevant technologies: DDS, or Data Description Specifications.
If you’ve ever been curious about how IBM i knows the structure of a file, the behavior of a display screen, or the layout of a printer form, DDS is the behind‑the‑scenes designer making it happen. Long before SQL DDL and modern UI tools came along, DDS was the go‑to method for defining data structures and user interfaces on the system. Even now, it’s still all over the place, quietly running decades’ worth of business logic.
Module Content
Welcome to the quirky and fascinating world of IBM i development. Today, we’re diving into one of the platform’s oldest yet still highly relevant technologies: DDS, or Data Description Specifications. If you’ve ever been curious about how IBM i knows the structure of a file, the behavior of a display screen, or the layout of a printer form, DDS is the behind‑the‑scenes designer making it happen. Long before SQL DDL and modern UI tools came along, DDS was the go‑to method for defining data structures and user interfaces on the system. Even now, it’s still all over the place, quietly running decades’ worth of business logic.
DDS serves as the blueprint language of the IBM i environment, unassuming and not modern, yet steadfast, reliable, and deeply embedded in thousands of production systems. Mastery of DDS provides valuable insight into the construction and maintenance of IBM i applications.
Here's a clean, skimmable DDS cheat sheet tailored for new IBM i programmers
In modern IBM i development, you have two distinct ways to define and manage database objects: DDS and SQL. Both are powerful and still widely used, but they serve different purposes. Knowing when to use each one is an important skill for any IBM i programmer. This lesson offers a straightforward, practical guide to help you choose the right tool for the task.
Welcome to one of the quirkiest yet oddly entertaining stops on your IBM i adventure. Today, we dive into ALLFILEF, the physical file that decided, “Why not show off *all* the DDS-supported field types in one fabulous data buffet?” If you’ve ever pondered, “What exotic creatures live in the DDS data type zoo?” or “How do packed, zoned, binary, float, date, time, and LOB fields strut their stuff in real DDS?” this is your backstage pass.
Welcome to the Swiss Army knife of SQL lessons! In this module, we dive into ALLTABLE.SQLFILE, a fully annotated table that struts around showing off every major SQL data type IBM i can handle. Curious how DB2 for i juggles characters, hoards binaries, nails numeric precision, or keeps timestamps on a tight leash? Not to mention its flair for LOBs, XML, arrays, identity columns, and that show-off generated fields, this table’s got it all, neatly dressed and ready for inspection.
To rename a field in an IBM i logical file, you use the DDS keyword RENAME at the field level. This lets the logical file present a different field name than the physical file, without changing the underlying PF.
Today we’re exploring one of the most handy and clever keywords in DDS Logical Files: SST (short for Substring). Think of SST as your “virtual scalpel,” allowing you to slice out parts of an existing field and present them as entirely new fields in a logical file without altering the physical file. It’s perfect for creating partial keys, splitting names, codes, or dates, and building cleaner views for programs and reports.