PFC 6.0 Migration |
Page 2 of 3 |
PFC 6.0 introduces two new libraries:
Pfcutil.pbl contains utility objects such as Debug, SQLSpy, and Datawindow Property service.
Pfcold.pbl contains obsolete objects. Datawindow debugger objects, replaced by the datawindow property service and the delete buffer dialog window, replaced by the restore row dialog window. The pfcold.pbl library should remain in your library path until the conversion is complete at which time you can examine your application to determine if the objects were utilized and whether they can be removed.
A rule of thumb for PFC migration is: for every new PFC object create a corresponding extension layer object. The challenge is to figure out the best way to copy/create the new extension layer objects for the new PFC 6.0 objects. Determining which objects were introduced in PFC 6.0 is not difficult. A list of new objects is provided in the PFC 6.0 file. However, determining the source and destination for these objects is slightly more involved. The issue is complicated further if an additional extension layer was implemented in a project. Consider a project with a department extension layer and out of the box PFC 6.0 libraries. How do you copy objects between the two?
One approach is to keep track of the current object source and the intended destination. This can be manageable when the inheritance structure of the source and the target are the same. It is more difficult to achieve when one side contains two extension layers while the other only one.
The solution to this problem is to arrange the library and inheritance structures of PFC and the current project to mirror each other. This ads an extra preparation step, but will greatly simplify the copy process. As an example, consider a project mentioned previously with an additional (department) extension layer. To match the PFC structure six new libraries are created and added to the application library path.
| 1 - pfcutil.pbl | 4 - pfcold.pbl |
| 2 - pfdutil.pbl | 5 - pfdold.pbl |
| 3 - pfeutil.pbl | 6 - pfeold.pbl |
Next step is to move the objects to the newly created libraries to mimic their location in the PFC 6.0 libraries. Because PFC layer PBLs will eventually be replaced moving the objects to libraries 1 and 4 is optional.
The obsolete object library - pfcold.pbl does not have an extension layer library so one has to be created. If you have not added an additional extension layer, no other changes to PFC 6.0 PBLs are needed. However in our example an additional department layer was inserted, so the PFC 6.0 libraries will require an insertion of the same layer as well. Fortunately this time a PFC Library Extender utility is available to simplify this task. To be able to rebuild new libraries a dummy application may be created, with library path encompassing the new PFC 6.0 libraries. Don't forget to declare a gnv_app global variable! After inserting an additional layer perform a full rebuild, using an empty dummy application.
After all the libraries have been prepared, the result is one to one relationship between the PFC 6.0 and the Application PBLs
| Step 4 | Create new PBLs and arrange the objects to mirror new PFC structure and object location. |
| Step 5 | If needed, insert an additional extension layer into PFC 6.0 to mirror the application inheritance structure. |
Before beginning the copy process one more precautionary measure may be taken. There is a possibility that you may have created an object with the same name as one of the new PFC objects. If that is the case, you may overwrite your old objects with new PFC 6.0 version. The Migration Assistant may be used "in reverse", searching your old application for any new PFC objects. This can be accomplished by copying the names of the new objects from the into custobs.txt. A sample file is shown in . The Migration Assistant can be used to search for custom "obsolete", or in this case new, syntax.
[Added 01/27/98 Version
1.0.02]
Another danger exists if you have declared user events mapped to the standard event IDs.
PFC 6.0 has introduced a couple of new events mapped to the standard event IDs.
For example if you have added a ue_dropdown event to u_dw
or any descendant and mapped it to pbm_dwndropdown you
have a problem. PFC 6.0 has added a dropdown event to the pfc_u_dw
mapped to the same event ID. The best outcome is a "Duplicate Event ID"
error message during the rebuild process, the worst is a Dr. Watson Exception Error.
It is strongly recommended that you scan your corporate, department and
application libraries for any events mapped to pbm_??? The
file has been modified to reflect the new
event IDs used in PFC 6.0. The Migration Assistant can be used to identify duplicate
event IDs.
[END Version 1.0.02]
The 6.0 PFC PBLs may now be copied overwriting the corresponding PFC PBLs in your project. Copying the extension layer objects may be accomplished one of two ways.
The Forward Copy approach, involves copying all the objects from the project extension libraries to the corresponding PFC 6.0 extension libraries. Objects from pfe_apsrv.pbl should be copied into pfe_apsrv.pbl, objects from pfe_wnsrv.pbl should be copied into pfe_wnsrv.pbl, etc… The old extension objects will be overwritten, the new objects will remain unmodified. The advantage of this approach is that you do not have to keep track of the new objects as they are being copied.
Using the Reverse Copy method only the new objects are copied from PFC 6.0 extension libraries into the project extension libraries. As previously mentioned, the list of these objects and their location is documented in the file.
| Step 6 | Use the Migration Assistant to scan the project PBLs for any occurrences of the new PFC 6.0 object names. |
| Step 7 | Copy the PFC layer PFC 6.0 libraries overwriting the corresponding libraries in the application. |
| Step 8 | Copy only the new PFC extension layer(s) objects into your
extension layer(s). (Reverse Copy) or Copy all the objects from your extension layers into PFC libraries. (Forward Copy) |
Last revised: February 15, 2004 03:58 AM.