The Output Log
PowerGen displays detailed output in a scrollable window, while the operation is running.

The log shows information about the environment (versions), the application being processed, and then about every detail of the build. Details can be customized to add or subtract information. The logs are sufficiently complete to meet all audit and compliance requirements.

Any error, either in configuration or in a particular operation, is written in a red font and summarized at the end of the log. This diagnostic information is especially important when configuring a build for the first time. At the same time that the GUI is presenting PowerGen's output, a log file is written with the same information. There are many options as to how and where this log is written. For example, PowerGen can generate a name for the file that corresponds to the starting time and date of the operation.

Bootstrap Import
PowerGen first introduced the Bootstrap Import for PB V5.0. Its purpose is to rebuild an application completely from just the exported object syntax (*.sr* files). So PowerGen enabled source traceability in our SCM processes long before it was possible with PB. Later this became a critical issue for PB8.0 when PB's source control architecture changed and there were no longer "registered" PBLs to use for a build. As soon as PowerGen offered the Bootstrap Import we chose to use it rather than rely on the registered PBLs, because it wasn't possible to verify the contents of those PBLs.

PowerGen's Bootstrap Import uses a three-phase import process. In the first phase global types and basic object signatures are established. In the later phases the complete object information is added back in. This progressive import is required to avoid fatal errors caused by a fully formed object that may contain many references to objects that haven't been imported. The finesse required to import selected parts of an object in successive phases requires an automated method. Attempting to do it by importing complete objects (which we tried), even in a carefully selected order, is futile.

Because PowerGen introduced the Bootstrap Import in an early version of PB, it has had to deal with several interesting issues. Until PB8.0 was released there was no information available about which objects belonged in which PBLs. Obviously this was essential information for rebuilding PBLs from object sources. So PowerGen introduced the Object List File (OLF) that provided the mapping between object files and PBLs. There are two forms of the OLF. In one all of the objects are enumerated along with their corresponding PBL:

.\Code Examples\Example App\pbexbm\benchmark.sra,.\Code Examples\Example App\pbexbm.pbl,"Comment"
.\Code Examples\Example App\pbexbm\d_benchmark_report.srd,.\Code Examples\Example App\pbexbm.pbl
.\Code Examples\Example App\pbexbm\d_dddw_cust.srd,.\Code Examples\Example App\pbexbm.pbl
Etc.

In this form each line contains two-four comma-separated parameters. The first names the object file, the second the PBL, and the optional third and fourth the object comments and PBL comments respectively.

In the second form the object file names can include a wild card:

.\Code Examples\Example App\pbexbm\*.sr?,.\Code Examples\Example App\pbexbm.pbl,"Comment"

In this form every file with an *.sr* form in the pbexbm subdirectory will be included in the PBL.

OLF's (and PBGs) can be created automatically by PowerGen, with many options to specify directory configurations for the source files, which form to use, whether or not to include comments, etc.

We've organized our source control repository to have a separate folder for the sets of objects for each PBL. This lets us use the OLF wild card form and not worry about whether an enumerated list is accurate. In other words, we're letting the source control structure dictate the PBL configuration. I think it's a better SCM practice than relying on a list that has to be maintained outside of the source control system. Even PB's PBG file, introduced in PB8, which provides the mapping function, is prone to be inaccurate.

Another issue arose from supporting older versions of PB. In versions of PB before V7.0 the "headers" of object source files, those lines beginning with $PBHeader and $PBComments, were removed from the source file when it was added to the source control. That meant that the comments were lost and that the object name and type had to be determined from the PBScript syntax rather than the header information. Comments are saved in the OLF files as optional parameters.

PowerGen versus ORCAScript
We've examined the use of ORCAScript for our build automation. ORCAScript is a command line-only utility that started shipping with PB 9.0 for automating build procedures.

We quickly decided to stick with PowerGen for several reasons.

We have a fully automated process, based on PowerGen, that operates flawlessly. And the process hasn't required any changes through all the versions of PB and PowerGen that we've used. As the adage goes, don't fix what isn't broken.

ORCAScript is only available for PB 9.0 and later. We need support for earlier versions.

ORCAScript doesn't provide enough detail in its output to diagnose build or configuration problems easily. Many of its error messages are difficult to interpret.

We've experienced cases where ORCAScript couldn't complete a build successfully (and PowerGen could).

ORCAScript is a command line-only interface. We find it far more productive, using PowerGen, to have a GUI that we can use to prototype our build procedures and then easily translate to a script.

Our Experience
We develop and maintain 40 PowerBuilder applications at New Hampshire's Department of Health and Human Services. The applications are used extensively in our welfare and health services delivery agencies. Example applications are for child-care licensing and managing adult and elderly care. Throughout the state the applications are used by hundreds of users.

Using PowerGen we have defined a process that includes a full Bootstrap Import and build whenever an application version is promoted to system integration testing and user acceptance testing. We use AllFusion Harvest from CA for our software configuration management tool and have versioned our PowerBuilder applications at the object level since we adopted PowerGen. When we're ready to release a version to test we "get" the labeled objects from Harvest and then run PowerGen scripts that completely automate the import and build process.

We've been using PowerGen at NH-DHHS for eight years. During that time it's saved thousands of man-hours and delivered a consistent high-quality result.

And, because of the importance given to compatibility between PowerGen versions (and an initially well-conceived design) we haven't had to change our build process through all the versions of PowerBuilder that we've used. In and of itself this has been a huge timesaver and has let us remain very confident in the quality of our build procedures.