A common cause of problems when installing Meister or Mojo is the prerequisites necessary for a successful install. Both Perl
and Java are required. Often, Meister customers run into a problem with either or both of these prerequisites when installing. More often than not, they do not have one or both of them installed on their machine, or they have an unsupported version.

However, even if you have the correct versions of Perl and Java installed, you might run into Perl or Java validation errors when you install Meister. The most common cause of these errors is conflicts with Oracle products. Oracle ships with its own version of Perl, which has been optimized to work with the Oracle database. When Oracle is installed, it modifies two environment variables: the PATH variable, and the PERL5LIB variable.

When Meister performs its Perl validation routines during installation, it recognizes the Perl version that Oracle has placed in the PATH. This is where the first conflict arises. Meister validates the Perl installation by running a `perl -v` command, and checking against the output of that command. Oracle’s version of Perl returns an unexpected version number string, and does not pass validation (this is by design, since Oracle’s version of Perl will not work with Meister’s Perl libraries.)

In order to pass Perl validation, then, you will need to modify the PATH variable so that the Oracle’s “bin” directory is no longer in the PATH.

Once you have cleared out references to Oracle Perl from your PATH, you will still run into one more error: Meister installation will hang if the PERL5LIB variable is definied. You will need to remove the PERL5LIB variable when you install Meister.

Openmake Support’s recommendation is to initialize a Meister install from a shell prompt. From inside the shell, modify the PATH variable to remove Oracle’s bin directory (where their perl.exe is installed), and unset the PERL5LIB. Once you have modified the environment, you can run the install of Meister. After Meister installed, you will be able to start it from your normal environment (including Oracle’s environment settings.)

While doing support calls for Mojo in the last few weeks, I ran into some mysterious behavior. One day everything about Mojo would be running fine (no, that’s not the mysterious behavior) - the workflows would run flawlessly, logging would display, etc. But, the next day, after the machine had been restarted, several .jar files that belong to the Knowledge Base server would disappear from the machine, hence the KB server could not be started.

I asked the customer to reinstall, and once again, everything would be working fine… until the machine was restarted. This went on for a few days, until we figured out that the Mojo Uninstaller that was deleting the files. However, it was the Mojo Uninstaller from a previous install that was deleting the files. It was deleting files from beyond the grave! (or the Recycle Bin)

The Mojo Uninstaller is based on a third-party software that stores a list of files that need to be deleted in an obscure location on the file system. Normally, this list is cleared once all files are deleted. However, in the customer’s case, not all files were deleted: the Knowledge Base server was still running during the uninstall, so any .jar files used by the KB Server could not be deleted. Therefore, the “files to delete” list still had these jar files listed. Once these files were freed up (i.e. on restart of the machine) the uninstaller jumped in and deleted the files. Since this list of files is stored in an obscure, relatively inaccessible place, we could not tell the uninstaller to quit uninstalling these files.

So, DO NOT use uninstall.exe when uninstalling Mojo on Windows. Unless of course you like headaches.

“So, Mr. Support Guy, how do I uninstall Mojo?” you ask?

Glad you asked. It’s a simple process:

1. Stop the Knowledge Base server - this will free up the KBServer jar files for uninstalling
2. delete all the files from the directory where you installed Mojo.
3. Delete the omenvironment.properties file.

If you have already uninstalled Mojo using uninstall.exe, and files are mysteriously disappearing from your Mojo install, then we recommend you do the following:

1. Uninstall mojo using the above process.
2. Reinstall Mojo in a different directory, so the uninstaller cannot find the .jar files it wants to delete.

In order to properly run builds with OpenMake Software products, there are a few environmental prerequisites that need to be met, such as Java, Perl and a number of environment variables (e.g. the OPENMAKE_SERVER variable mentioned in an earlier post).

To simplifiy operation in Mojo and Meister, we have introduced the omenvironment.properties file to help manage your Mojo/Meister environment.  This file contains OpenMake specific environment configuration and is automatically set up for you upon install of an OpenMake Software product.  For Windows users, this file is found in two locations: the “openmake” directory under your user’s “Application Data” folder (C:\Documents and Settings\USERNAME\Application Data\openmake) and the client\bin directory.  For those of you on UNIX or GNU/Linux, the file is found under the “.openmake” directory under your user’s home directory, as well as the client/bin directory.  The purpose of having multiple files is so that different users could have different environment settings, by using the file in their user home directories, or the environment can be managed globally with the file in the client\bin directory.  If the file exists in the user’s home directory, then that file will take precedence.  Otherwise, the file from client\bin will be used.

The main function of this file is to insure that when the Mojo or Meister interfaces are used to kick off a Workflow, these core variables required by Mojo/Meister are guaranteed to be part of the environment.  Also, by setting OPENMAKE_SERVER, it insures that you can connect to the KB server when you start the Mojo/Meister workbench.

There is another place where the omenvironment.properties file comes into play and sometimes causes problems: upgrading or reinstalling Mojo or Meister.  I will take on that topic in my next post.

Often times support receives calls about how Openmake Remote Build licensing works, in particular, whether or not build machine definition files are required. For those that don’t know, machine definition files are simply xml files that are stored on the central Knowledge Base server containing network information about how to locate licensed Remote Build machines. While these files are still used in Openmake, since 6.3, there has been no need to have them generated and provided as part of a Remote Build license. This is because the Remote Build Servers are now intelligent enough to send this machine definition information over to the KB Server on their initial startup. So now when you want an Openmake Remote Build Server licensed, you just need the license.kb generated and nothing else. This license file is stored on the KB Server and simply contains the host names/ip addresses of the licensed Remote Build Servers as well as a hardware specific hostid for the KB Server itself.

All license requests now need the following information to generate a proper license.kb:

