COBOL SKILLS - Hard to Find

At my prior job, our lead developer did not know COBOL at all (read or write code). He got around it by writing SQL, and I know a lot of people use SSIS packages to help with interfaces and SSRS for reports. Then, we purchased Design Studio and Process Flow thinking we would get away from COBOL. We found out that Design Studio code confused a senior level web developer who transferred to our group, and easy things like copy and paste in the Design Studio GUI is unpredictable. By this, I mean that when you paste, you expect the code to be pasted at the cursor; however, the code would be pasted elsewhere. My experience was that our web developer who used Dreamweaver or other tools hated the Design Studio GUI. I got frustrated too. Unless I had very little code to write in Design Studio, I preferred to put it in a library and use an editor which helped me locate issues better than the one in Design Studio. One of the premises of doing the changes in Design Studio was that customizations would be easier to manage; however, I found that to be untrue. We had a transaction which would skip records while paging, so I logged that with Lawson. When the change came back, the program worked in native COBOL; however, Design Studio had to have the new field dropped into the screen and the code had to be reworked. Things like AGS and DME calls really confused our web developer to the point that he gave up and just did SQL updates straight into the GEN database when he tried to update the dates on reports. Lawson said it was a really easy task to do in Process Flow. I wasn't too happy, and our web developer said he would try to do things the Lawson way the next time but never did. I really understand your problem as both our lead developer and senior web developer were in their mid to late 50s. I think Process Flow has a lot of potential, but it takes time to learn. I really like the tool in Design Studio to build AGS calls.

There are some younger folks who are picking up COBOL if they feel like the organization will help the employee develop their career and has a direction of where they want to go with Lawson. If you think about it, anyone who is not really close to retirement has to worry about their skills being obsolete. You need to mitigate their concerns. I found people who worked with SQR have a relatively easy time of transitioning to COBOL. I am sure there are other coding skills which are easier to transition to COBOL.

This year was my first Inforum, so it might just be one of those things that happens at every one of them that I just don't have the experience to realize yet.

But what I saw this year at it was any indication, anyone planning on sticking with Infor for the long haul and actually receive support on their products without paying out the nose for it, should probably plan on giving COBOL up eventually.

Infor seems to be very much in the vouge of transfering to cloud based SaS and ditching both COBOL and the idea of clients making many customizations at all to the product.

at the risk of making a shameless plug.... there are consultants out there that specialize in Lawson and are more than capable of making changes/customizations and or integrating into and out of Lawson using COBOL or custom AGS/DME (Servlet/Router) calls etc. Your best bet is to bring someone in house that knows or is willing to learn, assuming you expect to have a substantial/daily need. If it's more one off type of situations, there are a number of external options available.

end of shameless plug...

COBOL is not the problem. People is the problem. If you get a good smart employee who's willing to learn, he/she would be pumping out custom programs in no time. Took me a month to go from knowing nothing about COBOL to program anything in COBOL.

The web services have completely eliminated our need for COBOL customizations. I have developed a number of .NET libraries that turn all of our Lawson tables and screens into C# objects that at FAR easier to interact with programmatically, and make it much easier for us to extend the functionality of Lawson with very minimal risks of disruption from Lawson upgrades.

A good example is a project I just completed for our Training department. We use a third-party LMS and our trainers were spending hours each pay period entering updated medical certifications in both our LMS and Lawson. I was able to integrate Microsoft Office’s built-in OCR capabilities to develop a .NET app that lets them plop a whole pile of certs on a scanner, then let them quickly click through them all on the screen, and simply confirm that the OCR read the names, certifications and dates correctly. PA22 is updated automatically with the certs and they get a perfectly formatted CSV file when they're done that they upload to our LMS. What took 2 employees hours now takes one employee just a few minutes.

No customization of Lawson at all. And when we upgraded from Lawson 8 to Lawson 9 and everything switched from DME/AGS to SSO, it was just a simple change in one C# object and all our previous customization worked with the new system.

