Kbase P123168: Why is the ABL loading multiple copies of the same program into memory?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
30/03/2007 |
|
Status: Unverified
GOAL:
Why is the ABL loading multiple copies of the same program into memory?
GOAL:
Why is the THIS-PROCEDURE:FILE-NAME attribute sometimes different than what I put in my RUN statement?
GOAL:
Why does running X.P and C:/MyWorkingDirectory/X.P, where they point to the exact same program on disk, cause Progress to load the program into memory twice?
FIX:
When executing a RUN statement, the ABL will take the exact text of the program being run and do a check to see if there is a program in memory that was also run using the exact same text for the program name. If such a program exists in memory then the ABL does not attempt to load a new copy of the program into memory from disk.
However, given the following two RUN statements:
RUN X.P.
RUN C:/SomeDirectory/X.P.
Where X.P and C:/SomeDirectory/X.P point to the exact same file on disk, the ABL will see those RUN statements as pointing to different programs and will end up loading X.P into memory twice. This can be seen by using the -y startup parameter and looking at the resulting client.mon file.
Given the following code:
/* A.P */
RUN SomeRelativeDirectory/B.P.
/* B.P */
/* Check whether B.P was run persistently and if not rerun it persistently */
IF NOT THIS-PROCEDURE:PERSISTENT THEN
RUN VALUE(THIS-PROCEDURE:FILE-NAME) PERSISTENT.
Where the RUN statement in A.P uses a relative path, the THIS-PROCEDURE:FILE-NAME attribute will end up returning a fully qualified file reference to the RUN VALUE statement and as this value will be different than the relative path given in the RUN statement in A.P the ABL will end up loading two copies of B.P into memory. If code written like this uses compile on the fly rather than r-code this can cause a significant performance delay due to the duplicate compilation which will happen.