How do I showcase my skills in COBOL when applying for jobs?

[sgtberbatov]

Hi everyone,

I'm currently a PHP programmer and have been in web development for 10 years, doing front end to back end and everything in between. For about 2 years I've become jaded with the industry, and I feel that I've done everything I want to do in it. I've had several conversations with my fiancee and a few friends who work in my industry about what I could do. I've decided to move in to COBOL development, as there is a serious appeal (and coolness factor) for me to work on software that could be 20/30/40+ years old that handles vital transactions for large companies.

Currently I'm setting up some space in my home for me to study in, as well as allotting time to learn the COBOL language and the specifics of it. While I've been sorting this out, I've wondered about the process of landing jobs in the COBOL programming field. In my experience with PHP, I'd either provide sample code to an employer along with the website in action, or I'd sit a "test" which would either deal with PHP or deal with abstract programming questions in general.

As I'm starting out, I don't have any experience to reference when trying to land COBOL jobs, only what I've done with PHP. So I know I need to produce examples of my work which shows my skill and backs up my knowledge of the language. But what applications should I look to be building in COBOL while I learn? I'm following literature to learn the language and these will obviously have example applications for me to build. But is there anything I should be looking at building or learning about which would stand me in good stead both in terms of showing an employer I know what I'm doing as well as teaching me how COBOL is used properly in industry?

Thanks,
Michael

 

[johnherman]

I am an old COBOL guy. Well, actually I started with Basic and Fortran. But my COBOL goes back to the 1980's, which is hardly old compared to COBOL's actual birthday, but I digress. When I was a PM and a hiring manager, I gave a short COBOL test to applicants. I wrote the test myself to check on the aspects of COBOL that we used (or had bugs) most frequently. I haven't written COBOL since the mid 1990's, but I still see evidence of COBOL files at various jobs: evidence like signed overpunch numeric fields, COMP fields, and HIGH-VALUES.

Anyway, I did a quick search and found one COBOL certification.

http://work.chron.com/cobol-certification-5616.html

I guess you could walk in with that as well as your hands-on experience with PHP. Also, at the interview, especially if you really want the job, you could offer to "read" some of their code to give a general idea of what the code is doing.

http://www.ehow.com/info_8744933_cobol-certification.html

http://compgroups.net/comp.lang.cobol/cobol-training-and-certification/937258

good luck !

==================================
advanced cognitive capabilities and other marketing buzzwords explained with sarcastic simplicity

 

[k5tm]

It has been long while since I was a hiring manager looking for business programmers with COBOL skills.

Do you notice how I worded that? I was in what was primarily an all-COBOL shop, well before the web, approximately 25 years ago. Even then, COBOL was in such (undeserved) disfavor that finding the right programmers with COBOL skills was difficult. But I was looking for business programmers.

Think in terms of what the drivers are for retaining and maintaining the huge amount of COBOL code in the world. That code truly represents how businesses do business - the business rules encoded decades ago and modified over time as the business needs changed. The code represents a huge amount of programming effort that cannot be easily duplicated for the sheer joy of being more modern. Most of my business clients are in this category.

Then think in terms of what the drivers are for modifying the existing code base in today's world. Certainly one main driver, one that has been with us from the dawn of business computing, is regulatory change. Another driver is the need to recognize operational efficiencies by using specialized services now delivered over the web. The web also allows much easier connections to trading partners.

So, in my particular (and perhaps peculiar) world view, COBOL skills today are needed most in the area of interfacing a siloed business critical application with the outside world. Most of my clients retain me to help do this.

I would urge you to think in terms of how your existing PHP work has related to business critical applications. Did your PHP, for example, involve taking orders from customers and forwarding them on to some order fulfillment mechanism? If so, then you already have some skills - and an appreciation of handling the dollars and cents - that might be valued by a prospective employer. If your PHP skills are confined to things that do not help run a business, then your skill upgrade needs to start working on that problem.

Specific to COBOL: Learn how to speak about the language itself. Understand how data are stored, both using relational database (which might already be familiar from your PHP experience) and the standard COBOL indexed (ISAM) files. Understand decimal arithmetic. Understand control structures, especially how the PERFORM statement works. Understand the concepts of paragraphs and sections. Understand where PHP and COBOL have analogous constructs, and where they are radically different. I hope others will join the conversation, to add their own experiences.

Not sure if I have been particularly helpful.

Tom Morrison
Consultant

 

[SamBones]

At first I thought this post was a troll, but April 1st is still a week and a half to go . You say you've worked with the whole stack, front end to back end, but you're jaded. I don't know if COBOL is going to spark your creativity and make you love what you do. I guess that's for you to decide.

Keep in mind that COBOL is used mostly due to legacy reasons. I don't know if there are any shops tackling new large development projects using COBOL (of course if anywhere, this thread will inform me ). That means the majority of COBOL jobs out there are going to be of the bug fix and maintenance type of work. You'll be working to understand code with 20 to 40 years or more of history, to make little changes designed to not break the rest of the legacy code. That sounds like hell to me. Maybe it's your sweet spot. I don't know. Again, that's for you to decide.

