MKS Toolkit vs. Lawson Unix Utilities - Major problem

It's a microsoft issue, LUU/the Microsoft SUA is not able to run sh. Tim Butzier from lawson confirmed it to me a while back. Last I checked, they were waiting for a fix from Microsoft... so basically any programs that invokes from sh, don't work with LUU.

I do know the upgrade programs must use MKStoolkit, the upgrade programs do not work with LUU.

Thanks, Jimmy.

I currently have a case open with GSC but they so far have been unable to identify the problem.  But I'm keeping them on the hook because we need to get off of MKS ToolKit.  The licensing required for MKS Toolkit is simply unacceptable.

Do you have any details on the incompatibility issue?  I'm very interested in hearing more.

FYI:
IAN-90x-102701-01
Release Date: October 27, 2009
Status: Required
Title: Lawson Unix Utilities and MKS Toolkit
Description:
Customers wishing to use Lawson Unix Utilities:
Lawson has discovered a technical flaw with Lawson Unix Utilities (LUU) upon installing or upgrading Lawson deliverables through Lawson Interface Desktop (LID). The problem that could be encountered as a result of this technical flaw will only occur during the installation and is not impacted at runtime except for running 'sh' commands through LID.
Resolution:
Customers must use MKS to perform the installations and upgrades of Lawson deliverables. After installs and /or upgrades are complete, you can convert to Lawson Unix Utilities by enabling Microsoft SUA and then installing Lawson Unix Utilities. For details, see the Lawson Unix Utilities Installation Guide. Lawson Unix Utilities can be used for all runtime commands except for running 'sh' commands through LID.
Distribution:
This Installation Alert is being sent

FYI: a clip from my CASE a year ago.

Mar 15, 2010 0:18 PM Tim Butzler To CUSTOMERUSER
Hi Jimmy Chiu, my name is Tim Butzler and I will be working on your request from here. I want to take a minute to review your support request and any prior dialogue.

Mar 15, 2010 0:19 PM Tim Butzler To CUSTOMERUSER
Hi Jimmy, Do you have the programs under UG system code in pgmdef?

Mar 15, 2010 0:19 PM CUSTOMERUSER To EOUSER
I have UG00, and UG999

Mar 15, 2010 0:19 PM Tim Butzler To CUSTOMERUSER
Send me your Install.log again from ugsrc. It's not installing your upgrade programs then.

Mar 15, 2010 0:20 PM CUSTOMERUSER To EOUSER
XXXXXXX blanked out the links

Mar 15, 2010 0:23 PM Tim Butzler To CUSTOMERUSER
Are you on Windows?

Mar 15, 2010 0:23 PM Tim Butzler To CUSTOMERUSER
Are you using MKS or LUU?

Mar 15, 2010 0:23 PM CUSTOMERUSER To EOUSER
LUU

Mar 15, 2010 0:24 PM Tim Butzler To CUSTOMERUSER
That's not supported for upgrades. Your installs won't work with LUU it's required to have MKS when installing Upgrade programs. That is why your programs won't compile as LUU has an issue with scripts that use a loop. There is a critical notification on this.

Mar 15, 2010 0:25 PM CUSTOMERUSER To EOUSER
... what is my option then?

Mar 15, 2010 0:30 PM CUSTOMERUSER To EOUSER
yeah I just read the critical notification. LUU can be used for all command EXCEPT "sh" which is the case here.

Mar 15, 2010 0:30 PM Tim Butzler To CUSTOMERUSER
Yea, so we need to switch to MKS to install and run the upgrade programs as UG00 and UG99 both have sh scripts we run as well then change it back to LUU once the upgrade is done.

Mar 15, 2010 0:32 PM CUSTOMERUSER To EOUSER
So i can just install MKS "for now" then run the upgrade install? Do I need to switch to the "mks" setting in the laconfig setting?

Mar 15, 2010 0:33 PM Tim Butzler To CUSTOMERUSER
Yes, you would need to switch that in laconfig then stop/start everything so it takes affect.

Mar 15, 2010 0:34 PM Tim Butzler To CUSTOMERUSER
You need to use MKS for the entire upgrade process not just the install.

^^^ apparently there are scripts that don't work with LUU also during runtime, thus, they need me to use MKS thru the whole upgrade process.

Mar 15, 2010 0:40 PM CUSTOMERUSER To EOUSER
I knew I should just use MKS instead of LUU.. ok thanks.

^^^ paying > freebie

Mar 15, 2010 0:41 PM Tim Butzler To CUSTOMERUSER
It's actually a Microsoft issue for LUU not being able to run sh so we're waiting for a fix from them.

^^^ i don't think the fix is here yet a year later.

Mar 15, 2010 0:50 PM CUSTOMERUSER To EOUSER
ok

I ran into the same upgrade issues as well with needing to use MKS Toolkit to run upgrades. I have done upgrades last year and this year and there is no way to do them with out MKS just like Jimmy said. I cannot believe Lawson forced users to switch to something they can not use for every purpose. I guess they did not want to pay the licensing for MKS any longer either. I would say if you have an application upgrade in your future than you will want to have at least a couple of licenses for MKS.

Here's the problem with using MKS:

The MKS Toolkit license specifically states that "At no time shall the total number of installed copies of the Software or the total number of Users exceed the number of licenses for which you have paid a license fee."

 

In essence, you must purchase an MKS license for each and every user of your Lawson system.  You cannot just purchase one license of MKS for your server and then turn your users loose on the system.

 

That's how Lawson gets around by saying that you can use MKS Toolkit for the installation of your environment since you typically only have one person on the system doing the install.  However, before you place your system into production, you must first remove MKS Toolkit and install the Microsoft Utilities for Unix / LUU.  That is, if you want to remain in compliance with your licensing agreement with MKS (assuming you purchased a single license of MKS).

 

Now imagine a Lawson environment that has 2000+ users.  Can you imagine the cost of 2000+ MKS licenses?

 

I think this is why Lawson came out with the LUU product.  However, the problem is that if you use Lawson's EDI and/or the PO module, you are forced to stay on MKS as LUU will not work with these Lawson components.  Lawson insists this is a Microsoft issue. 

 

This has put large Lawson clients in between a rock and a hard place.  Lawson has known about this issue for at least 16 months and say they are "actively" working with Microsoft. 

I don't know that I agree. I think it's a single user--lawson. I think the reason for LUU is that it removes a licensing hurdle for Lawson considering LSF uses very basic MKS functionality. =

It's actually Lawson plus anyone else that needs shell access. Ran into this exact problem but we were able to successfully go back mks versions that don't enforce the named user license

Sent from my iPhone

On Feb 17, 2011, at 4:45 PM, forums-lsf-s3-sys-admin@lawsonguru.com wrote:

>
>
> S3 Systems Administration Forum Notification
>
> A message was posted to a thread you are tracking.
>
> Re: MKS Toolkit vs. Lawson Unix Utilities - Major problem
> Posted by: John Henley
> 02/17/2011 04:31 PM
> I don't know that I agree. I think it's a single user--lawson. I think the reason for LUU is that it removes a licensing hurdle for Lawson considering LSF uses very basic MKS functionality. =
> You may reply to this thread via e-mail; please do not remove the message tracking number from the subject line, and do not include this message in your reply. To view the complete thread and reply via your browser, please visit:
> https://www.lawsonguru.co...ities-major-problem/
>
> You were sent this email because you opted to receive email notifications when someone posted and/or responded to a message on this forum.
> To unsubscribe to this thread please visit your user profile page and change your subscription options.
>
> Thank you,
> LawsonGuru.com

John - I did have MKS come back and tell me specifically that I had to have an MKS license for every user accessing the system.

George - Something occurred to me about your post. Are you saying that you are using an older version of MKS Toolkit with your environment? If so, would that also mean that your environment is not supported by Lawson?

I'm just trying to look for a solution.

You don't really have a choice in my opinion.

Your lawson app doesn't work with LUU, it's a simple fact.

You need MKS to make it work.

MKS requires you to buy the 2000+ license.

Unless lawson can rewrite the codes to skip the shell access part. You are stuck.

