LicenseMonitor

References to $VOVDIR translate into the installation directory (for example, /opt/rtda/2011.03 or c:/rtda/2011.03).  Also, all paths should use /, even on Windows.

1. Determine the user and location for the installation.  We recommend using a service account for installing and running LM, although a normal user account can be used.  Local installations typically yield slightly higher performance and reliability, but some customers prefer their tools to be installed on a network filesystem.  We support either.  We do not support running LM as the root user on Unix.
2. Install RTDA software bundle.  Default options in the installer are almost always used.
3. Make sure "lmstat" and "lmremove" are visible to LM.  This is so that there is a default version of lmstat available for monitoring (you can also specify individual paths to lmstat per tag) as well as to provide lmremove functionality from the web UI.  Visibility can be ensured a couple of ways.  The first would be to copy both of these executables, or link to them, inside our $VOVDIR/bin directory.  The second way would be to make sure that the PATH environment variable includes a location where these exist, and running LM in that environment.
4. Start LM.  There are 2 methods that you can use to start LM.  The first method is to start it manually.  To do this, first setup the shell/command prompt to use our commands.  This can be doing by sourcing the $VOVDIR/etc/vovrc.csh (or .sh) script on Unix, or by running the $VOVDIR/bat/vovinit.bat script on Windows.  On Windows, you can also open $VOVDIR/startup in Windows Explorer and double-click the "vovcmd.bat" script (this opens a command prompt window with our environment applied).  With the environment setup, you can now start LM by typing "lmmgr start".  The defaults here are fine unless you need to change the ports that the application uses.  On Windows, you can avoid using the command prompt altogether by double-clicking the $VOVDIR/startup/lm/startlm.bat script.  The second method is to start it automatically at system startup.  To do this on Unix, modify the boot script template ($VOVDIR/etc/boot/S99lm) to match the customer's installation, then copy it into the /etc/init.d directory.  Afterward, links can be created in /etc/rc3.d and /etc/rc5.d to point to the script, which enables automatic startup.  On Windows, you can install the LM service by double-clicking the $VOVDIR/startup/lm/installlmservice.bat script.  Once you do this, you will be prompted to change the service user from the default.  This is done with the Windows Service Manager, and it is very important to perform this step.  Forgetting to do so would be like running LM with the root user on Unix, which we also do not support.  Once this is done, the service can be started, also using the Windows Service Manager.
5. Install the license.  Upon first startup, the $VOVDIR/../../licmon/licmon.swd directory is created.  This is where the license.key file is to be installed.  It is important to visually compare the contents of the file against the text that was in the license e-mail.  Microsoft Outlook often corrupts our license key during the detachment process.  Once the license is installed, login to LM as the owner-user, then click on the Admin tab, then the License page.  This will allow you to check the validity of the license, or see errors if the license is not valid.
6. Configure your first monitor.  Visit the Monitors page, also under the Admin tab, to do this.  The form is straight-forward.  Minimum information required is a uniquely-named "tag" that names the license server instance, and the port@host of the license server.  After approximately 30 seconds, your monitor should be active.  You can see this either in the Home page, or any of the pages located under the Current tab.  You can check the Tasks page under the Admin tab to debug problems if data does not show up.  If the jobs are red, they failed, and you'll want to check the Current > Raw Data page to see what the errors are.  If the jobs are light blue, they are queued, meaning that they have not yet executed.  This could be because of system overloading, or perhaps the parsing slave failed to start.  In this event, contact support@rtda.com for assistance.  This situation does not occur often.

These steps can be used to get up and running quickly, using the bundled SQLite database.  If MySQL is to be used, the database configuration steps that are outlined in the Admin Guide will need to be followed.  Please let support@rtda.com know if you have questions or need more information.

LicenseMonitor must be timezone-aware in 2 different situations:

1.  When parsing a debug log that was generated in a different timezone:

The debug log parser is executed locally on the LM server using the servers local timezone by default.  The debug log contains date/time information that was generated using the timezone of the remote server.  In the configuration, you can specify a timezone for the debug log.  What we do is run the debug log parser job in an environment that has the timezone overridden to the one that you specify.  Our parser will then appropriately localize the entries found in the log.  If the specified timezone is valid for your system, it should work just fine.  Example:

As you can see, I'm in EST, but when I override the environment with PST, the date/time is reported accordingly.  This is how we run the parser if an alternate timezone is specified in the configuration.  There are several supported timezone specifications on various systems.  Google is a good place to search for valid timezone specifications.  To confirm that the timezone override is working for your remote debug logs, find a DENIED event in the log and match that up with a denial in a history report for that tag.  If things are working correctly, the time for the denial should be localized to the LM server timezone.

2. When running lmstat across ssh on a machine located in a different timezone:

If you are using lmstat against a remote server directly, the timezone should already match what your LM server timezone is.  The lmstat utility reports the times using the timezone for the machine that it runs on.  If you are using lmstat across ssh, then you will need to override the timezone in the command setting.  Example:

In this case, demo5 is in PST, so that is what is reported when I run date on it across ssh.  But I can override it to EST to get the date to reflect my timezone.  The timezone specification in the monitor administration page only affects the optional debug log parsing.  It does not affect the lmstat run.

S, for a license server running in Europe, you're probably going to want to specify something like:

for the lmstat command to get the clock to not appear incorrect with respect to the LM server clock.

To summarize, with lmstat, you must make sure that it is executed in the LM server timezone.  With debug logs, you must make sure that the parser is executed in the timezone that the debug log was generated in.

To fix this issue, you must set the following variable in licmon.swd/setup.tcl:

setenv VOV_HOST_HTTP_NAME your-LM-server-name

Just remember to replace "your-LM-server-name" with your actual LM server name.  This name should be equal to whatever works with your DNS.  So, if your running LM on Linux and your Windows machines can only see the machine with the full domain name, enter the full domain name.  If short names are OK in your DNS, then using the short name is fine.  After making this change, you'll need to either restart LM or do the following:

vovproject enable licmon
vovsh -x "vtk_server_setenv VOV_HOST_HTTP_NAME your-LM-server-name"
vovproject reread
vovslavemgr stop
vovslavemgr start

This is a one-time change.  New LM installations using 2009.08 Update 2 will have the fix by default.

Brian