- hostid of the KB Server (see installation guide for how to obtain this for the different OS’s. On windows it’s vol c: and most unix flavors, a derivative of the uname command)

- host names of any Remote Build Servers that are licensed, if any.

- number of named licensed users.

- contact information (name, e-mail and phone number is sufficient)

- whether or not you have a permanent license or are just requesting a demo version.

For more information about licensing, you may also always contact our Openmake sales team.

The OPENMAKE_SERVER environment variable is very important in all versions of OpenMake Software products. The reason it is so important is that it is used by our executables and other components to find your OpenMake Knowledge Base (KB) Server and communicate with it. Now if you know OpenMake well, you that if you can’t communicate with the Knowledge Base Server, you can’t do much of anything with any of our products.

OPENMAKE_SERVER will normally be set automatically whenever you install an OpenMake product. The form of the variable is as follows:

http://<KB SERVER HOSTNAME>:<KB SERVER PORT>/openmake

Where people often run into problems is the hostname part of the variable. The problem is there is sometimes difficulty in resolving the hostname to find the machine, in particular when your machine is part of a domain that uses a name server. The way to work around this is to have OPENMAKE_SERVER use the IP address of the machine.

In the past few weeks, I have encountered about three different support cases where this fixed whatever error was reported (and they were completely different errors that were reported). Since the errors that come from this problem are often misleading, the best policy is to set OPENMAKE_SERVER to use the IP address instead of the hostname whenever possible.

We have had a few people out there who want instructions for how to install Mojo on Windows but we havent yet put together a fancy looking install document because its really simple: unzip the mojo zipfile and run mojo.exe. The only non-trivial part of installation are these system requirements:

1. Windows2000, Windows XP, or Windows 2003 server.

2. Active State distibution of Perl installed, with “bin” folder of the installation included in the PATH environment variable; 5.8.8 is the current preferred Perl version, though 5.6.1 is supported.

3. Any Java Runtime Environment version from 1.4.2_05 up to the latest 1.5.0 revision.

4. User must have privileges to edit the registry.

Once these conditions are met, the installation is merely a matter of unzipping the supplied zip file into its own directory and running mojo.exe.

Also, please note that these instructions are for new users who have not installed other OpenMake products. If you are an existing OpenMake Software customer and have problems with installing Mojo, please contact your OpenMake support representative.

With the release of Openmake version 6.4, we introduced the omsubmit utility to manage the spawning of various processes during builds. By default, when bldmake and om run, they submit themselves to omsubmit which then handles their execution, logging and cleanup. When om runs, omsubmit will check to see if there are build steps that are independent and execute multiple steps in parallel, up to the limit of threads specified by the OMSUBMIT_MAX_USER_PROC variable. Omsubmit also handles reporting of build activities to the new Build Manager, providing real time information on builds accross the network.

While most people liked the new features of omsubmit, we still found that some customers wanted things to behave like they did in 6.3, before omsumbit came to be. One particular reason people asked for this is that when running builds through omsubmit, the logging is written to a local log file instead of appearing directly at the console.

Anyway, if you want to bypass omsubmit, all that is needed is to pass the -l flag to bldmake or om. This will cause the build to effectively run as it did in 6.3. Note that this means that non-dependent build steps will not execute in parallel and that the build activities will not be logged to the Build Manager.

Though it is getting to be outdated, we still have many customers using Openmake 6.3. Because of this, ever since we released support for Visual Studio 2005 with Openmake 6.41.1 last year, many customers have been asking if VS2005 support would be rolled back to Openmake 6.3.

As of a few weeks ago, Openmake version 6.3 can be used to build Visual Studio 2005 applications, though the full feature set of the 6.41.1 Add-in is not available. With the latest update, 6.3 versions will be able to have Openmake automatically generate the Visual Studio 2005 Target Definition (.tgt) files and run VS2005 builds. The main deficiency however, is that Openmake 6.3 cannot run Openmake builds from inside the VS2005 IDE, which is something that can be done with the 6.41.1 Add-in. For more information on running VS2005 builds with Openamke 6.3 or 6.41.1, please contact an Openmake support representative

Some issues are so basic, they take several weeks to debug.

From time to time, I will be involved in a support case that will stump me for hours, days, or even weeks. These are cases in which absolutely nothing seems to work. The most basic step of the most basic build will crash and burn, leaving me with no place to even begin looking for clues as to what went wrong.

When nothing seems to work, my first instinct is to look for the most complicated explanation - the issue must lie deep in the guts of Openmake, the dark hinterlands of Openmake code that I haven’t touched in my two years as support person. In reality, the most catastrophic problems often have the most basic explanations.

One of the basic elements of an Openmake installation is the Perl libraries in the command line client. These libraries power nearly every aspect of an build, from dependency analysis to logging. Openmake’s Perl libraries are automatically installed during Command Line Client installation. However, if Perl itself isn’t installed, these libraries are useless, and a build will fall apart at the seams… literally nothing will work.

Now, one of the first things I check for when nothing seems to work (instead of trying to pick apart the innards of Openmake), is a working installation of Perl.

A small change to your index.html.template file is all that is needed to get Openmake running with IE7.

Due to changes in how Internet Explorer handles JavaScript, the Openmake Web Client will not load in Internet Explorer 7 without a small fix.

In order to allow the Web Client to load in IE7, you need to comment out a line of code in the index.html.template file in your <KNOWLEDGE BASE SERVER>/tomcat/webapps/openmake.ear/openmake.war directory.

Open the index.html.template file in a text editor, and do a search for the following line: if (_ie == true)

Two lines beneath this conditional (between curly brackets) is a line that starts with: document.writeln(’…

Comment out this line by typing two forward slashes (”//”). Restart your Knowledge Base server, and you will be ready to use Openmake with Internet Explorer 7.