Posted By Jimmy Chiu on 02/23/2011 10:39 AM
You don't really have a choice in my opinion. 

This is just bizarre. Lawson made a strategic decision to use a Unix emulation layer (MKS) in order to bring their product to market on the Windows platform faster rather than write it directly using Windows APIs (this was done way back in version 7.x).  MKS has always been the requirement.  Lawson is saying the client has always had a direct licensing relationship with MKS, and you really don't have to use MKS--you can use LUU, provided it works for you (it should work for some clients already on 9.0.1).

Here are some links from Lawson's support site regarding this:
Lawson S3 Third-Party Product Notice – MKS Toolkit Replacement Options
Lawson S3 Third-Party Product Notice – MKS Toolkit Licensing
Lawson Unix Utilities / Microsoft SUA and MKS Toolkit update Notice

Unfortunately, the notices that John posted above simply do not provide the whole story. If you are using Lawson EDI and/or using any applications that invoke 'sh', LUU will simply not work and you are forced to stay on MKS.

I still have my support case open with GSC and they are trying to create an environment matching mine in an effort to duplicate the problem.  However, based on past experience, I do not have very much confidence in them.

What, roughly, is the per user licensing cost that MKS wants?

When I last renewed my MKS Toolkit license, the cost was $479 per user.

Did MKS offer you concurrent user licenses?

For MKS 9.2 I am seeing a single user license on the MKS website for $479 and 5 user license for $2,225 which is $445 per user. For more users it says to just contact sales.

There is a note that for support of Windows 7 and Server 2008 R2 we may need MKS Toolkit 9.4. The note also states that 9.4 is not availble for sale on the MKS webstore. So I am not sure of what to make of that.

We are using version 9.2.0200.

And I don't think the issue is with "named" users. The MKS license agreement specifically states "User(s) means any individual who from time to time uses the Software..." "At no time shall the total number of installed copies of the Software or the total number of Users exceed the number of licenses for which you have paid a license fee. At no time shall generic logins be used that allow multiple Users under one license."

We have not yet opened a dialog with MKS to see if they offer concurrent user licenses.

Now, I'm not a lawyer so I don't fully understand what excactly a user is. For example, none of my users connect to MKS directly (they are not executing scripts, running shells, etc.), they are simply Lawson users and the Lawson software makes the necessary calls to MKS. So does that mean that my Lawson users are basically also MKS users "by proxy"? If that is the case, then I need 2,500+ licenses for MKS which is absolutely ridiculous.

My support case is still open with GSC and they tell me they are still trying to create an environment to test ED501 / ED502 to see if they can duplicate the problem. They are moving excrutiatingly slow for a priority 2 support case, but that's another story.

When I went to the MKS website the FAQ for 9.2 states that it is Named users. I have not looked at how MKS licensed 9.2 in the past. Assuming MKS offers a volume discount of say around $400 per user that would be over $200,000. A discount to $40 per user would get us to over $20,000. Not good numbers.

From my understanding the problem of Lawson and MKS is as follows:

MKS licensing requires that you either license each named user of MKS or you can buy unnamed (max concurrent) licenses. If you have 2000 users and you want each user to have a named license you would have to buy 2000 named licenses. But if only 200 are active concurrently out of your 2000 users then you could buy 200 (max conncurrent) unnamed licenses. The named licenses are around $400+ each and the unnamed licenses are around $1200+ each. After the first year, you will have to pay yearly maintenance for each license if you wish to do be able to upgrade to newer MKS versions, etc. Yearly maintenance for named licenses is around $100+ each and for unnamed licenses around $400+ each. Please note the costs are approximate.

The MKS licensing model discussed above has been true for all MKS versions, MKS 8.x, MKS 9.1, MKS 9.2, MKS 9.3, and MKS 9.4.

Before MKS 9.3, there was not a way for MKS to know how many users were actually using MKS. MKS 9.3 and MKS 9.4 began using a new activation method which can determine user and license use. That is when it was discovered by MKS that Lawson does not use only use one MKS license for the Lawson userid as we have all been told, but actually each Lawson end-user uses MKS when accessing Lawson and therefore requires a license.

This leaves us Lawson/MKS customers between a rock and a hard place. We can either pay MKS to license each user as required, or we can remove MKS and use the Lawson provided LUU replacement product instead of MKS. You must be on at least Windows 2003 R2 SP2 to use LUU. You must be on at least LSF 9.0.0.8 or LSF 9.0.1.5 to use LUU. Other requirements can be found at Lawson site.

As mentioned in other posts above, LUU has some problems. If it doesn't work for you then you have to use MKS and deal with the licensing cost. We are planning on moving off MKS immediately. It is not because we don't like MKS, but because we feel the licensing costs are exhorbant. If the cost per license was reasonable, we would have stuck with MKS.

Fred - Thanks very much for sharing that information. At least it confirms what I've been saying all along: Either go with LUU and deal with the problems that option presents or go with MKS Toolkit and deal with the licensing costs.

Either way, it's a very tough decision that we have to make. I hope that other users of Lawson are aware of these challenges so that they can make appropriate and educated decisions regarding their own ERP implementations.

Fred, you are correct in much of what you outlined in your 03/03/2011 05:45 PM posting.

For now, let me please offer feedback on 3 topics:


1) MKS Toolkit is licensed on both an Installation and a User basis.

2) MKS and Lawson customers using MKS Toolkit have been placed “between a rock and a hard place”.

3) What can MKS offer in an effort to help?


More on each topic below -


1) MKS Toolkit is licensed on both an Installation and a User basis.


I happen to have a copy of the MKS License Agreement for MKS Toolkit, version 8.5, in a folder that I keep containing 10+ years worth of MKS License Agreements.

Here are two excerpts from the version 8.5 MKS License Agreement:

"'User(s)' means any individual who from time to time uses the Software, provided that any individual who permanently ceases to use the Software may be replaced by another individual and such replacement shall not be considered a separate User for purposes of this Agreement."

“if you Install the Software on a network, client/server arrangement or any computer configuration which permits more than one User to have access to the Software, you have first paid for a license or for a separate copy of the Software for each additional User.”

I also have another MKS License Agreement for which I do not know the version, but it has a Windows "Date Modified" stamp of 9/17/1999 10:58 AM, and it too has the language above. And, I know that MKS Toolkit version 8.0, which you referenced in your posting, was released January 14, 2002.

Therefore, with confidence I can offer that the MKS License Agreement clearly stated that MKS Toolkit is licensed per User since at least 1999, and since at least version 8.0, without asking MKS Legal for even older files.


2) MKS and Lawson customers using MKS Toolkit have been placed “between a rock and a hard place”.


Lawson customers are between a rock and a hard place for at least 2 reasons:

A) The technical issues noted above.

B) Moving from MKS Toolkit to LUU does not remove the legal obligation to pay for what you used, at peak use of MKS Toolkit.

MKS is between a rock and a hard place for at least 2 reasons:

A) By adding programmatic license compliance to our products, and then hearing from Lawson customers who tried to run their Lawson server(s) from a single node locked, "Named User" license of MKS Toolkit that had programmatic license compliance, MKS learned that Lawson customers are and have been over using our intellectual property for years.

B) Have you ever had the responsibility of informing someone that they are out of compliance with the License Agreement that they accepted at installation? Have you ever had the responsibility of having to ask them to please pay for their over use, especially when Lawson recently offered a free replacement option? Have you ever been blamed for something, when you were innocent? Would you like to step into my shoes for a day?


3) What can MKS offer in an effort to help?


First, we hope that folks reading this post can appreciate that asking MKS to only be compensated for 1 User, if you have > 1 User using MKS Toolkit, is not fair. Also, please appreciate the fact that had MKS been able to confirm that our product was being over used prior to our release of MKS Toolkit with programmatic license compliance, we would have reached out to you sooner, and we would have refused to accept any additional orders from Lawson, the moment that this issue had been confirmed.

Second, while MKS can offer Named User licenses, our offer below is based upon Concurrent Use licenses. From working with other Lawson customers, it would seem that Concurrent Use is a better and more cost effective fit for most.

