Kbase 18084: How-To Allow Multiple Versions of Progress to Co-exist.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
08/07/1998 |
|
SUMMARY:
This Solution explains how to setup your system if you have multiple installations of different Progress versions on your machine.
If you have legacy applications on your machines but wish to run, or
develop with newer versions of Progress, this document may help
avoid some common stumbling blocks.
EXPLANATION:
Version 6 of Progress on Windows could be either GUI or Character-based. Both the GUI and Character-based versions of Progress Version 6 on Windows relied on environment variables to establish things like DLC or PROMSGS.
Version 7 of Progress on PCs could be either GUI- or Character-based. Both the GUI- and Character-based versions of Progress Version
7 on Windows used the progress.ini file found in the dlc\bin
directory. The [Startup] section of the progress.ini was used to control the GUI version and the [DOS Startup] section governed the
Character version.
Version 8 of Progress, up to 8.1x, could be either GUI- or Character-based. (Although most were GUI-based, there are only a couple 16-bit Version 8 Progress character clients available.)
Version 8, up to 8.1x, was also governed by the progress.ini.
Version 8.2x of Progress could be either GUI- or Character-based.
Both the GUI- and Character-based versions of Progress 8.2x and higher, look first to the Windows registry to find their startup settings such as DLC and PROMSGS. In addition to the registry the Version 8.2x clients can also use the progress.ini but this needs to be forced with a command switch to make use of the progress.ini if the registry entries also exist. The startup switches which can be used together to force Progress to use a specific .ini file are -basekey and -ininame.
With the exception of 8.2x Progress, all earlier versions of Progress
on PC systems were DOS-based applications. All GUI-based versions of Progress on PCs are intended for the Windows operating systems.
Furthermore, all client versions prior to 8.2x are 16-bit.
In 8.2x of Progress on PC systems, both Character and GUI versions
are Windows applications and cannot be run solely from DOS.
Version 8.2x is 32-bit.
On UNIX systems, running multiple versions of Progress is less
problematic since UNIX handles privatization of sessions better than
Windows. For most UNIX systems, having multiple scripts which govern individual sessions is all that is needed to allow multiple versions of Progress to operate simultaneously.
Progress always checks for environment variables when starting up a
session. This applies for both client and server versions.
Therefore, if you have multiple versions of Progress on your machine
and you have an environment variable globally defined for your system,
say for example DLC, then only one of your versions will likely work
(unless something else is set to redefine DLC for the second Progress
version just prior to launching).
Progress versions which use .ini files as the main method of
governing startup settings will look in the Working/StartIn
directory specified by their icons when launching a session
and will use any progress.ini file within that directory even
if the progress.ini file wasn't originally intended for that version.
The startup switch which can be used to force Progress to use a
specific .ini file is -ininame.
SOLUTION:
Having explored version specific behaviors, the three cases below demonstrate how you can have multiple versions of Progress exist without conflict on one machine.
-- Case 1: Progress Version 6 Character client used to connect to a Version 6 server which is on a UNIX server. Progress Version 8.1C GUI client used for development.
In order to run, Version 6 requires environment variables to be set for at least DLC, otherwise an error occurs: msgopn unable to open promsgs. So to satisfy Version 6's requirement, you set DLC to point to the Version 6 installation. That having been done, the Version 6 user is taken care of.
Subsequently, the need arises for Version 8 development. The Version 8 developer copies Version 8 onto the machine then attempts to run it and gets the same type of error:
msgOpen: unable to open message file: PROMSGS
Having already set DLC, this doesn't seem possible. Every version of Progress however, will check environment variables upon startup.
Even though Version 8 can use its progress.ini file to see what
DLC is for it, it will still check the system environment as well,
and now there is a conflict. DLC is set for Version 6 and the Version 8 executable has now seen that the environment variable conflicts with what is stated in the progress.ini.
If we remove the environment variable then Version 8 will be satisfied but Version 6 will not. There is another option. On Windows, each DOS Session (window) can have different and separate environment settings than any other DOS session. That means if you wanted to open up a DOS session for Version 6 and set DLC within that window, then even if a different value had been set globally for DLC, for this particular session (until the session was ended, that is, the DOS window is closed) you can set a different value for almost any environment variable. Being awkward to always keep typing set DLC=xxxxx every time you open the window, you could instead make a batch file specifically for Version 6 sessions.
That batch file might look something like this:
set DLC=c:\v6dlc
set PROMSGS=c:\v6dlc\promsgs
c:
cd \v6work
c:\v6dlc\_progres.exe
If this code is saved into a file named pro-v6.bat and an icon is created to point to this batch file, then every time you want to run
Version 6 you could just double click this V6 shortcut you created.
DLC would not need to be global to the machine, but even if it was,
the SET statement within the batch would alter the value just for the
session.
-- Case 2: Suppose you have Progress Versions 8.1A and 8.1C on your machine. They are contained within two separate installation directories but both have been set to use the same working directory.
(Working directory or Start In directory are listed within the
icon you use to start up Progress). Supposed you have a copy of
your progress.ini for 8.1C in the working directory as well.
Even though both versions of Progress make use of a progress.ini
file, since they both have the same working directory there is
something that might not be known about how Progress uses the .ini files. Progress will look in the working directory for a copy of the progress.ini when one of the Progress versions which uses an .ini file is launched. If it finds an .ini file it will read it and use the settings contained within it to govern its session. However if the
progress.ini file is actually set up for a different version of
Progress, then again there will likely be a conflict.
-- Case 3: Suppose you have Version 8.2x and 8.1C.
The only real point of contention between the two will likely be if you set any environment variables such as DLC or PROMSGS.
Since both of these use methods other than environment variables
for normal startup parameters they don't truly require environment
variables except in very specific instances (for example, Oibroker or
AppServer).
However, if an environment variable were to be set, then only one of
these versions would likely be able to run.
Example:
If DLC were set to DLC=c:\dlc82c and you tried to run 8.1C then 8.1C
would complain, "msgOpen: unable to open message file: PROMSGS".
If no variable is set then, by default, 8.2C looks to the registry for its settings while 8.1C looks to the progress.ini.
These 3 cases show some of the most common conflicts that will arise on most systems. In general a UNIX system will face fewer of these situations because session profiles usually will privatize environment settings and will step around most of these problems.