LawsonGuru Blog

In the last issue, I reported on some of the enhancements that you would want if you could change any one feature in Lawson. One of these requests is to remove the "mainframe look-and-feel" of Lawson. Others have since agreed, and I have received numerous comments from you about how you’d like to see Lawson do away with some of this "clunky" behavior.

Wishful thinking-because Lawson is "to the core" COBOL (or RPG on the AS/400), and will remain that way until there’s a compelling (in other words, financially lucrative!) reason to re-code it. By "re-code", I’m not talking about anything that’s easy–I’m talking about a wholesale redesign.

Whatever "wrapper" you put around it–be it character-mode LID, GUI LID, JED, NED, COM+, XML UI, Portal, etc. — (gosh, that list IS getting long)–you’re still executing Lawson’s "business logic" at the core. And, that core is written in COBOL (or RPG on the AS/400).

And, that core code is where the UI limitations exist. If you’ve ever looked at the code, you’ll know what I’m talking about. To maintain a standard and consistent code base, every Lawson program looks and feels (and is written) the same way, and works on a "screen block" of data. This may-or may not-be a bad concept. Perhaps Lawson could write some middleware to fake out the underlying programs, but it would probably be too clumsy, and make matters that much worse.

Every time I hear someone telling me how Lawson is re-writing their code base to sync up with language "flavor of the week", and coming out with some new whiz-bang layer of technology, I feel like laughing and screaming: "HEY GUYS: IT’S STILL COBOL!!". A couple of years ago, I heard just that-a serious effort was underway at Lawson to re-write the Lawson applications in Java.

Rumor is that Lawson attempted to use some porting techniques to magically turn they COBOL code into Java. Problem is that both COBOL and RPG are procedural languages-Java is object-oriented. While, it’s syntactically possible, and they did have some minor success, in reality it was a failure, and they group was quietly disbanded. A noble effort, I guess, but still a flawed approach.

In order to migrate from a procedural language, like COBOL, to an object-oriented language, like Java, you have to think, design, and code in a completely new way. For me, that "Aha!" moment came after working in COBOL for several years, and then learning C++ and SmallTalk. Suddenly, the world was much clearer, and computer programming actually made more sense!

Have you ever looked "under the covers" into a Lawson program? Any program can touch any table. While there is some encapsulation and modularity for convenience sake, it’s nowhere close to what it would look like in a object-oriented language. Lawson’s common procedure libraries are a (minor) step in the right direction.

But, procedure libraries are only a first step, and they’re only as good as the programmers who write and use (or don’t use) them. I remember a funny story (actually, it’s a travesty) regarding some 8.x AC/BR code. Bugs kept surfacing in programs that used account category lookups. Two tables with similar prefixes (AAX and AXX) were referenced in the code. The second reference had a typo-therefore duplicating to the first lookup. And, that code kept being copied to new programs, replicating the same bug further.

As it turns out, simply using a common procedure would have eliminated them. But, wrapping up a bunch of common code into a procedure IS NOT the same as encapsulating that logic into an object.

How about inheritance? Shouldn’t a sub-account inherit from an account? How about a process level inheriting from a company? Well, to Lawson’s credit, there are some "inheritance" concepts (they call it "defaulting") used throughout Lawson, but it’s accomplished by long blocks of procedural code. Certainly not as elegant as declaring a new object.

So, the next time you cringe at Lawson’s "mainframe heritage", or hear about Lawson’s new whiz-bang code "flavor of the month", take a deep breath, and remember that Lawson has a lot invested in this "legacy" code, and it won’t go away anytime soon.