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

What's new in Mentor License Utility (MLU) v3.0?

MLU version 3.0 (BETA) introduces many new and exciting functions. To name just a few:

  • Install licenses directly from SupportNet
    • From within the main MLU program but also from a new system tray applet!
    • Schedule a new license check (automated, runs in the system tray) for every 1, 3, 6, or 12 months!
    • See further below for screen-shot and demos
  • New "Server Services" tab for quick access to license manager info (mgcld daemon only)
  • New "Install Licenses" tab for quick access to license install and downloads

 

See further below for sample screen-shots.

 

For download and more details (including videos) refer to the following TechNote on SupportNet:

http://supportnet.mentor.com/portal?do=reference.technote&id=MG586631

 

 

Install Licenses (main) tab:

mlu_main.png

 

Install licenses from SupportNet:

MLU_InstallLicense.png

 

Server Services tab:

mlu_services.png

 

Client Environment tab (was the default display in MLU v2.x):

mlu_client.png

 

MLU Updater (system tray applet):

MLU_updater_menu.png

 

New licenses on SupportNet have been found and are ready for installation:

MLU_updater_newLicenses.png

One thing that's always been lacking in Windows is a good interface for creating or editing your environment variables, especially when it comes to PATH:

 

2014-08-22_141706.png

 

Se what I mean?

 

Fortunately, there's a great free utility called Rapid Environment Editor that not only makes it easier to edit variables, it will also tell you where you have bad values. Check it out:

 

2014-08-22_142055.png

 

It highlighted my Path in red to tell me there was a problem and when I expand Path, it shows the problematic entries. Brilliant!

 

I can delete these and save my environment with a cleaner PATH variable.

 

Feel free to give REE a try - http://www.rapidee.com

 

Guy

Those of you who frequent the Mentor Graphics Community have provided a tremendous benefit to the community at large; providing solutions and sharing your experiences for the benefit of others. By coming here and actively participating you have made the community what it is, and what we hoped it would become.

 

However, there are times where opening a service request with customer support is necessary. For those so entitled, this Tip of the Week gives you the top 5 things to include in a service request that will make the handling of your issue go as smoothly as possible.  Here is the list, in no particular order of importance.

 

1.       Product and Version Information

 

P        Providing this is key for a CAE to know where to start looking for a resolution to your issue. It helps them to quickly zero in on known issues in particular versions of software and find their solutions, provide you with information about patched versions, etc. The Product field is also used by our automated systems to route service requests to the right people who are the subject matter experts. Being as accurate as possible helps avoid any mis routing of service requests to the wrong support team, and the resulting delay as the request is re-routed.

 

2.       Platform and OS Information

 

      For much the same reason stated above, having accurate platform, OS and architecture information helps a CAE get to the root cause more efficiently. When they know what you have, a CAE can easily eliminate possible causes that don't apply to your platform, OS, or architecture.

3.      

            Error Messages and Log Files

 

      The error message is the first thing a CAE will analyze in the process of troubleshooting your issue. A complete and accurate error message, if one is presented, is the lead that can crack the case wide open. If no error message appears that is also an important clue, and you should point that out. Recording them word-for word, exactly as they appear, is important because subtle differences may give the error message a different meaning. Adding screen captures to your service requests is a perfectly acceptable way of providing this information. Log files that contain error messages, design path names, etc. are always welcome and should be included, especially if known to contain relevant data.

4.      

           Contact Information

 

      Your SupportNet profile allows you to set a preference for how contact with you is made (phone or e-mail). By default, no preference is set. In that case, CAEs use their own discretion to decide how to make contact with you. If you have a preference, setting it in your SupportNet profile avoids a situation where you are waiting for your phone to ring but the solution has been in your inbox the whole time. Accurate contact information is vital to avoid delays. Best practice is to review this information any time you open a Service Request.

 

      It's pretty common for the person opening the Service Request to be assisting another user at their desk, or perhaps in the data center working on the problem. In that case you should provide alternate contact information if needed, and specify the date/times when you can be contacted there. The most conspicuous place to put this information is in the symptoms field.

      

           Provide a Summary of Self-Solve Attempts

 

      If the CAE knows what you've already tried to solve the problem yourself  (TechNote procedures you followed, for example) it will help them focus their inquiries on the results you had instead of starting at square one.  CAEs read the details in your service request before they make contact as a rule. So for example, if they read in your service request that you reinstalled the software and there were no installation errors, they can assume for the moment that it’s not an installation problem and start troubleshooting elsewhere when they engage you.

 

 

This tip is written with Service Requests in mind, but also applies when posting in the community as well. Those who read your post may be more inclined to respond if they have enough information to form an opinion.

In Oracle nomanclature, patch 10404530 refers to the base 11.2.0.3 install. Using the term 'patch' may cause confusion but that is how Oracle refers to their software.

Oracle base version 11.2.0.3.0 automatically contains the patch 10404530 data. The ‘patch’ is a full install, despite the reference.

With the release of PADS VX.0, the Aladdin USB (9-) hardware key is now the only supported dongle. We began dongle discontinuations a few years ago and they have trickled out release by release. The PADS VX.0 is a major release and customers using older dongles who wish to run the latest version will need to request a replacement key.

 

Please see our Hardware Key (Dongle) Discontinuations and Replacement FAQ for more information.

 

Customers running older releases can continue to run with the older dongles provided they are on a supported platform.