25 April 2018
Development, Appeon, Engagement Profiles
Intertech Consulting was retained by the United States Coast Guard in September of 2015 to help with the migration of their procurement systems. The USCG applications consist of one main application and several batch programs that process data sent via email from other systems. The applications were all written in PowerBuilder 5.0 and used the PFC object framework. The overall project was to migrate the applications to the latest version, PowerBuilder 12.6.
Although the primary scope of the project was that the systems were written in PowerBuilder 5.0, they were running on an old XP Server and were no longer in compliance with the mandates that had been passed down by the USCG IT. The development environment had to be actively supported. In order to reach compliance Intertech had to migrate all the applications from PowerBuilder 5.0, to PowerBuilder 12.6, and move other production code to their new server.
Sounds simple enough. Little did we know that getting from A to Z was not as simple as one would think. And until we stepped through the doors at the USCG, we didn't realize what obstacles were going to hinder us during the migration process.
When we walked in the door, we were debriefed by the head of the development team. All of the accounting applications had been handled by an outside firm with security clearance to work on their systems outside of the office 20 years ago. Without going into detail, there was a protracted legal battle that ensued between this firm and the USCG over the simple ownership of the code. At the end of the day the ruling came down that the USCG owned the code. The USCG was not even sure if they received all the PBL’s from that firm. They thought they had, but they couldn’t be sure.
When we went to gather the PBL’s up for the first application, we first went and got the library list from the PB.INI file that resided in the PowerBuilder 5 development PC. In the process of gathering up the PBL’s, we found that there were individual directories that had the PBL’s for some of the applications, but it always seemed like they were missing core PBL’s. At this point we noticed that there was a common/bin directory that had been set up to hold what we guessed were common PBL’s/PBD’s.
As we attempted to migrate the first application we immediately were greeted by a litany of errors warning us of missing objects. This is where we hit the next major road block. A library path existed for this particular application in the PowerBuilder 5 environment, yet, we could not do a full build of the application in the PowerBuilder 5 environment or the PowerBuilder 12.6 environment because of a multitude of missing object messages. What we found out was that the only thing that had been done for 20 years were small incremental builds. only building individual PBDs with small changes to the code. This allowed these missing objects messages to stay hidden from their internal development staff for years.
The only thing we could do was to start looking through the code that was available in PowerBuilder 5.0 and start looking for references to the missing objects that were causing the missing objects message. Slowly we started to find the missing objects/properties/variables, etc. Piece by piece, we started to slowly pull the correct PBL’s, or in some cases, just identify missing objects, that needed to be imported into the PBL’s that were already in place in the application we were attempting to migration to PB 12.6.
Once we finally got the application successfully migrated, we knew we had hit a milestone that would allow us to take what we had learned and continue to migrate the other applications at a faster clip. However, before we did that, we knew we were going to have to upgrade the PFC that was in use in all their applications because we were making such a large jump in versions of PowerBuilder. Because the PFC had been opened sourced under the GNU license we found the absolute latest “Stable/Non Beta” version of the PFC. Once we had that downloaded, we opened that copy of the PFC/PFE using the PFC application object, and migrated it to PowerBuilder 12.6 as well.
At this point, we knew there could be the possibility that there would be custom code in the old PFE layer from the PowerBuilder 5.0 environment. So we started going through the objects in the PFE layer, and looked for code that had been put in place by the previous firm. And it’s a good thing because there ended up being about 20 objects in the PFE layer that had code that was placed into the PFE. Once we had those, all we had to do was export the needed objects from the PFE. Once we knew we were not going to step on any code, we replaced the PFC and PFE PBL’s in the migrated application, and update the library list to include the two additional new PFC Objects. Once we had the new PFC and PFE layers in place, we imported the code that we exported out of the old PFE layer into the new PFE layer.
With the new PFC/PFE layer in place, we went ahead and did another full build on the initial application that we migrated. Once that was completed, we ran into an issue that stemmed from there being global variables that had been created in the initial code that was migrated, that conflicted with new variables that were named exactly the same that came over in the new version of the PFC. Once again, this was another one of those areas that we thought was going to create a big problem for us. However, after doing an impact analysis of the migrated application, we determined that the global variables that had been created were orphaned, so we were able to remove them without any issues being caused in the process.
One thing we did find that was interesting within the PFC/PFE changes, we determined there were quite a few areas within the code that had hooks into the old PFC_Printdlg object. That was something that was specifically removed from the PFC back in PowerBuilder 7, because the PFC team found it was not the best way to handle the printing mechanism. It still worked, but it was just removed from future versions of the PFC. Because of this, we had to wire about 6 additional objects that had been removed back into the PFC, in order to keep from having to modify large amounts of the migrated application (or any of their other applications for that matter). In fact, once we completed wiring all these changes into the PFC, we made a copy of it so it could be reused within each migration that was completed.
At this point we believed we had successfully migrated and tested the first application and started to go down the list of applications that needed to be migrated into PowerBuilder 12.6. During this time the QA department built a development server so they could start testing each application to make sure they functioned correctly. As we started getting into each application, we were able to determine fairly quickly that the changes that had been made to the PFE in the first application we migrated were identical in each of the other applications. So we got to the point that all we had to do was copy of a set of the PFC and PFE objects over to the migrated code, and we were ready to work with that snapshot of the PFC in the newly migrated code.
As we continued through the migration of each application we resolved a series of show stoppers. Three of the applications to be migrated had no library list available in the PB.INI file. Luckily there are other ways of obtaining the library list, so we were able to go that route to get the library list. From there we were able to continue down the road of the migrations.
A couple of the major issues we ran into during the migrations came from the following. These applications were originally for 32bit PCs running anything from Windows 95 up to Windows XP. Back then, a 32bit application could easily write to HKEY_LOCAL_MACHINE hive. But unless we were deploying a 64bit application (which we were not), a 32bit application cannot write to the HKEY_LOCAL_MACHINE hive from a 32bit application. At the point that a 32bit PowerBuilder application attempts to write to the HKEY_LOCAL_MACHINE hive on a 64bit machine, the WOW3264 subsystem kicks in and places what’s being written to the HKEY_LOCAL_MACHINE hive to a node off the HKEY_CURRENT_USER hive.
The move from PowerBuilder 5 to 12.6 is a jump of 11 versions released over a 20 year period. Not surprisingly, Sybase tightened compiler edits over time. The second major issue we ran into stemmed from Sybase tightening up the compiler as each new version of PowerBuilder came out past version 5. This included not allowing users to break object oriented rules that the compiler allowed to slip through in the past. For example, we ran into a particular function call that was attempting to pass a menu object by reference. However, because the class that was selected as the data type being passed didn’t match the inheritance of the data type, and it actually worked under PowerBuilder 5.0 but silently fail in PowerBuilder 12.6.
Intertech found that there were a large number of SetItem() function calls where the column didn’t exist in the DataWindow. PowerBuilder 5 just ignored the error but this causes a runtime error in 12.6. Intertech had to determine what the columns were and whether it was really needed. In most cases the columns were added to the DataWindow.
There were a number of issues with the batch programs that read emails. When SAP released 12.6, they failed to mention that the built-in email feature had been changed from MAPI to Extended MAPI. The mail functions weren’t always working as expected. For example, the return from the mailGetMessages function was always mailReturnFailure!, even when it had actually received emails. Intertech had to remove the error checking in this case.
Granted, while working the project was challenging, working with the developers at the US Coast Guard was an extremely enjoyable aspect. There were developers there with diverse backgrounds that were very easy to work with. One had worked with NASA for some time before he came to work with the USCG. Intertech looks forward to continuing to work with them in the future!