Here is what we are currently offering:

A) MKS is willing to offer Lawson customers who are willing to work with us toward license compliance, a no charge, temporary Concurrent Use license of MKS Toolkit, at the latest version, for each of your Lawson servers (Dev, Test, Prod, Back-up/Disaster Recovery, etc.).

B) MKS is willing to set the initial number of Concurrent Users for each respective use license of MKS Toolkit to whatever reasonable number a customer requests. We should pick a number that is a little above what you think is required, in an effort of avoiding interruption to your hard working employees.

C) Once installed, MKS can then either increase or decrease the number of Concurrent Users depending upon what your users are experiencing.

For instance:

- If one or more of your employees using a Lawson server receive a warning that there are no unused licenses of MKS Toolkit, we can increase the count by 1 or 2 Concurrent Users, and see what happens.

- If none of your employees using a Lawson server receive a warning that there are no unused licenses of MKS Toolkit, we can - decrease - the count by 1 or 2 Concurrent Users, and see what happens.

The goal of the no charge evaluation licenses being to help us only ask you to invest in a number of MKS Toolkit Concurrent Use licenses, which represents actual use patterns, for each of your Lawson server types. And, once we know how many Concurrent Use, MKS Toolkit licenses you need, MKS will provide a quotation for the same.

In addition, MKS is also currently offering:

A) A trade-in credit for all of your current MKS Toolkit use licenses for which Maintenance is active, at list price, toward Concurrent Use replacements.

B) A discount - I will ask MKS to allow me to offer you a discount, on the balance due after your trade-in credit.

Why is MKS making this offer?

From working with other Lawson customers MKS has come to the conclusion that their over use of our intellectual property has been unintentional, as none seem to have knowledge concerning how Lawson products use MKS Toolkit "under the hood", especially at runtime, just as MKS had no idea that our products were being over used for the same reason.

Therefore, attempting to step into your shoes, we again are currently offering no charge evaluations, a trade-in credit, and a discount, to all Lawson customers who are willing to do the right thing, by working with MKS to move to license compliance, when it comes to your installation and use of MKS Toolkit.

Thank you for reading this post.

Please let me know if I can be of service.

Rick.Willhite@mks.com
703-803-4366

Rick, thanks for sharing MKS' side of the story. I'm proud that lawsonguru.com can provide this type of open communication forum. I agree that the over-use of MKS is obviously unintended, as I was myself always under the impression that the licensing was aimed at the Lawson service, not the number using the service. In other words, a single user not hundreds or thousands. Clearly an eye-opener. =

If concurrent license are allowed then I think we can actually get by with just a few. The only problem is Open Enrollment which only happens once a year. Open Enrollement is only open about 30 days and because it is only a once a year event there is no way to estimate concurrent usage. Rick, sorry but your solution of waiting for the system to error out really isn't going to work for an event like Open Enrollment. I guess since Open Enrollement doesn't happen till year end that should give Lawson time to fix LUU or for us to figure out a work-around. Should we look into work-arounds or do people think Lawson will fix LUU by say about September?

Response to: John Henley, 03/04/2011 06:23 PM

John,

We are in complete agreement that Lawson customers who use Lawson S3 products, and now find that they are over using MKS Toolkit, seem to have gotten into this position unintentionally. And, because we are in agreement, MKS is offering the concessions outlined in our 03/04/2011 05:05 PM posting.

However, now that all of us know that there is an issue, I hope that we can also agree that the next step that folks decide to take can only be described as intentional.

It is MKS' sincere hope that all Lawson S3 product customers will now intentionally choose to work with MKS as a team, in a positive and cooperative manner, to move to license compliance under the MKS License Agreement.

Thank you again for offering the LawsonGuru.com as an open communications forum, enabling MKS to share our thoughts.

Rick Willhite
Rick.Willhite@mks.com
703-803-4366

Response to: Jay Riddle, 03/07/2011 03:45 PM

Jay,

We should probably take the specifics of your unique situation off-line and direct. That said, if I am following you correctly, let me at least make some suggestions which I hope that you might appreciate.

I assume that Open Enrollment is a time during which you folks see a large spike in use of your Lawson systems. If this is the case I would have no issue asking MKS to work with your organization in two steps. Those steps being actions taken "Now" and then actions taken before/during/after "Open Enrollment". Here's more on these ideas:

1) Now

For now we can move you to version 9.4, and a hand full of Concurrent Use licenses of MKS Toolkit, so that at least we know that you folks are compliant under your non-Open Enrollment use. We could still start with no charge temporary licenses to size things, and then only ask you to buy what you need Now.

2) Open Enrollment

Perhaps a few weeks before Open Enrollment MKS can substitute your paid for license of MKS Toolkit for another set of no charge evaluation licenses, but this time we will turn the number of Concurrent Users up to a much larger number that you folks pick.

If you have the ability to simulate multiple users, to a load similar to what you typically experience during Open Enrollment, we can attempt to better prepare for the real thing, etc.

And, once the real Open Enrollment hits, we can adjust your temporary no charge licenses up even higher if needed, while Open Enrollment takes place.

Our request in exchange for this being that once Open Enrollment is over, your organization would agree to invest in whatever peak Concurrent User number we found was needed during Open Enrollment, while you were using no charge temporary licenses.

I hope that you find this fair or at least close enough to it that you consider working through the details with us.

Thank you for your response!

Rick Willhite
Rick.Willhite@mks.com
703-803-4366

John,
Can you or anyone else confirm that your issues with Lawson Unix Utilities are resolved?  Are you using the LUU utilities now or MKS Toolkit?

According to Lawson, the first two issues are resolved and they do not show any reported issues with the third issue (see below).

1)  The EDI application runs, it is just that the exam logs do not get updated, the messaging appears in the ED04 application program instead.  The job situation described is configuration related.  IAN-90X-102709-01 explains that issues on install and upgrades or nested sh scripting - JT 184053.

2)  PO20 with FAX Path message, there is an application CTP (71905) that resolves this situation.

Our issues have not yet been resolved. The CTP 71905 is massive, consisting of over 1,600 files. In our case, over 260 programs in Asset Management, Accounts Payable, General Ledger, Purchase Orders, and Requisitions would be updated. With all the departmental testing we'll have to do, we might as well do an application upgrade!

GSC is telling us we would also need to upgrade our EDI from version 9.0.1.1 to 9.0.1.3.

I'm just waiting on my users to complete some testing on our test environment before I install the CTP and EDI upgrade for testing.

If MKS is looking to have Lawson customers determine the number of concurrent users, is a survey of DBUSERS -n taken periodically over the course of say a month the best way to determine this number?

JY,

Please see my posting dated: 03/04/2011 04:05 PM.

MKS is offering no charge temporary evaluation licenses of Concurrent User MKS Toolkit, to help with the exact topic which you have mentioned.

Why?

Only Lawson knows exactly when, how, why, how often, etc. MKS Toolkit is used by their products at runtime. Lawson customers and MKS could all waste a lot of time trying to guess at answers to these questions, and we could still be wrong.

So, instead of guessing, MKS is offering no charge temporary evaluation licenses of MKS Toolkit to help Lawson customers confirm their actual MKS Toolkit use, instead of guessing, so that all who work with MKS in a cooperative and professional manner, are only asked to invest in what they actually need to move to compliance under the MKS License Agreement.

MKS is also offering a trade-in credit for your older valid copies of MKS Toolkit, currently covered under MKS' maintenance program, and which will be replaced with Concurrent User licenses, as well as a discount.

Please let us know if we can be of service.

Rick Willhite

Let me first say that we received this scare tactic email from MKS and were totally outrage!! It appears that MKS is no longer a partner with LWSN and because of that, MKS is threatening all LWSN clients who are on windows with this ridiculous request.

We had an old version of MKS 9.0 and no where in the license agreement that is delivered in the box that MKS comes in, talks about how they license their product. So MKS comes out with their new release, changes how they are licensing their product and now is forcing loyal LWSN clients to pay through the nose for licenses.

