Hi,

It appears that the "You are running A-Shell in Support Mode" message continues to be displayed from jobs that initially exceeded the number of licensed nodes, even if many users disconnect and the number of nodes in use visible by typing "ABOUT" is less than the licensed number of nodes.

I was wondering if this could be tweaked?

We are running A-Shell Linux: 6.5.1684.4

Thanks,
John Andreasen
Diversified Data Solutions

Good point. Obviously the mode flag is getting set once but never gets updated. I'll add that to the list...

In the meantime, feel free to purchase additional licenses!

OK, thanks Jack.

Its not normally a big issue as most of our customers have more than enough licenses. We have one that just has barely enough and is difficult to convince to buy more.

We use OPTIONS=RIGID (cant find it in ashell help) in the miame.ini to completely stop anyone logging in at the first place if they exceed the maximum license. Maybe annoying for them!, but still some live with it and spend hours yelling around the office asking others to log out rather than save some productivity time and buy more.

Thanks for the info Steve. I didn't know such an option existed. We may end up needing to turn that on for them.

I guess we didn't document it so that users wouldn't discover and remove it?

Ah one those top secret commands ! I’ll not mention the other ones ..
Must admit be nice change the default message with in Ashell , currently I think it’s hard coded with bad luck all licenses in use please phone jacks or Ty’s personal cell phone with your wallet at hand

(If you have not seen the real message it really says something like: please contact your software house otherwise microsabio on xxxxx)

Steve, I like your message better. I think we'll change to that.

John this may be helpful: There is also a no-cost license option* where we can set the license to "strict," which accomplishes the same thing but at an un-defeatable level--i.e., neither you nor the customer can change it with miame.ini settings. We put this in several years ago for a (very good!) customer who wanted to make sure that his end-users didn't abuse the flexibility of our normal license.

* although there is no charge for the "strict" option, there may be a admin charge for generating a new license with only such a change.

Hey Ty, that is good to know and we'll consider it. If we decide to try to activate this option, we may start out with the INI option as it would be easy to turn off if we do have issues with it.

Hi,

I think we may have uncovered another issue. It appears that if XCALL MIAMEX,MX_SETUSRNAM is used to change the username on an existing job and a new instance of ATE is opened from the same machine, it is initially counted as two nodes. Running ABOUT/R from another job causes it to be counted as one.

John - You have to pay a premium for that feature

Ah, I see Frank. I did not realize

Sorry for the delayed response here. I've traced this down to a deliberate bit of code that limits the licensing sharing to instances with the same user name and IP. Normally that would be more than reasonable, but in this case, I guess it seems overly rigid. (The theory behind it is that just because two clients share the same IP, doesn't mean that they are necessarily the same workstation. Any remote workgroup connecting over a WAN is likely to share the same IP.) Unfortunately, it would be rather inefficient to have to probe the other user to see if we could determine the real login name after it has been changed.

But what we could do is detect that they have the same MAC address. I'll revise that logic in the next update. (In the meantime, Frank's solution is always a possibility!)

Wait, now I remember why the MAC and IP address tests are subservient to the user/console-id tests: because of the environment where users connect to an intermediate server (e.g. RDP to a Windows Server) and then ATE from there. Those connections would all have the same IP and MAC address, but would be distinguished by the login name. I'll have to ponder it further ...

I implemented a compromise in 6.5.1690.2 to allow a 2nd session in this situation ...


ash65notes.txt
ash-6.5.1690.2-el5-upd.tz
ash-6.5.1690.2-el7-upd.tz

Hi Jack,

Thanks for the fix. I didn't realize all the different situations you have to account for with the license counting. We'll test this out a bit and deploy it.