The ultimate benefit of encapsulation is rapid response, and this is how it works.

Over the last three articles (parts 1, 2, and 3), we've worked to encapsulate your extension files, but until now it's been work without a lot of clear benefit. That's the way it is with architecture sometimes; the foundational changes require a lot of work, but the benefits of the approach quickly outweigh the initial investment. This article presents the culmination of all that effort: the ability to change your extension files on the fly!

Remember, this technique is not a silver bullet; you can never make radical changes to your database without disrupting your business. And when you do, the amount of work required depends on the change. It's relatively easy to make a field larger, but it's much harder to change a field from numeric to alpha. We can review those issues in another article; today we're going to cover the most common case, adding a new field. This also happens to be the least disruptive; once you've applied the architecture in these articles, you can do it even while users are running applications (within reason).

Adding New Fields

In Part 3 of this series, we talked about how to define fields for SQL access. Since you're not using the implicit record definition that comes with a file specification (F-spec), you need to explicitly define the field yourself. Without rehashing the article, it depends on whether you're using ILE RPG or RPG/400, but either way you're going to define the field you need and then use a SET statement to pull that value in. Actually, you could also use a SELECT statement, but I'm really leaning more and more toward SET since it's just so similar to the EVAL statement or its equivalent in any modern high-level language. SELECT…INTO just has a different feel to me.

Anyway, remember that actually using the field comes second. First, you want to add the field to the database. I've developed a very simple set of steps that you can follow every time you need to add a new field. There are a couple of variants to this theme based on the following questions:

• Did you create the file with DDL or DDS?
• Are you going to using RLA (record-level access, also known as native I/O) to update the extension file in your maintenance program?

The first question isn't really a decision point; you've done it either one way or the other. All that it means is that there's a different technique for one of the steps in the process. The second question is important and is one you have to decide. If the maintenance program for the master file you are extending is already in ILE, then I highly recommend that you add the extension file access through SQL. It's not any harder, and it removes one complication in the process. But for the purposes of this exercise, I'm going to assume your master file maintenance program will use RLA.

The steps are simple:

• Allocate the extension file exclusively.
• Change the extension file.
• Recompile the maintenance program.
• Deallocate the physical file.

In a vanilla environment, this can be done without interrupting your users, provided your extension file isn't too large. The default lock wait time for files on the IBM i is 30 seconds, so that's how much time you have to get from step 1 to step 4 before you start getting lock failures. Now, if you have special processing for your files with shorter wait times or your extension file is particularly large, then you may have to adjust your process. Add a step 1A to temporarily change the file wait time for the file using the following command:

CHGPF FILE(CUSEXT) WAITFILE(300)

This will extend the wait time to five minutes (if it takes longer than that to change your extension file, you may need to resort to a more traditional technique of kicking people off the system).

Note that at this point, all you've done is add the field to the database. You haven't enabled it yet. But now that the new column is in the database, changing the application to use it becomes a more focused change-management problem involving only program objects, not database file changes.

Additional Nuances

There are a few additional tricks and techniques involved in these steps, starting with step 1. The whole purpose of this approach is to avoid locking the file. Since all your programs (with the possible exception of the maintenance program) access the file via SQL, you might be surprised when you attempt your ALCOBJ command and get an error that you can't allocate the file. That's because SQL leaves "pseudo locks" on the file in order to increase performance. The good news is that you can remove those pseudo locks with a keyword on the ALCOBJ command. So, to allocate the CUSEXT file we've been talking about, use the following command:

ALCOBJ OBJ((CUSEXT *FILE *EXCL)) WAIT(1) CONFLICT(*RQSRLS)

The CONFLICT(*RQSRLS) keyword will cause any pseudo locks to be released. Why WAIT(1) instead of WAIT(0)? Due to a vagary in the allocate logic when pseudo locks exist, even if the command successfully removes all the pseudo locks, it still reports an error. By using WAIT(1), it won't return that error. Now, if you've done your preparation correctly, the only time you will get an error is if the maintenance program has the file locked. At that point, you probably want to politely kick people out before proceeding.

In step 2, the technique depends on how you defined the file. For DDS-defined files just use the CHGPF command, specifying the updated source member. For DDL, I prefer to have a source member with an SQL statement using the CREATE OR REPLACE TABLE syntax, which works exactly like a CHGPF command.

Step 3 is straightforward, but it’s not required if the maintenance program is using SQL access. For a number of reasons, though, I prefer using RLA. The biggest reason is that the maintenance program actually requires a lock on the file. Because of that, the users are locked out of master file maintenance while I'm doing the update. It's not strictly necessary, so it's really a personal preference.

The last step, releasing the file, has no special requirements. In fact, the easiest way is to simply sign off your sessions when you're done. The file will be released and your users none the wiser! Using this technique, I am able to add a new column to a table in just a few minutes without disrupting the business, and that's really the whole point of the process!

Hopefully, this has given you a solid guide to follow when creating extension files. Please let me know in the comments if you have any questions!

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Joe Pluta available now on the MC Press Bookstore.

		Developing Web 2.0 Applications with EGL for IBM i Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform. List Price $39.95 Now On Sale
		WDSC: Step by Step Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction. List Price $74.95 Now On Sale
		Eclipse: Step by Step Quickly get up to speed and productivity using Eclipse. List Price $59.00 Now On Sale