This Rick Willhite who sends out the emails, is trying to bully us into believing that LWSN has been "over using" MKS licenses. He makes these unbelievable assumptions on how he thinks LWSN is using MKS, when he can not tell us how MKS changed their software that constitutes a use of license.

Last, and most important, we have never dealt with such an unprofessional person as when we had to deal with this Rick Willhite. He was extremely rude to us and when we asked what his role is at MKS, he would not tell us. Also if you look at your email you received from him, he does not put any type of title. We finally had to engage our corporate counsel into this discussion and once we applied a little pressure to the individual, he changed his tone and backed down on the licenses issue.

BillW,

Thank you for your posting!

Please take a look at Section 2, just under subsection 2.1.3, of your version of the MKS Program License Agreement (PLA), which shipped with MKS Toolkit version 9.0.

You will see the following verbiage:

"if you install the Software on a network, client/server arrangement or any computer configuration which permits more than one User to have access to the Software, you have first paid for a license or for a separate copy of the Software for each additional User"

"At no time shall the total number of installed copies of the Software or the total number of Users exceed the number of licenses for which you have paid a license fee."

Please show this to your lawyer.

Also, if your lawyer contacted me, and I have not yet replied, this is due to the fact that Lawson has left MKS with around 300 Lawson customers, who use MKS Toolkit to support Lawson products on Windows, and all seem to have license compliance issues. I just finished my first attempt to contact all Lawson customers who use MKS Toolkit, just a few days ago. I am now looping back to respond a second time.

MKS' first goal and hope is that folks will simply work with us to move to compliance, because it is the right thing to do. Our hope is that we do not have to get MKS legal involved.

It's funny how your tone has changed a little and how you still have not answered any of the questions that were directed to you. What is your role at MKS? Also, since most of us in this particular topic are technical people, please explain, in technical terms, with your new release, how MKS considers a use of a license?

If you can not, then stop posting to this topic and stop sending emails with your assumptions on how LWSN is using MKS. In my mind you have very poor business tatics and who would ever want to deal with a company like MKS, that is only trying to scare people into purcahsing more licenses than they really need.

BillW,
Please tone it down.

Rick's tag line says "Lawson Account Manager, MKS Software, Inc."

Your outrage should be directed at LWSN, not MKS. As I've stated before, Lawson made a strategic decision to use a Unix emulation layer (MKS) in order to bring their product to market on the Windows platform faster rather than write it directly using Windows APIs (this was done way back in version 7.x). In doing that, Lawson made MKS an inherent requirement for running their software, just like Micro Focus COBOL.

What's happening is that, with the most recent MKS release, MKS started tracking number of licensed users for running their product, and is now understanding that Lawson is using a single-user MKS license inappropriately (and unethically if not illegally, but I will leave that to legal interpretation). When MKS approached Lawson about this, they responded by issuing their own LUU alternative.

What MKS is simply trying to re-coup their lost license revenue--even if you switch to LUU and/or accomodate those customers who can't switch to LUU.

I think this is an issue where MKS' management/legal team should work directly with Lawson's management/legal team to resolve, and should not be dragging their respective clients into the matter.

John, there are some parts of your response that I agree with, but please explain to me in technical terms how "Lawson is using a single-user MKS license inappropriately (and unethically if not illegally"

I'm a technical person and I need to understand. I would not have problem paying for add'l licenses, but I need an explaination.

Ok,
Before the tone of this gets too inflamatory, I will finally chime in. I believe I was the very first person to find this issue, period. I contacted Rick in March 2010 as I first started dealing with this in 2008 R2. With that said, I have the most familiarity with the exact causes and history of the issue.

A little history:
Lawson began the port of the environment in 1995, and I believe it was released in 1996/1997 at version 7.0.8. At that time, the developer in question used MKS *on his workstation* as it was pretty much the only emulation game in town. The intended uses were to replace the 'fork/exec' functionality required for a multi-process/single threaded application running on a predominately multi-threaded OS (at that time Windows NT 4.0 Server/EE).

What appears to happen from my close observation of the threads at that time (since I used the next release of it) is that when Lawson created their own protocol to access the system (lainetd), they essentially created a poor-mans Citrix/Terminal Services stack. That stack bypassed the appearance of multi-user access on the server. On the backend, laserv_scm (the Services Control Manager interface for laserv) allowed for some forks to be hidden as one named user access.

From the MKS side, they used the honor system in their license manager. In fact ALL companies did this (anyone old enough will recall the Microsoft KB Article that just said disable the License Service to stop getting checked on NT 4.0 EE). Lawson still does this with licsta and portal access (HINT: EXPECT THIS TO CHANGE...SOON). The name of the game was shipping more units, not more licenses of a unit.

About SUA:
SUA is a product Microsoft purchased (vis-vis buying all of Interix) in 2004 and mothballed. It has nearly NO support, since Microsoft's stated goal at that time was to starve the Linux interop market by taking the biggest players off the market. At the same time MKS refocused themselves as an Enterprise SCM vendor, and interop wasn't a huge drive to the business (acquisitions of SCM players were).

This strategy failed for MS, so they realized that they needed to basically give away the older Interix products as an interop offering to give the appearance of value-add. (I think EU anti-trust lawsuits I'm sure helped)

Landscape today:

Lawson has rewritten much of the multi-process interactions, as threads of a set of master processes, but a few things (such as job executions) still rely on fork/exec. Also most Lawson command line functions (aka LID) and all CGI's are stubs to an MKS (and optionally an LUU) executable.

Due to this, the same as 15 years ago is true today, you still need a UNIX emulation layer to fully use Lawson on Windows, until Lawson decides to take bin-utils from a *NIX distro and static compile their own, AND take a freeware POSIX subsystem and roll their own. That's not likely to happen EVER.

You will use an MKS license EVERY SINGLE TIME the app makes a PSIX library call...PERIOD. That's how Lawson uses SUA or MKS.

Now for my thoughts on this whole fiasco:
NOTE: I am not blasting ANYONE in this section, as I have worked with all parties involved, at great detail to help resolve the issues.

As for Lawson:
1) There is NO WAY that their timing was a coincidence. They saw that MKS was enforcing the licensing, and that the writing is on the wall for their clients. They had to release an alternative...fast.

2) They had to have been FULLY aware that there was multiple usage since you can see it NOW. Have any two users log into LID, and run 'ls'. Period.

As for MKS:
1) I believe Rick is outside sales. MKS is a Canadian company (I have an apartment in the same town as they and RIM).
2) I agree that Rick has been a tad forceful, but after a very very long conversation with him, he's rightfully upset. If he's outside sales, he personally gets a commission. Imagine being cheated for 15 YEARS of rightful revenue? Even if he isn't commissioned, there is no doubt he has a bonus structure that would tie to performance.
3) Rick is caught in a nasty appearance issue with the Lawson end-client. Lawson punted ALL responsibilities for this issue (it's the reason MKS is the ONLY product you had to by DIRECTLY from MKS...hint hint)
4) Due to #3, the value of the offering is undervalued by the Lawson client. The issue here is, while you expect to pay BSI (if you have payroll), you don't expect to have to pay MKS for something you don't see, doesn't increase end-user ROI, and most clients are too small to need/use outside of Lawson.

Advice:
- To Rick:
You shared with me the pricing for concurrent licenses. I think you may want to rethink it using a tiered structure due to the size of a Lawson *Windows* client. Contact me offline (you have the number) on my specific details.

- To Lawson:
1) INDEMNIFY YOUR CLIENTS!!! IBM did in the SCO case...
2) Fix the following issues in LUU
    a) Provide a WORKING alternative to ksh
    b) fix the sporadic issues with ls and grep
        (eg: grep will not accept the $ sign as the end of a line)

- To The clients:
1) Be pissed at Lawson. They either were too negligent or too lazy to test their own product, and set proper expectations.

2) Force them to fix their half baked LUU products. ksh doesn't work correctly (this is a problem with SUA actually, and has been for 8 years, this very issue was why *I* personally ditched it on my non-Lawson work)

BLAST YOU JOHN! I was typing this as you replied! :-)

Thanks, Kwane. Great explanation.

John and Kwane, thank you very much for the unsolicited feedback!