I agree with many of the comments above. I began my COBOL programming career back in the 70's using an IBM punched card system while listening to Ozzy, Sabbath, Van Halen, KISS, etc on my headphones. Other than getting rid of the punched cards, nothing has really changed for me when programming in COBOL ... LOL... But, over the years, us 'dinosaurs' all had to adapt and learn more languages to keep up with the times. My companyhas used Lawson since 1998. Besides the back end COBOL, we've had to learn Oracle tools, Crystal Reports, M/S-Access using ODBC, different operating systems, etc. We have MANY custom mods in our Lawson system. Although Lawson Infor does plan to phase our COBOL at some point, COBOL skills are still very much needed in this community especially when installing application CTP's with COBOL customizations. Younger folks with no COBOL skills, as it is rarely taught anymore, is something they can benefit from if they plan to continue to work on non-Landmark technology. One never knows when COBOL will truly go away. And us 'dinosaurs' will benefits from learning new tools and languages as they become available.

Hello everyone,
Well, it certainly appears that COBOL is going by the wayside. A couple of things that many of us will miss:
- Compiled COBOL runs like greased lightning. Few other languages can even come close to its speed of execution.
- COBOL happens to be written in English: "MULTIPLY RATE BY HOURS GIVING PAY", for example. You can simply read it!
- Lawson COBOL isn't actually "raw" COBOL. The early developers wrote LID and the 4GL (4th Generation Language), which completely eliminate the tedious parts of COBOL and leave you with the good stuff - managing the logic. Those developers were brilliant!

Some things we won't miss - such as receiving a program patch via fax with COBOL code changes to type in!

Design Studio, Process Flow, Java, .NET, C# are all sexy and fun, but we'll be sorry to see COBOL go . . .

As far as which direction to go - I recommend being careful to develop expertise in technologies that stand the test of time with Lawson/Infor. Landmark and Process Automation, for example, look like they will stay for the long haul. COBOL is slowly going away (obviously), along with Smart Office!

Best regards,
Dave
(303) 773-3535

Greetings,
I agree with several comments from above. Good developers can learn COBOL in a short amount of time and begin developing new programs quickly, even if it is not their language of choice or one they even know. Additionally good developers will find other solutions when needed.

From the rumblings I heard at Inforum it does sound like COBOL is going away since it sounds like many of the S3 products (all except PR) will be moving to Landmark in v11. My question is how long will Landmark be around before everything is a CloudSuite product?

Cheers!
Matt

Plenty of COBOL developers around. But long term Lawson is moving away from COBOL. Its mostly gonna be LPL, IPA and Landmark tools henceforth.
BTW at Inforum did anyone hear about any Landmark development tools. Anything that allows us to rewrite our 4GL code to LPL or even writing a basic LPL program from scratch that matches the versatility of 4GL/Self Service. We had nightmares converting RSS customizations to RQC.

I tell you what. There are very few languages out there that have been around and in wide use since the 1950's. I went to school after the military. I had one class in Cobol and have worked in nothing but. Well with the side of SQL, Javascript, Unix shell scripts, and Business Objects. Cobol is still a strong tool especially when used with the Net Express development tool. But I understand everyones frustration. Remember every language uses the same logic to accomplish the task. The only difference is in how the syntax works. Great discussion. BTW - I Hate Design Studio.

Regarding the cut & paste snafu described in AngelaC's post... I found the best way to get around that problem is to copy ALL the source code into a text editor and make your changes there. Then in the design studio editor DELETE EVERYTHING then paste EVERYTHING from the text editor. Works every time for me!

Rumor has it that Landmark 11 will finally allow LPL customization. Brush up on the Java skills...

I guess Configuration Console would be the equivalent of Design Studio, as far as allowing simple customizations via a GUI without changing the source code.

Per Infor in our discussions of upgrading to Xi. There is no more access to the source code for customizations, just Configuration Console with LPL to write your own functions/methods. Lawson S3 will be delivering grouped changes in a single jar file just like RQC at periodic intervals like monthly bug fixes and quarterly enhancements.