some users will be harmed by the new licensing policy in IDL 8.6

[Patrick Broos]

Prior to IDL version 8.6, on a unix machine (e.g. Mac), a license was required for each unique instance of the triplet (hostname, $USER, $DISPLAY). For example, a single user (with constant $DISPLAY) could run as many concurrent IDL sessions as desired, while consuming only 1 "license". This was extremely useful for data processing on multi-core machines (if the processing was most naturally parallelized via multiple IDL sessions). It was also convenient to be able to maintain several interactive IDL visualization sessions open on several desktops for days at a time without burning a lot of floating licenses.

All this is changing in IDL 8.6. Below is Harris Corp's response to my inquiry about the new licensing scheme they are rolling out. The bottom line is that if you are using floating licenses, every IDL session will now consume a license. If you have a node-locked license, you get only 4 concurrent sessions.

In my field, astronomy, I fear this will transform the long slow movement away from IDL into a stampede.

-----------------

Any time you launch an IDL session, it will count as a concurrent instance. Therefore is you try to launch 12 session of IDL on a single system at the same time, that will count as 12 instances as IDL. Any IDL 8.6 entitlement can be implemened as either a node-locked (stuck) to one computer or a floating license (can be used by multipled systems). If you use a node-lock license, you can run up to 4 concurrent IDL processes on the system. For floating licenses, each instance of IDL requires a license. A more detailed description of how many instances are available for an IDL development license is shown below:

Local (node-locked) license:
IDL command line/ IDLDE - 4
Execute compiled save code - 4
IDL Bridge Processes - 16
IDL Task Engine - 1

Served (floating) license:
IDL command-line/ IDLDE - 1
Execute compiled .sav code - 1
IDL Bridge Processes - 8
IDL Task Engine - 1


If you are using a node-locked license and you want to run 12 development sessions of IDL, you will need 3 licenses. If you are using a floating license, it would require 12 licenses to run 12 concurrent IDL development sessions. Another thing to note is that you can use 16 concurrent IDL_IDLBRIDGE sessions using a single node-locked license. Therefore, if you want to run 12 IDL_IDLBRIDGE sessions concurrently on a single system, you would need 1 license with a node-locked license and 2 for a floating license.


I hope that this information will be helpful to you. Please let me know if you have any additional questions or issues. I am happy to help.

[wlandsman]

Pat,

Thanks for alerting us to this. I am not sure that this is actually a change for floating licenses. Currently in our large group, every time someone starts a IDL 8.5 session (command line or idlde) it counts toward our total of 200 licenses. This seems the same as the V8.6 policy.

It does seem to be a change for node-locked licenses. If I want to process 6 data sets at the same time on a multi-core machine, the easiest thing for me is to start 6 IDL sessions, whereas for IDL 8.6 only four sessions would be allowed. Perhaps one can use the IDL_IDLbridge to get around this but it doesn't seem convenient.

-Wayne

Post by Patrick Broos
Prior to IDL version 8.6, on a unix machine (e.g. Mac), a license was required for each unique instance of the triplet (hostname, $USER, $DISPLAY). For example, a single user (with constant $DISPLAY) could run as many concurrent IDL sessions as desired, while consuming only 1 "license". This was extremely useful for data processing on multi-core machines (if the processing was most naturally parallelized via multiple IDL sessions). It was also convenient to be able to maintain several interactive IDL visualization sessions open on several desktops for days at a time without burning a lot of floating licenses.
All this is changing in IDL 8.6. Below is Harris Corp's response to my inquiry about the new licensing scheme they are rolling out. The bottom line is that if you are using floating licenses, every IDL session will now consume a license. If you have a node-locked license, you get only 4 concurrent sessions.
In my field, astronomy, I fear this will transform the long slow movement away from IDL into a stampede.
-----------------
IDL command line/ IDLDE - 4
Execute compiled save code - 4
IDL Bridge Processes - 16
IDL Task Engine - 1
IDL command-line/ IDLDE - 1
Execute compiled .sav code - 1
IDL Bridge Processes - 8
IDL Task Engine - 1
If you are using a node-locked license and you want to run 12 development sessions of IDL, you will need 3 licenses. If you are using a floating license, it would require 12 licenses to run 12 concurrent IDL development sessions. Another thing to note is that you can use 16 concurrent IDL_IDLBRIDGE sessions using a single node-locked license. Therefore, if you want to run 12 IDL_IDLBRIDGE sessions concurrently on a single system, you would need 1 license with a node-locked license and 2 for a floating license.
I hope that this information will be helpful to you. Please let me know if you have any additional questions or issues. I am happy to help.