BillW, I'll do my best to respond to your postings.

First, to be honest I did not see "questions" for me in your first post. I saw statements.

Therefore, when you suggest that "you still have not answered any of the questions that were directed to you" I find this a little bit confusing.

However, in your second posting, I do see some questions, so I'll do my best to respond to them:

1) My Role at MKS

To be honest, I do not understand your fixation with my job description / role at MKS, nor its relevance to the topic at hand. Whether I happen to be CEO, CIO, a VP or a Janitor, if the way that Lawson has designed their product could be making your employees over use your single User license of MKS Toolkit, without their even knowing it, I hope that we can agree that this might be an important topic to investigate.

Also, I am finding it a challenge to remember the conversation that you suggest that we had in the past, when you list your name as BillW and when you offer so little for the name of your employer. If you look at my first posting: 03/04/2011 04:05 PM, I offered my full name, full company name, my telephone number, and my role with MKS as it relates to this topic. I even picked a LawsonGuru user name of “Rick with MKS” so that anyone/everyone would know exactly who I am and who I work for if they read my post and/or decide to communicate with me, yet it would seem that you feel that I am hiding something.

The above considered, I will offer additional feedback because it seems so important to you. I am a Business contact for MKS. I cover the US and Canada, and I manage all large, complex and non-standard business for MKS' Unix to Windows migration and Interoperability products, which includes MKS Toolkit. And, since Lawson provided a copy of MKS Toolkit with their products since the 1990s, I have been MKS' Lawson Account Manager for years. But, Lawson is not my only account.

2) User

You seem to be suggesting that the definition for "User" when discussed in the context of license compliance is a technical topic. I believe that the definition for "User" is more of a legal topic, when being used for license compliance. You also seem to be suggesting that MKS' definition for "User" has recently changed. I disagree with this position.

Not wanting to make this statement without backing it up, here is a copy/paste for the defined term "User" from the oldest copy of the MKS License Agreement that I have on my laptop - the Word file containing this License Agreement has a Windows "Date Modified" stamp of 9/17/1999:

"’User(s)’ means any individual who from time to time uses the Software, provided that any individual who permanently ceases to use the Software may be replaced by another individual and such replacement shall not be considered a separate User for purposes of this Agreement"

I believe that the above is almost identical to the definition for "Users" in the version 9.0 MKS License Agreement that your employer accepted when MKS Toolkit was installed. You'll find the definition for "Users" in Section 1, ‘Definitions’ about 3/4 of the way down, assuming that you are still looking at a version 9.0 MKS License Agreement.

3) Technical

What MKS simply called MKS Toolkit back before 2000, is now called MKS Toolkit for Developers, but I'll keep calling it MKS Toolkit for simplicity in this response.

MKS Toolkit consists of approximately 400 Windows .exes which implement Unix commands, Unix utilities, and Unix shells on Windows.

Here is an alphabetized listing of the components:
http://www.mkssoftware.co...ds.asp?product=tkdev

4) How does Lawson use MKS Toolkit?

If you desire a detailed, comprehensive, and accurate technical description for what portions of Lawson’s products use MKS Toolkit, when Lawson products use MKS Toolkit, how often Lawson products use MKS Toolkit, etc., I have no issue admitting that only Lawson can offer what you are requesting, and that I cannot.

If I offered you and/or others that you work with feedback in this area, I was quoting what other Lawson customers have shared with me, as they for instance ran their Lawson system with a version 9.4 Named User license of MKS Toolkit, and then attempted to use typical and normal features and functionality of their Lawson products, things that their employees use daily, attempting to determine what portions of the Lawson products seem to be using MKS Toolkit. If I did not make this clear, please accept my apology.

What I do know is that we could all invest a lot of time and energy trying to find answers to these questions, and without Lawson's help, we probably would still not know all of the ways that Lawson products use MKS Toolkit at runtime.

This is one of the reasons why, as outlined in my 03/04/2011 04:05 PM posting, MKS is offering no charge temporary evaluation licenses of MKS Toolkit to all Lawson customers who are willing to work with us in a positive and professional manner, to move to compliance under the MKS License Agreement.

Instead of taking my word for the fact that MKS Toolkit is used by > 1 User at runtime in a typical Lawson configuration, MKS is willing to offer Lawson customers a no charge temporary evaluation Named User MKS Toolkit license so that you can confirm things at your facility, and on your servers.

Instead of guessing how many MKS Toolkit use licenses a Lawson customer requires for compliance and to run properly, MKS is willing to offer Lawson customers no charge temporary evaluation software, either Concurrent User, Named User, or both, to allow folks to confirm what is needed for each of their Lawson server types (Production, Development, Test, etc.) on their own, and in their environment.

In short, instead of guessing, MKS is offering to allow the programmatic license compliance code in MKS Toolkit version 9.4 to help us.

BillW, I hope that I have answered your questions. I regret it very much if we got off to a rough start, and I hope that we can find a way to work in a more productive manner moving forward.

Please let me know if I can be of service.

Sincerely, Rick Willhite
703-803-4366
Rick.Willhite@mks.com

Kwane,

Do you know if ESS hits the Toolkit? What about MSS? In my conversations with Lawson, all I got was that they were not AWARE of any ESS/MSS usage with the Toolkit.

With the LUU, Lawson could avoid accountability hiding behind " It's a Microsoft problem" until the world crumbles.

I think MKS would be wise to consider a site license model with some sort of routine headcount reporting for adustments. I can't imagine a core user in a healthcare environment being locked out of Lawson becuase some employee is updating their address. If ESS/MSS users are to be counted ( and in some shops even without them ), it seems that under a named or concurrent user model there's a price point at which an organization would just dump Windows and move to UNIX.

RalphL,

Concerning your ESS/MSS question -

How about installing a single User no charge temporary evaluation license of Named User MKS Toolkit, version 9.4, then start up a LID session, since every single Lawson customer that we've worked with and heard from has told us that LID takes a MKS Toolkit license. Next, try to start up ESS and MSS to see what happens. Kwane, John Henley, and others may have other and/or better ideas. I am far from a Lawson expert. I am simply attempting to try and help in a way that MKS can.

Concerning your MKS licensing suggestion -

Please remember that MKS is attempting to help fix a problem that we did - not - create. Like Lawson customers, MKS is a victim of inadequate detail concerning how MKS Toolkit is used by Lawson products at runtime. With just a little honest feedback from Lawson, both Lawson customers and MKS could have / would have made more intelligent decisions, years ago.

Yet, MKS is offering:

1) No charge temporary evaluation licenses of MKS Toolkit, to help Lawson customers only pay for what they are actually using;

2) A list price trade-in credit for all of your older MKS Toolkit licenses that are currently covered under MKS' Maintenance/PCS program; and

3) A substantial discount, after the trade-in credit, for your correctly sized license, which for most still seems to be moving to Concurrent User licenses.

My point, with the above, MKS is offering assistance which meets Lawson customers more than half way, and we are receiving zero assistance from Lawson. We are also taking a lot of heat for an issue that we did not create, and then being asked to give even more.

Does there ever come a time when folks might consider asking Lawson to contribute to the situation that they created, due to lack of communication, instead of only suggesting additional ways that MKS can give more?

For instance, if the list price for MKS Toolkit Concurrent User licenses for a particular Lawson customer came to $40,000, but after trade-in credit and a discount MKS was offering to grant the same block of licenses for under $20,000, why would it be so unreasonable to ask Lawson to accept $10,000 less for that customer’s annual maintenance renewal, as a one time contribution? Just a thought.

Please let me know if I can be of service.

Sincerely, Rick Willhite
Rick.Willhite@mks.com
703-803-4366

Ralph,
It's dicey. I had a conversation with Rick on this very issue. Portal seems to make calls that would mimic some uses of fork (the cgi programs, as instantiated via CgiRunner come to mind), and thus could be an issue.

One one hand, EMSC does NOT run jobs, but it does run CGIs. I'll take time this week to determine what's happening, when I can audit a client's running system.

