It’s time to get your hands dirty and actually begin the database modernization process. Learn how to start and manage the physical-file-to-table conversion process in this TechTip.
The previous two TechTips discussed the organizational aspects of the database modernization process. It’s now time to start converting your old-school, DDS-defined physical files to “modern” and better-performing DDL tables.
Converting DDS to DDL
Some tools, like AO Foundation (which I mentioned a couple of TechTips back) enable you to automate the task of converting DDS to DDL. However, you can (and, in my opinion, should) know how to convert the files manually. It’s actually a simple process:
- Open IBM i Navigator.
- Go to the Databases node in the left section of the screen and select your database.
- Select Schemas and choose the library where the file resides.
- Find the file you want to convert, right-click it, and choose Generate SQL.
The Run SQL Scripts tool will pop up, and show you a CREATE TABLE or CREATE VIEW statement, depending on the type of file you selected. This statement should be a fairly accurate approximation of the DDS defined file. In most cases, it will be an exact match. However, because some DDS keywords don’t have an SQL equivalent, you might not always get what you want. Table 1 lists these keywords.
|
Table 1: DDS Keywords Ignored During SQL Generation |
|
|
File Type |
Keyword |
|
Both Physical and Logical Files |
ALTSEQ, FCFO, FIFO, LIFO, CHECK, CHMSGID, CMP, DATFMT, DIGIT, EDTCDE, EDTWRD, TIMFMT, RANGE, REFSHIFT, UNSIGNED, VALUES, and ZONE |
|
Logical Files |
CCSID or TRNTBL |
|
Join Logical Files |
JDFTVAL or JDUPSEQ |
Keep in mind that, depending of the IBM i Access software version that you’re using, these steps may vary a little. Once you find and run the Generate SQL option, carefully review the results, and adjust as necessary. Some situations might require changes in your programs, while for others you might find an “SQL way” of solving the problem. Before you run the statement and generate the SQL object, be sure to change the library name. You might want to change the SQL object name to something longer and more descriptive, as discussed in the previous TechTip. Keep in mind that you need to maintain compatibility with the programs that use the “old” file.
If the DDS object to convert is a physical file, there are a few additional tasks to perform. If you’re not familiar with the CREATE TABLE SQL statement syntax, it might be a good idea to review it at this time. Also, because SQL is not constrained by the operating system 10-character limit, consider using longer, more descriptive names for each column, followed by the FOR COLUMN expression, after which you’ll place the DDS name of the column. Finally, add the RCDFMT keyword with the DDS record format name to ensure your RPG programs are still able to use the table/file as they did before.
Logical files present different challenges. If the logical file you’re converting has a key, you’ll need to create an SQL index with that key and create a view with the selected columns. There are some limitations to this process, however. Multi-member files cannot be converted directly, for instance, because SQL can’t handle them. You’ll need multiple tables to store the information. If you want to convert such a file, you need to get creative and figure out a way to migrate the data from the original physical file to new SQL tables and, for example, create a stored procedure that automatically accesses the right one.
Finally, you can select a file name and location to save the SQL script. Always remember to save scripts before running them, because sometimes the execution ends in errors or freezes, and you might lose unsaved work. Try this for a couple of physical files and their dependent logical file. Ideally, choose files that are not used in many programs and do a proof of concept (PoC), just to get the hang of it and start hammering out possible inconsistencies in your process. Note that this is a high-level description of the whole DDS-to-DDL conversion process. To get a more technical-level description, please refer to the vast literature on this topic and, naturally, the experience and guidance of your modernization consultant.
Once you’re happy with the conversion and have performed all the necessary program adjustments and recompilations, you’ll be ready to move to the next stage. By now, you should notice an interesting performance gain. This results, among other things, from the larger page size of SQL indexes (64 Kb) compared to the native access paths (8 Kb) used by logical files.
Here’s where things start to get really interesting. You’re now ready to squeeze some more performance from your database and modernize it at the same time. This should be enough to keep you busy until the next TechTip of this series, which will be about the second step of “tidying up” your database: normalization.
Coming Up
In the first article of this Database Modernization subseries, I explained the theory behind the whole normalization theory. Next time around, I’ll show you how to methodically approach the subject. Until then, comment, correct, or suggest a topic in the Comments section below.
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