I'm one of the legions of programmers that built that legacy COBOL code that's running in banks and government and others large institutions. It's really not as glamorous as the movies make it out to be. My biggest improvement to my own career was learning skills to get me out of that.

I do agree with Tom that your knowledge of business processes is much more important. To me COBOL is a very simple language. It was designed to be simple so you can focus on the business logic. It doesn't take a big effort to become a COBOL language guru. So in a business that's looking for a COBOL programmer, a bigger asset is understanding business processes. Also important is understanding data integrity issues and math and calculations associated with businesses (i.e. calculating percentages, or amortizations, etc). Also important is understanding flat files, indexed files, and relational databases, since those will be your primary input and output to a program. You most likely won't be dealing with an interactive UI of any kind.

If you can, I would try to get experience with IBM mainframes. Specifically the OS. I currently work for an extremely large company that's in an extremely cutting edge industry, and we still have a lot of COBOL running on the billing systems (only). These are all big IBM iron. If you can learn IBM COBOL on an IBM mainframe OS, you should be able to find a high paying gig at an IBM shop. The only downside would be that there's a much higher chance of you needing to wear a suit and tie.

 

[johnherman]

BTW, my experience with COBOL in recent days shows it is still being used for Credit Card and other legacy Banking applications, Auto and Home insurance, Investment portfolio and IRA management, vendor mgmt and procurement. It may still also be in use with Health Care claim payment systems.

==================================
advanced cognitive capabilities and other marketing buzzwords explained with sarcastic simplicity

 

[sgtberbatov]

Thanks everyone for the feedback!

I understand it's quite a weird thing to say that I'm jaded, but it was through a conversation with a friend of mine who's also in the industry that pointed it out. Put simply: I don't have a beard, I don't use a Mac, I don't own an iPhone, and I'd rather put my trust in something tried and tested instead of using the next big hyped up language/library that enters the web development world. I have had heated discussions with people I've worked with who, every 6 months, come out and say "Hey we should use X in the next project!". When I ask them why it boils down to it either "being cool" or "everyone else is using it". And I've just had enough of that sort of rhetoric in an industry. I even bought a copy of .Net magazine for the first time in years the other week, and my heart sank with the general feeling of the industry having a culture of trying to outshine the next person by creating something flash and cool. Not actually creating something that helps the end user.

I have built systems from scratch in PHP (as well as MySQL, JavaScript etc) that have held the personal details of 60,000 people which would be accessed by 2,000 people day or night. I've also built a system that calculates and catalogues waste collected by a large recycling company, again accessed by numerous people. But in the second example the system I built needs to calculate the collected weight of something as well as it's carbon footprint etc. So I think I've got good experience in delivering and developing large(ish) systems for business.

All of your feedback has been brilliant, I'm really grateful for it. I've met plenty of programmers, but when I mention COBOL to them they either don't know about it or pour scorn on it. I can understand why, but at the same time if it was really that bad it wouldn't be responsible for mission critical software. That's my opinion.

The one thing I will ask though is how would I get the experience on IBM mainframes? Can they run in a VM or would I need to source the hardware from eBay? I don't mind running the hardware myself, it could go nicely with the IBM PC XT and PS/2 that I have in the garage!

Thank you so much for the advice and pointers though, really really do appreciate it. Even if I may have come across as a little bit of a troll in my initial question

 

[SamBones]

There are some IBM mainframe emulators. Just Google "free IBM mainframe emulator". You can also change "emulator" to "training" or "access" for other interesting sites.

Here's one called Hercules that apparently lets you bring up an MVS emulator on a PC.

http://www.hercules-390.org/

https://en.wikipedia.org/wiki/Hercules_(emulator)

I don't know how extensive it is, or if there's a COBOL compiler available, but it would be a start.

Just keep in mind that there are multiple OSes that run on IBM mainframes. I believe there's even a Linux version for mainframes.

Good Luck in your quest! Please keep us informed on your progress. I am interesting in how it goes.

 

[SaltyTheFrog]

I'm an ex-COBOL programmer and my 18+ years experience was all on the IBM mainframe. To work in an environment like that you need to know a lot more than just coding COBOL. There wasn't much use for someone that just coded COBOL except for the very basic beginning programmers. I seriously doubt many companies still using mainframe COBOL have and programs to train people from scratch. Maybe the PC based COBOL platforms are another story.

 

[SamBones]

Salty, I have a little different take on it.

I work for a large company that is in a very cutting edge industry. We try to stay on the bleeding edge of many different fields. Despite that, our billing system is on big IBM iron and running COBOL programs. My impression is that the billing system group is more accepting of a new/novice programmer just because the pool of candidates is much smaller. This is where Michael's plan is brilliant.

If you look at the pool of "experienced" COBOL programmers in the marketplace, the majority of them are approaching, at, or past retirement age. People I've talked to would welcome an eager young COBOL programmer. Someone that wants to become highly proficient and stick around a while. Not someone that wants to learn it and them move onto the next fad language or technology.

