1

I've been trying to do a spec for a PowerBuilder 9 to 11.5 migration of a relatively complex application. Granted PowerBuilder is not really my specialty I'm having issues trying to justify an estimate for this part of the project (and the PowerBuilder people I've been talking with have had some personal issues lately and are out of communication). These are some of the metrics that we have seen and can evaluate:

-PBL Files
-Main Windows
-Data Windows
-Functions

(no we don't have the source available on this project)

What metrics in particular are helpful and how long would any given "unit" such as a Data Window take?

tekiegreg
  • 1,667
  • 6
  • 25
  • 41
  • Don't know much about PB 9, but one of the reasons we just replaced our last PB 5 application by a so-much-better .NET program was that the hole thing was a binary BLURB where we don't had any access to the code on the text level. So, version control did not work very well, global searches did not work well, and code-metrics??? Yes, you got it, they did not work very well, too. – Doc Brown Mar 24 '10 at 21:08

2 Answers2

5

Most PowerBuilder migrations are rather smooth. The biggest thing that might get you moving from 9.0 to 11.5 are (a) the change in the Rich Text Edit control (if used) and (b) Unicode versus ANSI. The later will primarily be an issue if you have external function calls that pass strings, and only require the addition of a ;ANSI suffix or a migration to the Unicode version of the call.

So, look to see if the Rich Text Edit control is used, and look to see how many external function calls are declared. If you don't have any of either, it would be as simple as opening the project up in 11.5 (after making a backup of course) and allowing 11.5 to do the migration.

Bruce Armstrong
  • 613
  • 3
  • 7
  • 1
    I'd agree with the two categories. PB migration will add the ";ANSI" qualifier to any external function calls that have string parameters. I'd look for any external functions that have byte arrays or blobs that someone is trying to stuff a string into; stuffing a Unicode string into it instead of an ANSI string may cause problems. (PBL Peeper can get you the list of ext fns.) As for metrics, I don't think any code based metrics matter; the migration is automated. The vast majority of the effort is testing, so you want to know the quantity of function points in the UI of the app. – Terry Mar 25 '10 at 00:43
  • 2
    Another thing to consider if it's a PFC application is whether you will fix-up and continue to use the migrated PFC or move to a version built for 11.5. If there's no mid-tier and there are customizations to the PFC, you may want to keep the old PFC. – Hugh Brackett Mar 25 '10 at 14:59
  • Good answer Bruce. The only thing I'd add is to allow plenty of testing time. The migrations usually go very smooth, I'd bet you'll get it done the first day. The ANSI issue mentioned by Terry got me on one migrate. Finding the quirks that occur however take a lot of testing. – Rich Bianco Nov 29 '10 at 01:41
0

Its been a while, and I don't remember the specifics, but our upgrade from 9 to 11.5 went very smoothly.

FauxReal
  • 4,762
  • 4
  • 21
  • 18