[Chris Torrence]

Post by wlandsman
Pat,
Thanks for alerting us to this. I am not sure that this is actually a change for floating licenses. Currently in our large group, every time someone starts a IDL 8.5 session (command line or idlde) it counts toward our total of 200 licenses. This seems the same as the V8.6 policy.
It does seem to be a change for node-locked licenses. If I want to process 6 data sets at the same time on a multi-core machine, the easiest thing for me is to start 6 IDL sessions, whereas for IDL 8.6 only four sessions would be allowed. Perhaps one can use the IDL_IDLbridge to get around this but it doesn't seem convenient.
-Wayne

Post by Patrick Broos
Prior to IDL version 8.6, on a unix machine (e.g. Mac), a license was required for each unique instance of the triplet (hostname, $USER, $DISPLAY). For example, a single user (with constant $DISPLAY) could run as many concurrent IDL sessions as desired, while consuming only 1 "license". This was extremely useful for data processing on multi-core machines (if the processing was most naturally parallelized via multiple IDL sessions). It was also convenient to be able to maintain several interactive IDL visualization sessions open on several desktops for days at a time without burning a lot of floating licenses.
All this is changing in IDL 8.6. Below is Harris Corp's response to my inquiry about the new licensing scheme they are rolling out. The bottom line is that if you are using floating licenses, every IDL session will now consume a license. If you have a node-locked license, you get only 4 concurrent sessions.
In my field, astronomy, I fear this will transform the long slow movement away from IDL into a stampede.
-----------------
IDL command line/ IDLDE - 4
Execute compiled save code - 4
IDL Bridge Processes - 16
IDL Task Engine - 1
IDL command-line/ IDLDE - 1
Execute compiled .sav code - 1
IDL Bridge Processes - 8
IDL Task Engine - 1
If you are using a node-locked license and you want to run 12 development sessions of IDL, you will need 3 licenses. If you are using a floating license, it would require 12 licenses to run 12 concurrent IDL development sessions. Another thing to note is that you can use 16 concurrent IDL_IDLBRIDGE sessions using a single node-locked license. Therefore, if you want to run 12 IDL_IDLBRIDGE sessions concurrently on a single system, you would need 1 license with a node-locked license and 2 for a floating license.
I hope that this information will be helpful to you. Please let me know if you have any additional questions or issues. I am happy to help.

Hi Pat & Wayne,

The main goal of the new licensing was to make it easier for people to license the product, and also to plug some holes in our license agreement where people were running servers with hundreds of IDL sessions using just a single node-locked license. So we tried to maintain a balance between giving the typical user enough licenses to get their job done, while not giving away too much. Hopefully in most cases we struck the right balance.

You might try the IDL bridge to see if that could take the place of some of your interactive sessions, especially if you are doing batch processing. It's fairly simple to use:
IDL> x = idl_idlbridge()
IDL> x.execute,'p=plot(/test)'

