MKS Toolkit vs. Lawson Unix Utilities - Major problem

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.