Because of that shrinking pool of candidates, I think companies are more amenable to providing a little bit of training, assuming there's a basic working knowledge of the language.

 

[mikrom]

Hi sgtberbatov,

I am a developer (COBOL, Java, DB2) of a core banking system written in COBOL and running on IBM iSeries. There is still new COBOL development in our bank:
- new COBOL batch programs
- new interactive applications with backend in COBOL and frontend in Java
- new WebServices which calls the COBOL programs
I think we are very flexible with this system, but nevertheless the managers speak mainly positive about Java and about COBOL only mainly negative. I do not know why COBOL has such a bad reputation. It is probably just a marketing speech from the many suppliers that our bank has, which try to get a bigger piece of cake with the promise to replace our COBOL system with a different one which should be better. So if you want to be a COBOL programmer, you must be prepared for some psychological situations after that you will feel like a second-class programmer.

IMO, you have good experience with databases and programming, so it would be no problem for you to learn a simple language like COBOL. But COBOL will be mainly used on IBM machines like zSeries (aka mainframes) or iSeries (aka AS/400). Working with these operating systems is different from systems like Unix and Windows, so it would be advantage for you if you can get some experience with it, to see if it is really that what you want to do. There are some commands what you have to learn to be able to work on these platforms and some additional languages like Control language (CL on iSeries, JCL on zSeries) and maybe REXX. For example if you compile a program you get a spoolfile with a listing and errors. So you have to first look in this spoolfile, search for the errors, correct them in your source, compile it again and look in the spoolfile again.

The one thing I will ask though is how would I get the experience on IBM mainframes? Can they run in a VM or would I need to source the hardware from eBay?

Some years ago I got a free mainframe account here:

http://www.efglobe.com/cgi-bin/mainframe/mainuser

So I could try some COBOL examples on the mainframe. But after a certain time when I have not logged in, my account expired.

Try to apply there for an new TSO userid, then get some tutorials and start to learn.

If you want to try the other platform - the IBM iSeries - then apply for a free account by Holger Scherer here:

http://pub400.com/signup.html

I have it and it never expired.

But as said above, the biggest asset of COBOL programmer is not the technology he works with, but the understanding of the business processes in the institution he works in - e.g.: booking, loan, sales, credit cards, ... etc

 

[Glenn9999]

Nothing much to add to what the others said: COBOL or PHP or whatever is just a tool used to perform a job. You need to learn about what that job is a whole lot more than the language itself, and then how to use that tool (whatever it is) to accomplish the job. A lot of times, the tool is going to sink into the background (the fact that a programmer doesn't actually DO that for a majority of his billable hours being the one thing they didn't teach going out of school) in the name of other stuff. It's the *other stuff* you got to worry about being able to handle, cope with, and the like. Handling bosses who have no clue about what you do, end-users that expect the world delivered to them yesterday, and the like. In a way, all of this is just a warning to you - if you are "jaded" about the industry now, switching to something like this likely won't fix that "jadedness".

 

[johnherman]

So you wanna be a COBOL programmer?!? First thing - know what COBOL acronym stands for. Second, dye your hair grey or shave your head and dye your hair grey. Wear wire frame glasses, even if you don't need glasses. Tinted lenses optional. Wear 1970 and 1980 vintage ties along with your white shirt and black slacks. Extra points for a pocket protector.

==================================
advanced cognitive capabilities and other marketing buzzwords explained with sarcastic simplicity

 

[sgtberbatov]

@Glenn9999 Thanks for the input. You're right in what you say about dealing with end-users and idiot bosses who have no understanding. I've come across plenty of them, but I can deal with them easy enough. The jadedness comes from dealing with peers in the web design/development industry. Always looking for newer and cooler things to do to show off their talent while not giving a damn about the end user. I've had enough of that, and while I know there will always be an element of that, I think that type of scenario is more or less confined to that industry.

@johnherman I own a Commodore Calculator and an IBM PC XT. Does this make me more or less of a COBOL programmer?

 

[johnherman]

@sgtberbatov - I used simplex (half duplex) teletypes before terminals/screens were in use. I used acoustic modems where you placed the phone handset into the modem cradle. I used yellow baudot punch tape to store my programs and data until we graduated to punch cards. I remember magnetic tape and have seen (but never used) wire boards for programming. I remember when the internet was text only, before the world wide web, and when unix mail was a great thing, since generic e-mail had not yet evolved. I remember the Compaq luggable PC's - they were like a heavy suitcase. I remember when my coworker bragged to me that he could download 4 minutes of song from his cassette player into his Amiga PC and that I couldn't do that with my IBM compatible. He was soooo technically hip - he carried a "bag" phone (in 1989). It was about the size of a small backpack and fairly heavy, like a TA-312. I remember 20 megabyte Winchester drives. Woo-Hoo.

What's amazing about all of that experience? I never learned Assembler.

BTW, you seem to have the right mindset for a COBOL programmer. ;-)

==================================
advanced cognitive capabilities and other marketing buzzwords explained with sarcastic simplicity