Anyway, if you find that it doesn't fit your needs, then I would recommend contacting tech support and your sales representative. I can't promise anything (since I'm not on the business side) but they are quick to respond and might be able to come up with some creative licensing solutions.

Cheers,
Chris
IDL Project Lead

[kallisthene]

The question is : Does the use of idl_idlbridge counts as another IDL session ?

Post by Chris Torrence

Post by wlandsman
Pat,
Thanks for alerting us to this. I am not sure that this is actually a change for floating licenses. Currently in our large group, every time someone starts a IDL 8.5 session (command line or idlde) it counts toward our total of 200 licenses. This seems the same as the V8.6 policy.
It does seem to be a change for node-locked licenses. If I want to process 6 data sets at the same time on a multi-core machine, the easiest thing for me is to start 6 IDL sessions, whereas for IDL 8.6 only four sessions would be allowed. Perhaps one can use the IDL_IDLbridge to get around this but it doesn't seem convenient.
-Wayne

Post by Patrick Broos
Prior to IDL version 8.6, on a unix machine (e.g. Mac), a license was required for each unique instance of the triplet (hostname, $USER, $DISPLAY). For example, a single user (with constant $DISPLAY) could run as many concurrent IDL sessions as desired, while consuming only 1 "license". This was extremely useful for data processing on multi-core machines (if the processing was most naturally parallelized via multiple IDL sessions). It was also convenient to be able to maintain several interactive IDL visualization sessions open on several desktops for days at a time without burning a lot of floating licenses.
All this is changing in IDL 8.6. Below is Harris Corp's response to my inquiry about the new licensing scheme they are rolling out. The bottom line is that if you are using floating licenses, every IDL session will now consume a license. If you have a node-locked license, you get only 4 concurrent sessions.
In my field, astronomy, I fear this will transform the long slow movement away from IDL into a stampede.
-----------------
IDL command line/ IDLDE - 4
Execute compiled save code - 4
IDL Bridge Processes - 16
IDL Task Engine - 1
IDL command-line/ IDLDE - 1
Execute compiled .sav code - 1
IDL Bridge Processes - 8
IDL Task Engine - 1
If you are using a node-locked license and you want to run 12 development sessions of IDL, you will need 3 licenses. If you are using a floating license, it would require 12 licenses to run 12 concurrent IDL development sessions. Another thing to note is that you can use 16 concurrent IDL_IDLBRIDGE sessions using a single node-locked license. Therefore, if you want to run 12 IDL_IDLBRIDGE sessions concurrently on a single system, you would need 1 license with a node-locked license and 2 for a floating license.
I hope that this information will be helpful to you. Please let me know if you have any additional questions or issues. I am happy to help.

Hi Pat & Wayne,
The main goal of the new licensing was to make it easier for people to license the product, and also to plug some holes in our license agreement where people were running servers with hundreds of IDL sessions using just a single node-locked license. So we tried to maintain a balance between giving the typical user enough licenses to get their job done, while not giving away too much. Hopefully in most cases we struck the right balance.
IDL> x = idl_idlbridge()
IDL> x.execute,'p=plot(/test)'
Anyway, if you find that it doesn't fit your needs, then I would recommend contacting tech support and your sales representative. I can't promise anything (since I'm not on the business side) but they are quick to respond and might be able to come up with some creative licensing solutions.
Cheers,
Chris
IDL Project Lead

[Patrick Broos]

Chris,

I appreciate your helpful suggestions, and your obvious desire to support your customers.

With your indulgence, I'd like to describe one of my own astronomy data processing tasks. The telescope I work with (the Chandra X-ray Observatory) observes a target in a series of separate observing "segments", separated in time. Various data processing/analysis computations have to be performed on each of those segments. That segment processing is most naturally and efficiently performed using an IDL session for each segment. On a 12-core machine, > 12 such processes can productively run concurrently (depending on the balance of CPU vs I/O activity). The IDL Bridge is not suitable for this processing, for several reasons.

When that single-segment processing finishes, "merging" computations have to run (to combine results from all the segments). This is most efficiently done by another IDL session, which is launched at the outset, then polls to detect the completion of the segment processing, then performs the merge processing.

While all that number crunching is going on, I may have several interactive IDL sessions in the middle of visualization work on several projects. (Astronomers are always working on several targets and/or proposals at the same time.)

While all that's going on, I may be writing/debugging/testing other IDL programs, which requires another IDL session.

The general theme here is that IDL is integral to almost every part of my daily work activities. I need to keep my 12 cores busy, and that requires many IDL sessions. I have multiple on-going data analysis projects, and it's often very helpful to leave several IDL sessions open on separate desktops for days or weeks.

For 25 years, the monetary cost of this sort of IDL-centric multitasking working style for ONE person has been ONE license. Under the new scheme, this sort of IDL-centric multitasking working style is simply not feasible. I have never even been tempted to jump to Python (as most astronomers are doing), but I feel backed into a corner now.

Sincerely,
Patrick Broos

[r***@crd.ge.com]

They also eliminated the "flexible single user" license which allowed me to run IDL on my work machine as well as my home laptop (non-simultaneously). It's still possible, in theory, but not very practical: apparently I'd have to deactivate the license on one machine and activate on the second -- through Harris' application to their server, which my company's IT department doesn't allow.

Note also that you can only transfer your license to a new machine if you have a current maintenance contract with Harris:

"You can only re-host a license if the licenses are current on maintenance."

http://www.harrisgeospatial.com/Support/HelpArticlesDetail/TabId//219/ArtMID/900/ArticleID/14981/Default.aspx

[MSatt]

Post by Patrick Broos
Prior to IDL version 8.6, on a unix machine (e.g. Mac), a license was required for each unique instance of the triplet (hostname, $USER, $DISPLAY). For example, a single user (with constant $DISPLAY) could run as many concurrent IDL sessions as desired, while consuming only 1 "license". This was extremely useful for data processing on multi-core machines (if the processing was most naturally parallelized via multiple IDL sessions). It was also convenient to be able to maintain several interactive IDL visualization sessions open on several desktops for days at a time without burning a lot of floating licenses.
All this is changing in IDL 8.6. Below is Harris Corp's response to my inquiry about the new licensing scheme they are rolling out. The bottom line is that if you are using floating licenses, every IDL session will now consume a license. If you have a node-locked license, you get only 4 concurrent sessions.
In my field, astronomy, I fear this will transform the long slow movement away from IDL into a stampede.
-----------------
IDL command line/ IDLDE - 4
Execute compiled save code - 4
IDL Bridge Processes - 16
IDL Task Engine - 1
IDL command-line/ IDLDE - 1
Execute compiled .sav code - 1
IDL Bridge Processes - 8
IDL Task Engine - 1
If you are using a node-locked license and you want to run 12 development sessions of IDL, you will need 3 licenses. If you are using a floating license, it would require 12 licenses to run 12 concurrent IDL development sessions. Another thing to note is that you can use 16 concurrent IDL_IDLBRIDGE sessions using a single node-locked license. Therefore, if you want to run 12 IDL_IDLBRIDGE sessions concurrently on a single system, you would need 1 license with a node-locked license and 2 for a floating license.
I hope that this information will be helpful to you. Please let me know if you have any additional questions or issues. I am happy to help.

I too am disappointed with the dissolution of the flexible single user license, which allowed me to develop on IDL at work and on a machine at home.

Talking with the licensing folks, the recommendation to undertake a daily deactivation/activation regime is unrealistic. IDL has always been an expensive proposition ... now it feels like significantly less bang for the buck than before.

MSatt

[Chris Torrence]

Hi Patrick, Wayne, et al,

Thank you all for your thoughtful responses. As a long-time IDL user myself (pre-RSI-employee), my workflow remains essentially the same as yours.

Just some background. Sticking with our old licensing code was becoming impossible - it was no longer being actively maintained by our vendor, and we started to see more people abusing it by running IDL on a server for cloud-based computing. The new Flexera software has both advantages and disadvantages. The advantages are an easier licensing process for most customers, less headaches for our tech support group, and more flexibility for splitting licenses among features (such as "main" IDL versus "bridge" versus the "task engine"). The disadvantages are less flexibility on the licensing schemes, such as the "flexible single use", since the licenses are now definitely tied to a particular host. We also needed to make difficult decisions on the feature count, which is what you have unfortunately run up against.

Our overall goal remains the same - make an easy-to-learn, fast, robust language which scientists and engineers can use to find answers in their data. We don't want anything to get in the way of that, including licensing.

Here is my suggestion. If you haven't already contacted Tech Support (or heard back from them), I would strongly recommend emailing ***@harris.com. Include your customer information, including a brief description of why IDL is important in your daily research (just for some context). Also, most importantly, include your specific license requirements, such as "I need to run 12 full IDL processes simultaneously, and it's only for me on my one machine", or "I need to run 1-2 IDL sessions on both my Mac and Windows machines, and I don't want to activate/deactivate and I don't want a hasp dongle."

Tech Support will forward your request on to your sales representative who will most likely ask for more information, just to see if a different license type might be a better fit. In general, if you are making a reasonable request, then we will try to do the right thing, especially for our long-time trusted customers (i.e. you!).

I hope this helps.
Cheers,
Chris

[Chris Torrence]

Hi Patrick, Wayne, et al,

Thank you all for your thoughtful responses. As a long-time IDL user myself (pre-RSI-employee), my workflow remains essentially the same as yours.

Just some background. Sticking with our old licensing code was becoming impossible - it was no longer being actively maintained by our vendor, and we started to see more people abusing it by running IDL on a server for cloud-based computing. The new Flexera software has both advantages and disadvantages. The advantages are an easier licensing process for most customers, less headaches for our tech support group, and more flexibility for splitting licenses among features (such as "main" IDL versus "bridge" versus the "task engine"). The disadvantages are less flexibility on the licensing schemes, such as the "flexible single use", since the licenses are now definitely tied to a particular host. We also needed to make difficult decisions on the feature count, which is what you have unfortunately run up against.

Our overall goal remains the same - make an easy-to-learn, fast, robust language which scientists and engineers can use to find answers in their data. We don't want anything to get in the way of that, including licensing.

Here is my suggestion. If you haven't already contacted Tech Support (or heard back from them), I would strongly recommend emailing ***@harris.com. Include your customer information, including a brief description of why IDL is important in your daily research (just for some context). Also, most importantly, include your specific license requirements, such as "I need to run 12 full IDL processes simultaneously, and it's only for me on my one machine", or "I need to run 1-2 IDL sessions on both my Mac and Windows machines, and I don't want to activate/deactivate."

Tech Support will forward your request on to your sales representative who will most likely ask for more information, just to see if a different license type might be a better fit. In general, if you are making a reasonable request, then we will try to do the right thing, especially for our long-time trusted customers (i.e. you!).

I hope this helps.
Cheers,
Chris

[Chris Torrence]

Hi Patrick, Wayne, et al,

Thank you all for your thoughtful responses. As a long-time IDL user myself (pre-RSI-employee), my workflow remains essentially the same as yours.

Just some background. Sticking with our old licensing code was becoming impossible - it was no longer being actively maintained by our vendor, and we started to see more people abusing it by running IDL on a server for cloud-based computing. The new Flexera software has both advantages and disadvantages. The advantages are an easier licensing process for most customers, less headaches for our tech support group, and more flexibility for splitting licenses among features (such as "main" IDL versus "bridge" versus the "task engine"). The disadvantages are less flexibility on the licensing schemes, such as the "flexible single use", since the licenses are now definitely tied to a particular host. We also needed to make difficult decisions on the feature count, which is what you have unfortunately run up against.

Our overall goal remains the same - make an easy-to-learn, fast, robust language which scientists and engineers can use to find answers in their data. We don't want anything to get in the way of that, including licensing.

Here is my suggestion. If you haven't already contacted Tech Support (or heard back from them), I would strongly recommend emailing support<AT>harris.com. Include your customer information, including a brief description of why IDL is important in your daily research (just for some context). Also, most importantly, include your specific license requirements, such as "I need to run 12 full IDL processes simultaneously, and it's only for me on my one machine", or "I need to run 1-2 IDL sessions on both my Mac and Windows machines, and I don't want to activate/deactivate."

Tech Support will forward your request on to your sales representative who will most likely ask for more information, just to see if a different license type might be a better fit. In general, if you are making a reasonable request, then we will try to do the right thing, especially for our long-time trusted customers (i.e. you!).

I hope this helps.
Cheers,
Chris

[superchromix]

Post by Patrick Broos
Prior to IDL version 8.6, on a unix machine (e.g. Mac), a license was required for each unique instance of the triplet (hostname, $USER, $DISPLAY). For example, a single user (with constant $DISPLAY) could run as many concurrent IDL sessions as desired, while consuming only 1 "license". This was extremely useful for data processing on multi-core machines (if the processing was most naturally parallelized via multiple IDL sessions). It was also convenient to be able to maintain several interactive IDL visualization sessions open on several desktops for days at a time without burning a lot of floating licenses.
All this is changing in IDL 8.6. Below is Harris Corp's response to my inquiry about the new licensing scheme they are rolling out. The bottom line is that if you are using floating licenses, every IDL session will now consume a license. If you have a node-locked license, you get only 4 concurrent sessions.
In my field, astronomy, I fear this will transform the long slow movement away from IDL into a stampede.
-----------------
IDL command line/ IDLDE - 4
Execute compiled save code - 4
IDL Bridge Processes - 16
IDL Task Engine - 1
IDL command-line/ IDLDE - 1
Execute compiled .sav code - 1
IDL Bridge Processes - 8
IDL Task Engine - 1
If you are using a node-locked license and you want to run 12 development sessions of IDL, you will need 3 licenses. If you are using a floating license, it would require 12 licenses to run 12 concurrent IDL development sessions. Another thing to note is that you can use 16 concurrent IDL_IDLBRIDGE sessions using a single node-locked license. Therefore, if you want to run 12 IDL_IDLBRIDGE sessions concurrently on a single system, you would need 1 license with a node-locked license and 2 for a floating license.
I hope that this information will be helpful to you. Please let me know if you have any additional questions or issues. I am happy to help.

This is a scary change. I will ask our IT department to avoid upgrading to IDL 8.6 until there is more clarification on this.

I and the other IDL users in my department are constantly using multiple IDL sessions on our desktops, launched via the VM. If these are now going to take up one license each, IDL will cease to be a feasible solution for us.

Mark

[superchromix]

I still can't get my head around this. How does this change make any sense? If I am an IDL licensee, with IDL installed on my desktop, I should be able to run multiple IDL programs simultaneously. So called "Multi-tasking" as been a standard feature of most operating systems since the early 1990s! Moreover, with IDL's already very limited support for multi-core / parallel operation, for some applications the only reasonable approach is to run multiple sessions.

I would like to see some movement from Harris on this.

[superchromix]

The only reason my institution purchases IDL licenses is to support the code that I write, and distribute to other users in my department. If this change makes the number of licenses we would need go through the roof, then the users who supported IDL for years are being completely screwed over.

[Patrick Broos]

Superchromix, thank you for raising this issue in your institution. I also have invested man-years of labor developing a large IDL application that is distributed to users (both in our department and at dozens of other institutions). The most natural workflow for this application involves multiple IDL sessions---50 or more for some projects. I never dreamed that the fundamental licensing rules, in place for 25 years or more, would be so radically changed.

I will attempt to conduct my own science projects using IDL 8.5.1 until I retire. However, the users of my application at other institutions will often have no control over the version of IDL provided at their institution.

This change in the language, without community input, is fodder for those who advocate "open source" languages (e.g. Python) and criticize commercial languages (e.g. IDL). No doubt, Harris Corp. knows their market far better than I do, but I just don't see how this helps them preserve or expand their customer base.

[Chris Torrence]

Hi all,

Just to re-emphasize, Harris needs to hear from you:
-----
If you haven't already contacted Tech Support (or heard back from them), I would strongly recommend emailing ***@harris.com. Include your customer information, including a brief description of why IDL is important in your daily research (just for some context). Also, most importantly, include your specific license requirements, such as "I need to run 12 full IDL processes simultaneously, and it's only for me on my one machine", or "I need to run 1-2 IDL sessions on both my Mac and Windows machines, and I don't want to activate/deactivate."
-----

[Helder]

Hi,
there is another thing that I find discomforting. Until now, I could write code, produce a .sav file and give it to "users" that would download IDL and run the code with the VM. At the moment only licensed users can download IDL.

I already mentioned this problem to Harris Tech Support. I'll keep you updated if anything changes.

Cheers,
Helder

Post by Chris Torrence
Hi all,
-----
-----

[superchromix]

Post by Helder
Hi,
there is another thing that I find discomforting. Until now, I could write code, produce a .sav file and give it to "users" that would download IDL and run the code with the VM. At the moment only licensed users can download IDL.
I already mentioned this problem to Harris Tech Support. I'll keep you updated if anything changes.
Cheers,
Helder

Post by Chris Torrence
Hi all,
-----
-----

Is this true? Distributing code for use with the VM is a fundamental part of the IDL model. If Harris were to change this, I hope they would at least let the userbase know.

[Helder]

Post by superchromix

Post by Helder
Hi,
there is another thing that I find discomforting. Until now, I could write code, produce a .sav file and give it to "users" that would download IDL and run the code with the VM. At the moment only licensed users can download IDL.
I already mentioned this problem to Harris Tech Support. I'll keep you updated if anything changes.
Cheers,
Helder

Post by Chris Torrence
Hi all,
-----
-----

Is this true? Distributing code for use with the VM is a fundamental part of the IDL model. If Harris were to change this, I hope they would at least let the userbase know.

I contacted tech support about this and the response was:
"We are currently working on a way to make IDL VM available without having a license, since this affects several of our customers."

So my guess is that this was an unwanted consequence of the new licensing system and it's going to get "fixed" one way or another. Until they have a solution, 8.6 is for me useless.

Cheers,
Helder

[wallabadah]

It might also be worth noting that the lmgr() function has been decimated, presumably related to the change in licensing model.

From IDL 8.5 online help:

Result = LMGR( [, /DEMO | , /EMBEDDED | , /RUNTIME | , /STUDENT | , /TRIAL | , /VM] [, EXPIRE_DATE=variable] [, /FORCE_DEMO] [, INSTALL_NUM=variable] [, LMHOSTID=variable] [, SITE_NOTICE=variable])

and from IDL 8.6:

Result = LMGR( [/RUNTIME | , /VM])

One of my applications uses the LMHOSTID return variable to check it's being run by a registered user... which is no longer possible in 8.6. It was a neat way of finding out the MAC address of the host, and I'm sure I wasn't the only one using it....

looking for a solution,

Will.

[Helder]

Post by wallabadah
It might also be worth noting that the lmgr() function has been decimated, presumably related to the change in licensing model.
Result = LMGR( [, /DEMO | , /EMBEDDED | , /RUNTIME | , /STUDENT | , /TRIAL | , /VM] [, EXPIRE_DATE=variable] [, /FORCE_DEMO] [, INSTALL_NUM=variable] [, LMHOSTID=variable] [, SITE_NOTICE=variable])
Result = LMGR( [/RUNTIME | , /VM])
One of my applications uses the LMHOSTID return variable to check it's being run by a registered user... which is no longer possible in 8.6. It was a neat way of finding out the MAC address of the host, and I'm sure I wasn't the only one using it....
looking for a solution,
Will.

Hi Will,
thanks for reporting this. I was doing the same exact thing: using lmgr to check the mac address and validating that.
Nooooooo!
Why remove the function if it is not used by IDL licensing software? We had access to it and we used it for our own licensing!
Great!
I'll write tech support.
H.

[Helder]

Post by Helder

Post by wallabadah
It might also be worth noting that the lmgr() function has been decimated, presumably related to the change in licensing model.
Result = LMGR( [, /DEMO | , /EMBEDDED | , /RUNTIME | , /STUDENT | , /TRIAL | , /VM] [, EXPIRE_DATE=variable] [, /FORCE_DEMO] [, INSTALL_NUM=variable] [, LMHOSTID=variable] [, SITE_NOTICE=variable])
Result = LMGR( [/RUNTIME | , /VM])
One of my applications uses the LMHOSTID return variable to check it's being run by a registered user... which is no longer possible in 8.6. It was a neat way of finding out the MAC address of the host, and I'm sure I wasn't the only one using it....
looking for a solution,
Will.

Hi Will,
thanks for reporting this. I was doing the same exact thing: using lmgr to check the mac address and validating that.
Nooooooo!
Why remove the function if it is not used by IDL licensing software? We had access to it and we used it for our own licensing!
Great!
I'll write tech support.
H.

It seems like the only workaround will be retrieving the mac address using spawn and some string handling:
windows: "getmac" eventually with options /FO csv or /FO list
linux (debian as su): ifconfig | grep HWaddr

At list there is some workaround, but still lmgr() was much easier to manage.

And what drives me *** is the lack of backward compatibility. If somebody installs 8.6, I can't ask them to run older software because the lmgr would fail.

Cheers, Helder

[superchromix]

OK, I spoke with our IT department, and they have agreed 1. Not to upgrade to IDL 8.6 and 2. To send negative feedback to the sales contact.

[kallisthene]

Post by superchromix
OK, I spoke with our IT department, and they have agreed 1. Not to upgrade to IDL 8.6 and 2. To send negative feedback to the sales contact.

Unfortunately this move makes it more difficult to use Python in IDL code, since they have to code themselves the dll to communicate with new versions of Python.
It is always possible to install old Python installs but it's less straightforward.
IMHO the Python gamble they took is the cheapest and easiest way to include a matlab-like variety of advanced functions. At the price of a complexity of installation as well of coding, we are still only one or two among our group using this solution ...