Lately, it seems that the DDS language has gone stale. The new data types and lengths are not being incorporated into DDS with any regularity. As we receive new user requests and begin designing their systems, the database design could suffer if DDS limitations are taken into consideration. But what else is there?
In a previous Midrange Developer article, I wrote of moving to SQL from DDS--from the programmer perspective. Today, I'd like to address this issue as it relates to management.
A well-known IBMer who retired only a few years ago once said, "SQL is too damn difficult to learn." This is one of my favorite quotes. He often spoke on database normalization. He also told me that originally IBM thought SQL could replace DDS for database definitions. A lot of efforts went into attempting to fit SQL into the AS/400 development culture, but those efforts didn't work well. Some inroads were made, but certainly nothing worth writing home about. DDS for physical and logical files was entrenched in our OS/400 lives and was not about to be displaced by SQL.
There are some very good features in DDS. For example, with DDS you can create a logical view with both a format and a key. In SQL, you can create a view and you can create an index: two different objects. There is no ability to combine them like you can with DDS. Why does SQL support logical views differently from DDS? Because SQL wants to both define and retrieve your data.
When using SQL to retrieve data, you can specify a key field with the ORDER BY clause. Here's how it works: When you attempt to retrieve data from a database with SQL, specifying an ORDER BY clause, if there is no SQL index built over the file using that field, SQL creates an index on the fly. This is very similar to what happens when OPNQRYF is used. Consequently, you don't need keyed logical views; you need indexes. If the index already exists, it uses the existing index, and that can certainly help performance.
What DDS lacks, however, is some of the new RPG IV data definition capabilities. For example, the integer data type is not supported; what is supported is the rather the outdated "B" data type. And 31-digit packed decimals are not supported. And DDS does not allow for long field names. Granted, I'm not a fan of 30-character field names, but sometimes it would be nice to create a field with a name that has a little more meaning to it. SQL supports all of these things.
Migrating to SQL can be easy as well. Simply use it to build your physical files (called "tables" in SQL) and logical files (called "views" in SQL). You can even retrieve SQL statements that were used to create a file or view, even if the file was created with DDS. Yes, you can extract SQL from a physical or logical file. Of course, this requires that an API be called, but it is not difficult.
I think my friend from IBM who said SQL is too damn hard to learn might have been mistaken. SQL is not hard to learn at all. What is difficult is using SQL in RPG, in COBOL, and certainly in CL. IBM's support for the so-called "embedded SQL" has been, in a word, nonexistent. The implementation of this support was never done correctly and has (as of this writing) never been enhanced. For example, you cannot use embedded SQL with local variables in RPG IV procedures, in free-format calculations, or with qualified data structures. So if you're an SQL fan, you need to limit your applications capability in order to use SQL. IBM needs to fix that, and it should have been done at least three years ago.
SQL is currently the only solution to the shortcomings in today's DDS. DDS is stable, reliable, and proven, and quite frankly, I love DDS. But in order to leverage contemporary database features in your applications, you need to consider migrating new application database design to SQL.
Bob Cozzi is a programmer/consultant, writer/author, and software developer. His popular RPG xTools add-on subprocedure library for RPG IV is fast becoming a standard with RPG developers. His book The Modern RPG Language has been the most widely used RPG programming book for more than a decade. He, along with others, speaks at and produces the highly popular RPG World conference for RPG programmers.
MC Press books written by Robert Cozzi available now on the MC Press Bookstore.
 |
||
 |
|
RPG TnT Get this jam-packed resource of quick, easy-to-implement RPG tips! List Price $65.00 Now On Sale
|
|
||
 |
|
The Modern RPG IV Language Cozzi on everything RPG! What more could you want? List Price $99.95
Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online