Home page Home page Home page Home page
Pixel
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel
Pixel
By Captain C | Wednesday 27 May 2009 09:00 | 0 Comments
In the recent posting on OI initialization we touched upon the program loader process, or RTP27 as it's officially known. This is the stored procedure that is responsible for loading object code onto the OpenEngine program stack so it can be executed.

An integral part of this loading process is the SYSENV SYSPROCNAMES record, which is simply a list of all the stored procedures that OpenInsight considers to be system stored procedures. It is cached in memory during the engine boot process.

Under most circumstances you'll see RTP27 use the application inheritance chain to find the correct version of the object code to load - i.e. it parses @AppID appending an extracted application name to the specified program name until it finds the correct record in SYSOBJ or until it reaches the SYSPROG application.

For example, if the application inheritance chain looks like this:
  • GRANDCHILD_APP
  • CHILD_APP
  • PARENT_APP
  • SYSPROG


Then RTP27 will search for the object code record for TESTPROC in SYSOBJ in the following order:
  • $TESTPROC*GRANDCHILD_APP
  • $TESTPROC*CHILD_APP
  • $TESTPROC*PARENT_APP
  • $TESTPROC


However, this is not the whole story: RTP27 first attempts to locate the program name in the cached SYSPROCNAMES list. If found then the SYSPROG version of the program is loaded - the application inheritance chain is never used. This is to prevent application specific programs with the same name as a system program from loading and possibly interfering with the system processes.

You may think this sort of thing doesn't happen, but on a recent site visit we moved an existing OI 4.1.3 system to version 9.0.0 (We did this the simple way - an APPBACKUP from 4.1.3 into a clean 9.0.0 system). One of the big issues we encountered during the upgrade process were naming conflicts: Being a well established system there were some stored procedures in the client application that had the same name as those found in the SYSPROG application. For example, the clients PlaceDialog() function conflicted with the SYSPROG PlaceDialog() function - the result? No dialogs were visible in the System Editor++ when run from the client app - ouch!

Of course I just said that SYSPROCNAMES protects system routines right? Unfortunately the OI 9.0.0 installation process installed a blank SYSPROCNAMES record which meant that nothing was protected. This has been corrected in the next release (OI 9.0.1 as of writing), but as a workaround for now simply copy the SYSPROCNAMES across from your OI 8.x system if you need to.


Compiler Protection and modifying SYSPROCNAMES

Just as it protects RTP27 at runtime the SYSPROCNAMES record also protects the system from accidental compilation and overwriting of system stored procedures: The compiler will not let you compile any stored procedure if it's name can be found in SYSPROCNAMES.

If you need to disable this feature for any reason you can modify the desired program name in SYSPROCNAMES (usually by inserting a ";" or "*" in front of it), saving the changes, and then rebooting OI (This is how the aforementioned client had programs in their own application with the same name as system programs). This will have the added effect of forcing RTP27 to load your modified version rather than the SYSPROG version at runtime. Bear in mind however that OI upgrades from Revelation will overwrite SYSPROCNAMES so make sure you remember any changes you make to it!

Labels: , , , ,

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]



<< Home

Pixel
Pixel Footer R1 C1 Pixel
Pixel
Pixel
Pixel