Groundbreaking nuclear-geneticist Hermann Joseph Muller said, "Life is a whole ceaseless change. There is no sign of physical limit yet."

Bearing that in mind, it occurred to me that I should begin to test the limits of PowerBuilder 8, and see if I could disprove Muller. It seemed to me the easiest way to go about this heady undertaking was to convert our EMS natural gas trading and accounting application. It was written in PB 6.5 with the PFC and Transact-SQL for the motors behind the screens.

Last year in PBDJ (Vol. 7, issue 9), I did a case study of this application and our use of CAST to map the many objects in PowerBuilder and Sybase, and the use of CAST.

EMS has more than 600 PB objects, more than 1,700 stored procedures, 604 triggers, 179 views, and more than 400 tables. Migrating this application was not something that happened quickly, but PB 8 made this a somewhat painless transition.

It occurs to me as I begin to look at my beta version of PB 8 that I'm quite comfortable with PB 6.5 and not so sure that I want to move off it and into the unknown. PB 6.5 is solid, is marketed by Sybase as solid, and was designed as a developer's environment.

It also flew in the face of the old implementation theory, "Let the other guy work the bugs out." Instead of ducking, or waiting for the coming storm, I decided to plow ahead....

Starting the Migration
The first step in starting this migration was to move all of my pibbles and objects to one of my local drives. This is an important step in speeding up your migration. If you attempt to migrate from a network, it can take a lot of time and tie up a PC for a good while, creating unnecessary network traffic and tying up your development environment - slowing productivity and losing programmer time.

Doing the migration locally and then copying back to the network is a necessary first step. Then you'll need to establish your library list with the local directory as the starting point on this list. You can use the PowerBuilder editor or any text editor to make the changes.

Then open the application in PB 6.5 and paste in this new library list. That way when you go to make the transition to PB 8, it will look for the pibbles that you're going to migrate on your local drive. After you have pasted in the new lib list, save your application object, close PB 6.5, and get ready to start the fun.

Several EMS modules left me high and dry when I attempted to re-create or find my old lib list. One of the things you can do if you have an old app and have forgotten the lib list, or nobody has it, or it's just gone...you can export the Application Object to a folder, and then edit the SRA file after you save it on your hard drive.

That application object will have the library list in it as text. Copy and paste it into your word processor to assure yourself that you have truly gotten the best and most efficient code.

Another preliminary step is having the PowerBuilder stored procedures (pbsyc.sql and pbsyc2.sql) run on the server where you want to access databases. You won't be able to see the tables, procs, triggers, or anything else that you need for your nice smooth database connection without that being run. Our DBAs run them for me on the various database boxes and then I'm able to access the data from PowerBuilder, in this case from PB 8.

Creating a Workspace
Once you've done that, you'll have to create a Workspace. This PowerBuilder object gives you a means of grouping applications or targets. This will have a .PWB extension. The Workspace is new to PB 8 and it will give you a way of opening and deploying multiple targets at once.

There are two kinds of targets: Web and Powerscript. Both the Workspace and target concepts are aimed at the Web development environment. Targets are considered an excellent way of allowing you to "build, manage and deploy HTML, images and other resources needed for a Web site," to quote Sybase.

Select the Application
Once you have created a Workspace for your applications, select the application that controls the pibbles that you're going to migrate. This will bring up a list for the migration, and here is where PowerBuilder will stop you with the Migrate Application dialog box and tell you that the application you are opening was from an older version and must be migrated.

It will also give you the opportunity to browse for more pibbles if you have more that you need to add.

Make sure you connect to the database so that when PB starts regenerating the DataWindow objects, it will find the tables and columns in question. As you start the process, PowerBuilder will begin by naming your application object with a .PBT extension, making it into a target - which is the PB 8 way of saying application object. Then it will begin reading in the objects in the pibbles that you are moving, and regenerating and rebuilding them in PB 8.

Now You Can Edit
Now the system will allow you to edit your objects and work in PB 8. Another nice feature of the target was searching by target. It has always been frustrating to search by one pibble at a time, plunking your way through, so being able to search through a target gives you the ability to run through multiple pibbles in no time at all. Bravo, Sybase!

PowerBuilder uses the Migration Assistant to move through your pibbles, objects, and methods, then scans them, and moves them to the newer version. In the process it captures the errors, obsolete functions, and obsolete events - and then lists them so that you can fix them if necessary.

The Migration Assistant (see Figure 1) can also be used selectively to pick a single pibble or object to migrate. You can choose PFC or PowerScript and PB will check for obsolete functions or events and it will also go through the code for problems with reserved words. The display will show the obsolete code, and the pibble, object name, and line where it's found along with a suggested replacement. This all comes in for display in the Output window at the bottom of the screen (see Figure 2).

Capturing Errors
PowerBuilder has a nifty new way of capturing the errors that can come up as well. As it began to crash and burn, I got a message saying, essentially, "PowerBuilder is about to crash, do you want to capture the information?" If you get this, you can get a sys dump of sorts, and save it off to disk in a text file format.

This will be very helpful in tracking down some of those mysterious PowerBuilder system deaths that occur from time to time. This text file shows the registers active, the O/S version, the memory status, and what modules are loaded at the moment of pain.

I did get more than my fair share of obsolete objects or renamed ones in my information area of the Migration Assistant. I also had a good number of conflicts between instance variable names and exceptions. Sybase is still not killing these things off summarily, which is both wise and merciful on their part.

Someday dwDescribe may actually stop working, but for now, it just keeps rolling along. PowerBuilder also has several new-reserved words, and you'll have to change any variable names that conflict with these: TRY, CATCH, FINALLY, THROW, and THROWS.

After I generated all of my PBDs and executables, I had to make up new folders for the PB 8 runtime DLLs. While it's not something that we're likely to forget, it does pay to mention it after all. If you follow lists and patterns as I do, it pays to have every detail mentioned.

There are a number of objects now obsolete in PB 8, and some have moved to other places in PB. The release notes list these changes, and there are warnings as usual for obsolete objects that come with the migration. PB 8 has a few new concepts, but for the most part, the transition to this new system was straight ahead for a complex client/server environment.

Noticeable Improvement
The large number of objects involved only extended the time taken up by the transition between versions. The application is up and running, and seems to have gained a certain amount of speed between versions.

So far, all is well with PB 8 and EMS.

• Figure 1
• Figure 2