As for the costs, and jumping to UNIX directly: That's the big issue over all. MKS has a perception issue Lawson left them with, in the way of how the end client sees the value of the product. Since no one knows exactly how it's being used (short of a decompile, which is illegal in this sense...except in the EU), the client can't quantify the fair value. The post by Rick@MKS on the size of the sample discount is about as much as you'd expect anyone to give up. Essentially they are parting with TOP-LINE revenue...

I also agree with Rick on this one. Lawson should pony up a portion of their maintenance revenue for a year to help make clients whole.

The numbers themselves aren't easy to swallow. Doing a site license wouldn't work for MKS, because the reality is clients would want that site license for nearly nothing, and if they didn't, it's not realistic for MKS to negotiate between 300-800 specific site license agreements.

In fact that's why Lawson is having issues now, because they don't know who has what contract in place, since almost all the contracts where special licenses for each and every client.

What will complicate this is the fact that Lawson is looking to be bought. If MKS choices to raise the issue as litigation, it's going to get sticky for Lawson to explain away 5-14 years of license discrepences.

Kwane/Rick,

Thanks for the quick response. Hope you're mixing in some March Madness! Rick, not suggesting that MKS is not doing enough. Just looking for a solution that would not pose the risk of breaking a production system. To that end...Kwane, would it be possible to perhaps isolate non-critical users on a separate concurrent use license while ensuring that the core users ( on a concurrent use license of their own ) would never be denied service? Maybe a separate jvm for self service. I"m with you both that Lawson should own some of this.

Ralph,
No. I asked Rick this question, and if I understood his response to me, you can NOT mix named and concurrent licenses. The system is either in full concurrent mode or full named user mode.

Now with that said, you are essentially referring to license affinity. Depending on the algorithm used by the license tracking system in MKS, this may not be an issue. The reason is, the core two users (the Lawson laserv process owner, and whatever WebSphere is running as) should be using a license perpetually, and the system should never release those locks. Also I believe that a user can run a nearly infinite number of processes, since the license is by user and not processor, so the core two users (or one if you run WAS and Lawson laserv as the same account) will always function.

NOTE: In NO case can that user be BUILTIN\System (S-1-5-18), Local Service (S-1-5-19), Network Service (S-1-5-20), or BUILTIN\NETWORK (S-1-5-2). Presumably it this prohibition also includes ANY SID that is S-1-5-x, where x is from 0 to 20 inclusive. This implies that ALL standard Lawson installations that have the laserv process running as Local Service, using MKS, are NOT correctly configured per MKS license requirements. The reason for this is that laserv could spawn an MKS utility via any Win32 API or emulated POSIX call. I don't know if the license racking system catches this, but it's still a violation of the license all the same.

It gets tricky from here, since the next license need to be for the person installing the system initially, or the system Admin. That person has to have LID access (currently), and thus needs access to the utilities.

It is possible to install MKS AND LUU at the exact same time, AND get them both to work for different parts of the system, but it's evil hard, and is not supported by Lawson. I was forced to do this on a DEV system for a client to get them the ablility to test LUU, and still having a running environment (using MKS).

On the personal note:
I got a little NCAA action in, I watched the Butler vs Florida game (I'm from Indiana, and I live in Florida now, so I was just watching for entertainment)

my problem is that Lawson will not or can not tell me how many licenses we need, i have no idea what programs need MKS. Why will not Lawson tell me?

Because Lawson doesn't truly know themselves. They don't seem to do QA testing with license compliance in mind, and they haven't provided MKS with the ability to do this testing for themselves, as they seem to have done with BSI (a payroll tax calculation package)

Kwane

All,

I've been reading for a while and it is interesting to me that everyone is complaining about the issue and nobody is resolving the issue.

A few months back Kwane and I had a long conversation about the issues (it was during an upgrade on a new Windows 2008 Server) with MKS. We talked about using LUU/SUA for those calls to the Windows system within the programs and how to resolve the issues.

I spent some time finding the differences in how LUU/SUA works with the system call and rewrote the upgrade scripts. I can't give you all the details here, but I do know for a fact that MKS is NOT REQUIRED to run Lawson. Since Lawson is not stepping up to the plate to resolve the issue(s) seemed like the logical thing to do was fix it myself...

Since this Lawson stuff is more of a hobby then work for me ;-) and I volunteer my time coordinated by Bill Mitchell it would be best to contact him to set up time with me. Bill can be reached at 530.889.8550. If you know me and have my number and/or email feel free to contact me directly.

Well, surf's up - gotta go

Todd

Todd,
I just saw this post. I'm glad to see it. I didn't want to post that you had made progress, until you felt it was a done deal. I see that you have.

Rest of the Community,
As Todd mentioned, I had a long conversation on this issue, and he did put a good deal of effort into fixing the core scripts (and I think with some persuation, he might be willing to fix the issue with the ED3xx start/stop jobs also).
I didn't feel as though I had the time, so I personally decided to wait for Todd to work the magic, and come up with a solution.
I'd highly suggest that anyone interested call Bill to see if the solution meets your need.

DISCLOSURE: This would mean your upgrade would be technically outside of supported bounds, but since it's a one time thing, and you'd have to validate the outputted data, this may not be an issue for your organization.

Kwane

Does the 5/19 Critical Notice regarding Microsoft hot fix for LUU resolve the issues mentioned in this post? We are looking to moving to LUU and this particula post is concerning. We use HR & Finance Suite on 9.0.1.7 with EMSS & Process Flow, Windows 2008 64 bit.

Very interesting thread. I'm left with several questions about my own environment...
I'm currently on 9.0.1.x on both app and env. We only run the financial package. and only portal (with LID only used for administration and the occasional debugging of issues).
Questions:
1) What are the issues being reported with LUU? Is it just on the upgrade, or certain modules?
2) What is all involved in switching to LUU at this point? How major of an undertaking are we talking about?
3) I've read about the uncertainty of the number of licenses needed. I don't want to take the trial and error method that MKS is presenting, as that seems like a pretty risky way of figuring out exactly what is needed. Any ideas what I need for a strictly portal/financials environment? one for each web user? one for each system account I may be using?
4) has anyone made any progress in gettng Lawson to "own up" to their portion of the licensing issue as of yet?
Brian Hynes

Very interesting thread. I'm left with several questions about my own environment...
I'm currently on 9.0.1.x on both app and env. We only run the financial package. and only portal (with LID only used for administration and the occasional debugging of issues).
Questions:
1) What are the issues being reported with LUU? Is it just on the upgrade, or certain modules?
2) What is all involved in switching to LUU at this point? How major of an undertaking are we talking about?
3) I've read about the uncertainty of the number of licenses needed. I don't want to take the trial and error method that MKS is presenting, as that seems like a pretty risky way of figuring out exactly what is needed. Any ideas what I need for a strictly portal/financials environment? one for each web user? one for each system account I may be using?
4) has anyone made any progress in gettng Lawson to "own up" to their portion of the licensing issue as of yet?
Brian Hynes

Brian,
Since you are on 9.0.1.x it should not be a concern.
It really only affects the upgrade from 8.0 to 9.x, 9.0.0 to 9.0.1 and a very small chance it could affect some scripts with EDI.
It is only an installation of LUU and MS SUA and should only be a couple hours max for you to perform.
Not sure on the users but think it is a per user of Lawson basis.
No, have not heard of Lawson owning up to it.
Hope this helps. Let me know if you need anything else.
Bill Mitchell
530.889.8550

Since you are on 9.0.1.x it should not be a concern at all.

It really only affects the upgrade from 8.0 to 9.x, 9.0.0 to 9.0.1 and a very small chance it could affects some scripts with EDI.

It is only an installation of LUU and MS SUA and should only be a couple hours max to perform.

Not sure on the users but think it is a per user of Lawson basis.

No, have not heard of Lawson owning up to it.



Bill Mitchell

Kastle Consulting



530-889-8550

bill.mitchell@kastleconsulting.com



”One’s destination is never a place but rather a new way of looking at things.” - Henry Miller



