It’s time to talk about database modernization methodology. Because each scenario is a little (or a lot) different from the others, you’ll have to adapt these steps to your particular situation.

Most database modernization scenarios have a few things in common, which allows you to follow the three-step methodology presented in this section, with a few tweaks. This methodology is just a set of tasks and guidelines that you’ll need to adapt to your particular scenario.

Keep in mind that nothing is written in stone, and your knowledge of your particular context is of paramount importance to a successful modernization process. It’s important that you understand each step and adapt it to your needs. Although there are only three steps, they are complex and require detailed explanation. This means that the discussion of this methodological approach will span over several articles, so bear with me while I explain each step with enough detail for you to understand its core and adapt it to your application’s context.

You might find that you can safely skip one or more of them, while the others are mandatory to reap the benefits of the modernization process. Also keep in mind that you’ll be repeating these steps quite a few times, because you shouldn’t try to modernize the whole database at once. Start with the files that support the most important functionalities of the application. Once you’re done with those, repeat the process with the next group of files, and so on until you’re done.

These are the three steps:

1. Convert the DDS files to DDL objects.
2. Move business rules to the database.
3. Take advantage of DB2’s advanced functionalities.

The general idea is that you’ll gain a lot with these changes, in terms of performance, database user-friendliness, and flexibility. It’s not an easy path, and some steps may sound a bit weird (yes, I can imagine what you’re thinking about step two), but it’ll make sense in a while. Bear with me, and I’ll explain it all in greater depth over the next pages.

Let’s start with the first step, which seems self-explanatory…but it’s not.

Step One: Convert DDS Files to DDL Objects

Before converting your database from DDS to DDL, you really should take the time to understand, document, and analyze it. Even though you think you know your database, there will be some surprises (more on this next), and you need all the information you can get from your database before you move on.

This will be a time-consuming process, but it will pay off later. The result of this “detective work” will serve as the basis for the rest of the modernization process. In order to tackle such a complex and important step, you need to establish some sort of working process. Let’s go over a possible approach to this working process, which you should repeat for each library of your application that contains files.

Discover and List Existing Files

Depending on the application’s age, the process of discovering and listing existing files can be easy or extremely time-consuming. Older applications will require greater efforts. For instance, your application’s database might still contain program-described files (remember them from the old days?) that you’ll need to map into your database model. Don’t worry too much about them right now—just document their existence and move on.

Besides these ancient files, you might have some other peculiarities in your environment, which you’ll need to document. These oddities might include the following:

• “Ghost files”—These are empty shells. They only exist to be used as a base for a temporary file in QTEMP for a program to store data while it’s running.
• Output-only physical files—These are usually printout-turned-into-file-to-be-exported-to-PC-format files. They are somewhat similar to the previous ones, but they retain their content (the output of a certain program) after the program ends, even though their data has no direct relationship to the rest of the database.
• Logical files with selections—These files, which are often used as a way to speed up a program’s execution, might present a challenge later in the process, so be sure to locate all of them.
• Other oddities—Here’s where the knowledge of your specific environment comes in. You or someone on your team should have an idea of what other unusual stuff you have in your database. List everything, even if it doesn’t sound important.

Once you have listed all the files and what they’re used for, you’re ready to move forward.

Figure Out and Map Implicit Relationships Between Files

Again, this depends on the application’s age. I’d say that the probability of the relationships between the files not being in the database itself, but in the programs that maintain the data, increases with the age of the application’s database. It’s true that you can enforce referential integrity via logical files based on more than one physical file, but this is seldom used. You’ll need to map all of those relationships thoroughly because that will help you change your programs later, freeing them of the referential integrity tasks that they perform now.

That’s something to do later. For now, the idea is to convert the DDS files to DDL objects, and nothing else. This too will be a time-consuming and tedious task, but you can make it slightly less boring by drafting your Entity Relationship Diagram at the same time, which will be the topic for the next TechTip.

Stay on Course

At this point, you might be tempted to start drawing your existing database’s physical model, using IBM Data Studio, which I mentioned in the previous TechTip, for instance. Don’t do it! Legacy application databases are often a collection of seemly unrelated flat files, connecting to each other via the RPG programs that use them. There’s so much duplication, garbage, and outdated stuff that you’ll be wasting your precious time drawing a diagram. At this moment, concentrate on what you have to do to modernize other aspects of the database. As I mentioned before, next time around I’ll explain how you can start preparing to organize your database, by defining or refining the definition of a few things so that you can finally implement step 1 of the methodology: convert your files from DDS to DDL.

Rafael Victória-Pereira has more than 20 years of IBM i experience as a programmer, analyst, and manager. Over that period, he has been an active voice in the IBM i community, encouraging and helping programmers transition to ILE and free-format RPG. Rafael has written more than 100 technical articles about topics ranging from interfaces (the topic for his first book, Flexible Input, Dazzling Output with IBM i) to modern RPG and SQL in his popular RPG Academy and SQL 101 series on mcpressonline.com and in his books Evolve Your RPG Coding and SQL for IBM i: A Database Modernization Guide. Rafael writes in an easy-to-read, practical style that is highly popular with his audience of IBM technology professionals.

Rafael is the Deputy IT Director - Infrastructures and Services at the Luis Simões Group in Portugal. His areas of expertise include programming in the IBM i native languages (RPG, CL, and DB2 SQL) and in "modern" programming languages, such as Java, C#, and Python, as well as project management and consultancy.

---

MC Press books written by Rafael Victória-Pereira available now on the MC Press Bookstore.

		Evolve Your RPG Coding: Move from OPM to ILE...and Beyond Transition to modern RPG programming with this step-by-step guide through ILE and free-format RPG, SQL, and modernization techniques. List Price $79.95 Now On Sale
		Flexible Input, Dazzling Output with IBM i Uncover easier, more flexible ways to get data into your system, plus some methods for exporting and presenting the vital business data it contains. List Price $79.95 Now On Sale
		SQL for IBM i: A Database Modernization Guide Learn how to use SQL’s capabilities to modernize and enhance your IBM i database. List Price $79.95 Now On Sale

Also Read

Programming in ILE RPG - Defining Data Structures, Part I

H and F Position-less Specs

Practical RPG: AI and IBM i