Providing support for all E. Crane Computing products, including POWERGEN, PBSERVICE, HARPB, VERSIONEDIT, PBLRESCUE, and PBLEXPLORER.
You are not logged in.
Pages: 1
I've been away from PowerBuilder/PowerGen a good number of years and I want to make sure I'm up to date on the best practices.
In a former life ( 1999-2003 ) I did nightly bootstrap builds and event driven ( check in ) incremental builds that would take the most recently added/modifed objects, but them in to a LMC ( Last Minute Changes ) PBL and rebuild just those objects. This gave me a set of PBL's that were in near real time sync'd to my object definitions that were in PVCS.
The developers would refresh there development environment from those PBLs and CM would perform a build to create EXE/PBD's from those PBLs.
Now I'm trying to do all of this using TFS Team Build but I want to simplfy/refactor the design if possible. Speed and Reliabilityare important to me. I have some questions and feel free to point me in a different direction:
1) What's hardware configuration choices are best for PowerGen? I remember back in the day the AMD 3200 Barton Core running the build on a RamDISK was idea. The Pentium 4 seemed to be slower to build. But when Windows 2000 came out the disk caching was a lot better so I don't know if a RamDISK driver would help anymore. I'm testing right now as we speak.
2) Is syncronizing the PBL's safe and reliable? I can tell TFS to not reset my workspae and not force a get of the object unless it's changed.... If I do this, will the sync process quickly and reliably update my PBLs? I always found the bootstrapping at night and all updates into a 1st z-order pbl to be very fast and reliable but it comes at the cost of having to support two different build types.
Right now a full bootstrap import and generation of pbd's is taking 1:20 minutes. Currently it takes 20 minutes to build using the project object from PBLs. If I could get a bootstrap or sync process down to under 30 minutes I think I'd be very satisifed. Faster is nicer of course...
RAMDisk had almost no impace.
The sync seems to work fine, it took me 56 minutes to do an initial full build
1:55 - 2:27 ( 33 minutes ) /K with all objects being new
2:25 - 2:51 ( 26 minutes ) /A full regen / build of PBD/EXE
Now I'm running a test of the incremental pattern. No files have changed and yet Powergen thinks a single window changed:
Object 'w_getzoomfactor_visiflow' in 'C:\TEAMBUILD\ANTHEM\Clerk\Sources\pbl\athshrialvisflw.pbl' has changed
Summary of Synchronization
1 object(s) updated
4009 object(s) unchanged
0 object(s) added
0 object(s) deleted
It took about 35 seconds to do the sync. I'm guessing the regen / build will take the same time as before so my incremental build is basically half the time of the full build. That should be good enough, but is it safe? I don't understand why it says a window changed when it did not. There is no changeset in TFS for that object ( this is a prototype and no one is checking in and out yet anyways )
Sorry for the delayed response.
Synchronization is very reliable. The function has been used heavily since PB6, and there haven't been any problem reports on it in years.
As for the window that thinks it has changed, can you send the source file for it? After it reports a difference, what happens if you export it and then try the synchronization again? PowerBuilder (and likewise the ORCA interface that PowerGen uses) has been know to rearrange segments in the source. This has never caused a problem in the build but can create then kind of symptoms you are seeing.
Regards,
Phil
I'll email you the source for the object in question.
Any thoughts on the performance question? I asked over 4 years ago back in the P4 vs AMD Barton days and no one had an answer back then.
http://groups.google.com/group/comp.soft-sys.powerbuilder/browse_thread/thread/1b598418a9183969/7181188c2ccd7066?lnk=st&q=powergen+performance&rnum=1#7181188c2ccd7066
I imported, regenerated and exported the object in question and the problem has gone away. Doing a text comparison I can see that following three types were resorted to have cbx_save as the last type. I think this is a bug in the export functionality of powergen as all 4000 of my objects were created in this way. I can live with this though since PowerBuilder will be doing all exports from here on out... Powergen export was only for a one time conversion to the new system.
Thanks,
Chris
type cbx_save from w_getzoomfactor`cbx_save within w_getzoomfactor_visiflow
int X=82
int Y=772
end type
type cb_cancel from w_getzoomfactor`cb_cancel within w_getzoomfactor_visiflow
int X=498
int Y=932
end type
type cb_ok from w_getzoomfactor`cb_ok within w_getzoomfactor_visiflow
int X=125
int Y=932
end type
Chris,
I'd be surprised that the change in the export syntax is specific to PowerGen. It uses the same PB DLLs that the PB IDE uses.
If you find a case where the export syntax is different when exported by PowerGen and PB from the same PBL, please send the PBL to me.
Regards,
Phil
PowerGen seems to export objects with newlines in object comments differently then PowerBuilder also. PowerBuilder puts a ~r~n escape sequence and keeps the comment on one line and PowerGen literally breaks the comments on to the next line. This then causes the object to choke in PowerBuilder since the PB Version metatag isn't on the next line as expected.
Can you e-mail a sample object that shows the problem? I'd like to check this against the upcoming release of PowerGen V7.0 and make sure it's addressed.
Regards,
Phil
I've emailed the problematic objects ( before/after/readme.txt )
Pages: 1