From: forums-lsf-s3-sys-admin@lawsonguru.com [mailto:forums-lsf-s3-sys-admin@lawsonguru.com]
Sent: Monday, June 13, 2011 2:21 PM
To: bill.mitchell@kastleconsulting.com
Subject: RE: MKS Toolkit vs. Lawson Unix Utilities - Major problem [00008417:00015892]




S3 Systems Administration Forum Notification


A message was posted to a thread you are tracking.


RE: MKS Toolkit vs. Lawson Unix Utilities - Major problem


Posted by: brihyn
06/13/2011 03:09 PM


Very interesting thread. I'm left with several questions about my own environment...
I'm currently on 9.0.1.x on both app and env. We only run the financial package. and only portal (with LID only used for administration and the occasional debugging of issues).
Questions:
1) What are the issues being reported with LUU? Is it just on the upgrade, or certain modules?
2) What is all involved in switching to LUU at this point? How major of an undertaking are we talking about?
3) I've read about the uncertainty of the number of licenses needed. I don't want to take the trial and error method that MKS is presenting, as that seems like a pretty risky way of figuring out exactly what is needed. Any ideas what I need for a strictly portal/financials environment? one for each web user? one for each system account I may be using?
4) has anyone made any progress in gettng Lawson to "own up" to their portion of the licensing issue as of yet?
Brian Hynes

_____

To view the complete thread and reply via your browser, please visit:
https://www.lawsonguru.co...ies-major-problem/3/

You were sent this email because you opted to receive email notifications when someone posted and/or responded to a message on this forum.
To unsubscribe to this thread please visit your user profile page and change your subscription options.

Thank you,
LawsonGuru.com

brihyn,
I read Bill's reply, and he is spot on for all four points.

The further answer #3, there are a few ways you can calculate it, but MKS's method isn't trail and error. What's happening is they give you a decent number of time locked licenses, and see what your actual usage cap is.

This is NO different than what Lawson themselves did for the apps in LID. There is a column in 'licsta' that allows you to go over, and then they give you 30 days of license overage run time (eg: the grace period), and then they lock you down.

Their issue is that they never adapted that for portal usage. This may change with the new owners, because I know *I* would if I were them.

This is STILL how MicroFocus does it now, except on a server basis, and how BSI is starting to, again on a server basis. License compliance is becoming mandatory, and no longer on the honor system.

Pay-for-usage and pay-as-you-go (aka SaaS model) is where it's all going.

...but I digress

Now to beverly,
Not exactly. There are TWO issues here. One is a technical one, the other is a legal one.

The technical one:
SUA's implementation of several UNIX tools is weak, at best. This creates major issues for any script that expects proper POSIX compliance, and correct operation. Specific examples are as follows:
1) 'ls -1' does not always produce a single column list. At times (randomly) it will act exactly as 'ls'. This can botch programs that need to parse the single column.
2) 'ksh' doesn't always properly pass file handles, output through pipes, etc. Again, this can break scripts that are otherwise coded correctly.

This affects LUU, since Lawson really is stub calling the backend binaries. This is mainly done so Lawson can hide the location differences between implementations. Essentially they are virtualising.

Personally, it would have been easier if they would have picked up a copy of bin-utils, and static complied them, or made cygwin a third option, but again, I digress...

Now, the legal issue:
When MKS switched from the honor system, to a strict named user licensing model, the long taken as truth "you only need one license" was proven untrue. at that point, MKS realized they had between 10-15 years of de facto violations of license agreement, because Lawson has had a Windows port since 1996.
MKS had to at that point decide how to proceed. Since Lawson has never *directly* sold MKS, they were off the hook *directly*, so MKS is faced with the same question SCO was...do they go after EVERYONE, big or small, or do they make a peace offering. They essentially went with the peace offering, since they realised clients didn't *intentionally* violate the license agreement, because no one really knows how Lawson uses the tools, and how that usage has changed internally over the last 15 years.

The key is this: MY UNDERSTANDING OF THEIR INTENT (I'm NOT Rick or MKS legal), is that MKS is agreeing to waive the 'legal' issue by rectifying the licensing issue for the present usage. In exchange, they are solving your 'technical' issue, since MKS is THE number one SUPPORTED UNIX interop, and has been for almost two decades (if memory serves me well).

Now with that said, if you choose NOT to agree to their peace offering, the legal waters get messy, and as I'm NOT a lawyer, I can't speculate one what happens. What I do know is they *do* have a legal leg to stand on, but against whom (the client or Lawson), I do not know.

It's even tricker, since MKS was just acquired by PTC, and Lawson is being acquired by Infor (et al).

Personally, with the generous discounts, it's not worth the potential legal wrangling. But I'm not the client, so that's just my high level view on it all.

Just remember, even if you switch to LUU *now*, you don't resolve the *past* violations, only any future infringement. It would take a lawyer to review Novell vs SCO vs IBM (the closest case I can think of), to see how this would play out in the extreme case lawsuit were filed.

If anyone has any questions, feel free to contact me on it off-topic.
Kwane

I agree wholeheartedly with Kwane's comments (they do say great minds think alike, right? ) :).

In particular, I would add that if you do ANY scripting at all or use EDI, do not use LUU. You are wasting your time and not saving your organization any money.

If you do switch to LUU, you are rolling the dice with regard to past legal infringement. Sometimes it's easier to just pay up--whether you're right or wrong--and move on.

From: forums-lsf-s3-sys-admin@lawsonguru.com [mailto:forums-lsf-s3-sys-admin@lawsonguru.com]
Sent: Wednesday, June 15, 2011 09:30 PM
To: John Henley
Subject: RE: MKS Toolkit vs. Lawson Unix Utilities - Major problem [00008417:00015935]

[LawsonGuru.com Logo]<https://www.lawsonguru.com/>
S3 Systems Administration Forum Notification
A message was posted to a thread you are tracking.
RE: MKS Toolkit vs. Lawson Unix Utilities - Major problem
Posted by: Kwane McNeal
06/15/2011 10:30 PM
brihyn,
I read Bill's reply, and he is spot on for all four points.

The further answer #3, there are a few ways you can calculate it, but MKS's method isn't trail and error. That's happening is they give you a decent number of time locked licenses, and see what your cap is.

This is NO different than what Lawson themselves did for the apps in LID. There is a column in 'licsta' that allows you to go over, and then they give you 30 days of over run time, and then they lock you down.

Their issue is that they never adapted that for portal usage. This may change with the new owners, because I know *I* would if I were them.

This is STILL how MicroFocus does it now, except on a server basis, and how BSI is starting to, again on a server basis. License compliance is becoming mandatory, and no longer on the honor system.

Pay-for-usage and pay-as-you-go (aka SaaS model) is where it's all going.

...but I digress

Now to beverly,
Not exactly. There are TWO issues here. One is a technical one, the other is a legal one.

The technical one:
SUA's implementation of several UNIX tools is weak, at best. This creates major issues for any script that expects proper POSIX compliance, and correct operation. Specific examples are as follows:
1) 'ls -1' does not always produce a single column list. At times (randomly) it will act exactly as 'ls'. This can botch programs that need to parse the single column
2) 'ksh' doesn't properly pass file handles, output through pipes, etc. Again, this can break scripts coded correctly otherwise.

This affects LUU, since Lawson really is stub calling the backend binaries. This is mainly done so Lawson can hide the location differences between implementations. Essentially they are virtualising.

Personally, it would have been easier if they would have picked up a copy of bin-utils, and static complied them, or made cygwin a thrid option, but I digress, again...

Now, the legal issue:
When MKS switched from the honor system, to a strict named user licensing model, the long taken as truth "you only need one license" was proven untrue. at that point, MKS realized they had between 10-15 years of de facto violations of license agreement, because Lawson has had a Windows port since 1996.
MKS had to at that point decide how to proceed. Since Lawson has never *directly* sold MKS, they were off the hook *directly*, so MKS is faced with the same question SCO was...do go after EVERYONE, big or small, or do I make a peace offering. They essentially went with the peace offering, since they realised clients didn't *intentionally* violate the license agreement, because no one really knows how Lawson uses the tools, and how that usage has changed internally over the last 15 years.

