Skip navigation
All Places > Licensing and Installation > Blog > 2014 > October
2014

If you have automation for removing the local WDIR in your Windows environment, then you know the challenge is that %WDIR% can be made of up several paths, like this one:

 

WDIR=C:\WDIR;\\my\corporate\wdir;C:\MentorGraphics\7.9.5EE\SDD_HOME\standard

 

In most circumstances all you really want to remove is the first folder in the path, the local WDIR. You could hard code the paths to it in your script, but then you'd have to depend on everyone using a standardized name or passing it as an argument.

 

Here is some nifty code you can but into your batch script that will parse the %WDIR% variable, get the first path name (the local WDIR path), and assign it to a variable:

 

:: These commands are required so that variable expansion works in your script environment

setlocal enableextensions enabledelayedexpansion

 

:: Echo WDIR, then using ; as a delimiter, get the first token and assign its value to MY_WDIR

for /f "usebackq tokens=1,2 delims=; " %%w in (`echo %WDIR%`) do set MY_WDIR=%%w

 

:: Now that we've isolated the local WDIR folder, we can remove the folder

rmdir /s /q %MY_WDIR%

 

There you have it. I hope this tip is useful.

 

-K

Testing an Oracle Server Installation

Use SQL Plus to verify that the database connection with the Oracle Server is okay.

 

Note:
The Oracle version installed is 11gR2, 11.2.0.3.0

 

Procedure

In Services, check that the Oracle listener is started.

In Services, check that the Oracle database service is started.

Open a command prompt and use the cd command to navigate to <oracle_home>\BIN:

For example: C:\app\myuser\product\11.2.0\dbhome_1\BIN

Enter this command:

sqlplus system/<password>@<instance>

<password> is the password entered for the SYSTEM user when Oracle was installed

<instance> is the database instance.

 

Result

If the database can be accessed using the credentials you have entered, sqlplus
lists information about the Oracle version and about the database, and displays
the prompt SQL>.

 

Example

C:\app\myuser\product\11.2.0\dbhome_1>cd bin

C:\app\myuser\product\11.2.0\dbhome_1\BIN>sqlplus system/mypassword@mydb

 

Successful output:

SQL*Plus: Release 11.2.0.3.0 Production on Tue Dec 18 15:11:32 2012

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

I recently received a license file for Questa Core, the installation of which had me wrapped around the axel for a few minutes.  Spoiler alert: it was the line endings.

 

I'm consulting at a painfully small startup, which explains why every computer here is a Windows machine. Having a long and storied history in ASIC design, when confronted with the Windows OS, I will do my design and development work using Cygwin (www.cygwin.com). For those of you not familiar with Cygwin, it is "a large collection of GNU and Open Source tools which provide functionality similar to a Linux distribution on Windows." I think Cygwin is great, but you can expect to encounter Windows (DOS, really)/Unix line-ending interoperability problems.

 

Why am I telling you this. Because my experience with Cygwin has implanted some sort of watch-dog process in my brain. When confronted with very weird results for what should be a minor and straightforward effort, the watch-dog gets triggered, and it sends this message to my brain: "Maybe it's a line-ending issue."

 

And it was. Our license server (FlexLM) is hosted on a Windows computer. But the license was in Unix format. And try as I might, I couldn't get the license server to start *or* produce a log file.

 

LSS (long story short), my internal watch-dog got triggered, I ran Cygwin's unix2dos utility on the license file, and Bob's your uncle (that's British for "that fixed everything". No, I don't know why it means that).

 

So, is the moral of this story "When in doubt, maybe it's the line-endings!"? Not so fast.

 

A subsequent search of supportnet, Flexera's website, and even Google yielded no mention of this license file issue . Am I one of only a handful of people to encounter this? I would think this issue would be much more common these days. Have any of you, esteemed readers, ever tripped over this issue. Please let me know.

 

But in the meantime, when in doubt, maybe it's the line-endings.

What does this license error message mean?

 

There are two messages which regularly we get asked to explain.  They are similar, but refer to different areas of licensing, and have different solutions.

 

 

FLEXlm version of the vendor daemon is too old

 

This means that the tool you are trying to run requires a newer version of software on your license server.

 

You can check which version you are running with the command "lmutil lmstat".  It should show v11.11 for BOTH lmgrd and mgcld.

 

If the version you are running is not the latest (v11.11), then update it using the instructions in technote mg66951.

 

 

License server does not support this version of this feature

 

This means that your license file does not include the correct version of license to run this version of the tool.

 

The version number appears as the 4th entry on each INCREMENT line in your license file:

 

     INCREMENT wgascentl2 mgcld <version> <expiry_date>

 

For example the license below has the version 2014.120:

 

     INCREMENT wgascentl2 mgcld 2014.120 31-mar-2015 ...

 

If you have a current support contract, ensure that you are using the latest license file available from Supportnet.  This should have a license with a newer version number.

 

If you do not have a support contract, you will be restricted to older versions of software.  For example, a license with version 2012.120 will only enable you to use software released in 2012 and earlier.  To use later versions, please contact Mentor Graphics Support.

The first time the Registrator runs (during the VX install) it prompts for the local WDIR folder location, and the value entered is stored into the WDIR_<product_root> environment variable. For example, PADS VX product root is "PADSVX.1.1" and therefore the variable name is WDIR_PADSVX_1_1 (replace periods/full-stops with underscores). The value of this variable becomes the "WDIR" once the applications launch (see TechNote MG586180 on SupportNet for more details).

When the Registrator next runs (launched from the Start Menu or via the Release Switcher) the WDIR prompt is populated based on the WDIR_<product name> environment variable. If you change the value, the variable is updated. Do NOT attempt to update the WDIR environment variable in the system area, as it will be over-written by the WDIR_<product_root> environment variable (e.g. WDIR_PADSVX_1 for PADS VX.1) as soon as the application launches.

While you can edit the WDIR_<product_root> environment variable in the system area , the recommended way to change the WDIR is to run the Release Switcher or Registrator.

Refer to the screen-shot below to see the relationship between the WDIR_<product root> variable and the WDIR prompt in the Registrator.

PADSVX0_WDIR.png

 

Related TechNotes:

 

Setting (and silencing) the WDIR variable (on SupportNet)

VX installation did not set environment variables, is this expected?