The key is this: MY UNDERSTANDING OF THEIR INTENT (I'm NOT Rick or MKS legal), is that MKS is agreeing to waive the legal issue by rectifying the licensing issue. In exchange, they are solving your 'technical' issue, since MKS is THE number one SUPPORTED UNIX interop, and has been for almost two decades (if memory serves me well).

Now with that said, if you choose NOT to agree to their peace offering, the legal waters get messy, and as I'm NOT a lawyer, I can't speculate one what happens. What I do know is they have a legal leg to stand on, but against whom (the client or Lawson), I do not know.

Personally, with the generous discounts, it's not worth the potential legal wrangling. But I'm not the client, so that's just my high level view on it all.

Just remember, even if you switch to LUU *now*, you don't resolve the *past* violations, only any future infringement. It would take a lawyer to review Novell vs SCO vs IBM, to see how this would play out in the extreme case a lawsuit were filed.

________________________________

To view the complete thread and reply via your browser, please visit:
https://www.lawsonguru.co...ies-major-problem/3/

You were sent this email because you opted to receive email notifications when someone posted and/or responded to a message on this forum.
To unsubscribe to this thread please visit your user profile page and change your subscription options.

Thank you,
LawsonGuru.com

Thanks for the information. I do realize that we need to legally pay for past years usage, and that's only fair to Rick and MKS. However I'm also doing my own due-diligence to make sure I provide the correct information to the people within my organization making the decisions, and after going through our original contract with Lawson, we need to have our own dialog with our sales rep before jumping to pay this un-budgeted expense. This is not at all to say that MKS is not owed money for their product, however I only learned of the scope of this isue last week when perusing LasonGuru to resolve my own separate MKS licensing issue.

My real issue is how I want to proceed going forward. At this point, my own discussions with Rick have been nothing short of showing that MKS (or at least Rick, as a representative of MKS) is not willing to provide the support we paid for on a separate license of their software for an entirely separate installation of the software. Again, I realize that licensing fees are owed to MKS, however my requests for support have been completely ignored, or, when not ignored, directly refused. And as a result, if I can avoid this level of non-support in the future without issue, as well as remove one piece of non-lawson software in the behemoth that is a lawson system, all the better.

But I digress. Back to the issue at hand..I'm working to build a new Lawson system (as I have on and off for the past 6-8 months). Will LUU be sufficient for a brand new installation to get all of the Lawson installations completed?

Brian,

This is perhaps not the best place for this discussion, but you have left me no option but to respond.

You contacted MKS and told us that you are receiving a message indicating that you have exceded the maximum number of activations, on a single Named User license of MKS Toolkit.

And, instead of deactivating this license from the current machine and then activating it on the new machine:

http://www.mkssoftware.com/docs/activation/

Which would have avoided your contacting MKS, you are asking MKS to "reset" the serial number so that it can be activated, for a "final time".

Then, while I was looking into your question, I receive two emails containing LawsonGuru.com posting to this topic - date/time stamps: 06/13/2011 03:09 PM and 06/13/2011 03:26 PM, and in both you are stating:

"I don't want to take the trial and error method that MKS is presenting"

While you are also asking questions about moving to LUU.

Your words made me think back to your request to "reset" your single Named User license for an additional activation, because you are receiving an activations exceeded notice.
 
As well as your comment for a "final time"

I ask myself how might this be the "final time" that you will need to activate this license? 

I come to the conclusion that you - might - be planning to use MKS Toolkit to install LUU, and you then you plan to remove MKS Toolkit for good - before - you have taken care of your organization's likely past and current MKS Toolkit over use issues, and while you also "don't want to take the trial and error method that MKS is presenting".

Finally -

I offered a second option to settle for likely past and current MKS Toolkit over use, that would not require our "trial and error method" and received no response to this idea.  But, I did receive another request from you to reset your license. 

So, I then asked for something in writing, from someone who can legally represent your organization, confirming that you folks will continue to work with MKS to cover for likely past and current over use of MKS Toolkit, in trade for my assistance.  To date I received no such confirmation. 

Brian, I am happy to cooperate, in return for cooperation.

Sincerely,

Rick Willhite
703-803-4366
Rick.Willhite@mks.com

Brian,
Concerning LUU:
- Lawson Installation: Technically, yes
- Operation: Possibly, *unless* you need to run an App upgrade, EDI, FaxIntegrator, PFI, or custom scripts.
- LID Users: Probably not more than one or two

To beverly,
I got around to installing LUU on a test system today, and I did notice a very undocumented feature (or I just missed the documentation). Lawson has rearchitected LUU to have the ability to point to ANY UNIX InterOp, including both CygWin and potentially statically compiled GNU bin-utils.

I don't think they intend to allow clients to deploy it yet, but it's not too difficult to get it to work, as is.

Kwane

Rick-
As to continue taking our conversation out of the public forum, I have replied directly back to you again. I do ask that, if you continue to doubt that I am working on two entirely separate issues (one being your licensing needs, the separate being the need of a named-user reset), I simply ask you to search for all posts here on LawsonGuru that I have made. You will see that I have been working on building a new Lawson system since last fall, Working to try to create some form of documentation. As such, I have removed and reinstalled every piece of software many times, to the point of starting from scratch with an OS reload.
As for the final time question, as you see in my email, I need to know how to simply back up the licensing information (I believe there must be a way to create a license.dat file?) so that if I need to reload yet again, which seems pretty likely, the MKS licensing portion of my reinstall at least won't be an issue.

Finally, a huge thank you to everyone on LawsonGuru once again, for not just helping me out in this licensing and LUU thread, but in helping me get as far along with this server build as I finally am. I'm glad to say that after about 4 months of working on this in my free time, I've finally made it past the Websphere issues I was posting early in the year

I know it should be an entirely different thread, but does anyone know how to reset my net-express license? That's the next hurdle!
-Brian

Call your lawson rep to reset your netexpress license.

We have just upgraded from LSF 9.0.0 to 9.0.1 and went from MKS to LUU with the upgrade.  We have found that went printing our ACH receipts it is taking ALOT longer to spool and on the bigger files it is printing 2 copies.  We believe the duplicate copies are occuring due to the timeout being set to 60 seconds in the ServerIOTimeout in the Websphere Plugin.  We have increased the timeout but it is taking 40 minutes to spool our receipts when it used to take 1-2 minutes on LSF 9.0.0.  I am not sure where this issue lies but saw this post - thinking it may be an issue with LUU.  Did you ever get any conclusive information?  Any input is appreciated!

Check lawson announcement # CN-LSF90x-20110519

There are some fixes from microsoft you can download to help with LUU issues

Thank you for the CN# tip Jimmy!

Go to the MyLawson.com. Select Critical Notifications option under the Get Support tab. Filter on S3 and Windows. It will come up, date is 5/19/2011.

Posted By Kwane McNeal on 06/15/2011 11:30 PM Personally, it would have been easier if they would have picked up a copy of bin-utils, and static complied them, or made cygwin a third option, but again, I digress...

Lawson has issued an update to LUU to work with cygwin as a full replacement for MKS (see Lawson KB Article ID 5422254).

Lawson just came out with a pretty decent manual for installing LUU + Cygwin. KB 5438494.

FYI: I would redownload the LUU install from lawson. The name of the file did not change, but the size of the file changed.

 RE: the move from mks to luu. Read KB article over and over and think that you need win 2008 'R2' with Cygwin if you want to use LUU and be able to do upgrades.. if 'upgrades' means lawson version upgrades, we are o.k. because non planned..but if it means ctp's ..that is a concern.

is it possible to get away from mks while staying with win2008 sp2. we are apps 9.0.1 (msp5) and enviro 9.0.1 (sp7)

"Upgrades on Windows using LUU instead of MKS Toolkit are supported for Technology releases LSFCT 9.0.1 SP7 or higher, on Windows 2008 R2 only, and only with the LUU Cygwin/Alternate Shell configuration."

So this affects impexp and importdb only?

ANY file-based action that updates the database, is bound to 8-12 records a sec

I know this is a very old topic, however, I am having problems with MKS Toolkit and gpg4win....has anyone used these hand in hand for encryption and decryption?