Mainframe COBOL: How Will It Look?

Correct. ^[6] Nevertheless, the new COBOL standard that includes object-oriented syntax has been in the making for how long? Ten years. When the industry really implements COBOL 2002 (that together with all of the specific vendor implementations ), you will have a new COBOL language. Go ahead, review the new COBOL 2002 standard in the context of each COBOL vendor's implementation. Although object orientation seems to get most of the attention, the details of the COBOL 2002 standard include many additional changes. I suggest that this "evolution" for COBOL is almost as "revolutionary" as .NET is for Visual Basic.

The business technology world has changed significantly over the last decade . The fact that the J4 committee (as committee members and as individual corporations outside of the committee) has positioned COBOL to enter the object-oriented, XML, and XML Web service “dominated world is certainly a good thing for the mainframe programmer community. Incidentally, I look at this as a confirmation that Microsoft has headed in the right direction with .NET. Everyone is coming to the party! All of the corporate J4 committee members, other software vendors , and Microsoft recognized this changing business world and the changes needed to provide developers with the tools to program for this changed world. Now comes your part: to use the tools. Confused about choosing your retraining path ? I do not blame you. Now you understand why I wrote this book.

Choose Your Vendor and You Choose Your Retraining Path

Aren't you glad that the apparent chaos in COBOL land will be someone else's problem? After all, you are abandoning the mainframe, right? So, what choices will they (those poor COBOL mainframe programmers that you leave behind) have? Let's review:

• Unisys and their ClearPath platform for developing object-oriented COBOL.

• Micro Focus presented as platform neutral. Still, there are proprietary development tools to learn.

• IBM's COBOL is captured in two acronyms: J2EE and Java ( courtesy of Sun Microsystems).

• EDS, another apparently platform-neutral interpretation that offers proprietary development tools.

• Acucorp's COBOL offers Web enabling, graphical front-end, and Windows platform technologies.

• Fujitsu Software Corporation provides a bridge into .NET through their Microsoft partnership.

Depending on which COBOL vendor, and thus, which COBOL 2002 implementation they would be working with, those COBOL mainframe programmers will have a variety of retraining challenges. They will need to learn the vendor-specific language extensions, development tools, and proprietary development platforms. Think about it.

Should each vendor have the liberty to interpret the COBOL standard with a unique implementation? Of course! Alas, this is the "value" of having an " open " standard. Appropriately, vendors should have something that sets them apart from each other. It is good for business and good for future technological innovations. However, what is good for business and technology creates extra challenges for us, the developers. Training and learning does not occur overnight. Additionally, just saying that you are coding in one particular language is not enough. The choice of one vendor over another inherently brings additional opportunities for learning (e.g., the development tools, the platform, vendor-specific language extensions, and so on) that could be more significant than learning the specific language syntax itself.

Before you throw your hands up and declare that in the workplace, vendor selection is out of the individual developer's hands, take note: When you see the lines drawn between technologies and vendors, you may begin to see the role that developers play in their individual places of employment.

Perhaps you have ambitions to take your programming skills in the desktop-to- Web direction. You have heard there is a large market out there for "office collaboration and workflow" applications ”a hot opportunity for entrepreneurs ready to cater to both enterprises and small businesses. Well, with IBM, you might be going down the path with Lotus Framework products (i.e., Lotus Notes, Corel WordPerfect, Domino.Doc, Domino Workflow, and so on).

On the other hand, with Microsoft and .NET, typically you would go down the path with Microsoft Office XP (i.e., Word 2002, Excel 2002, Outlook, and so on). You, the developer, understand that it is usually easier to develop integrated solutions when working within the boundaries of a particular vendor's product line. This is not an accident or coincidence . This concept applies to the mainframe just as it does to the desktop ”the software vendors depend on it. Try to see the larger picture when choosing your career direction.

Be Concerned About Your Future with COBOL on the Mainframe

Upward compatibility was maintained from COBOL 2002 back to COBOL 85. This is not true for Visual Basic .NET back to Visual Basic 6.0. In order to really revolutionize the language, Microsoft took a bolder step toward a complete overhaul of Visual Basic. On the other hand, the J4 took a more customer-friendly approach, but the COBOL language will likely suffer as a result. In other words, the J4 held the upward compatibility restriction as a higher priority, and thus tied their own hands. Frankly speaking, I am deeply concerned about the future of COBOL programming, at least as it exists on the mainframe. But what about you? What are your concerns?

I realize that some of you have read this entire section of the book in total dis-belief and shock . You may have had kind thoughts such as "This author has got to be joking. I have not heard anything about these revolutionary COBOL 2002 changes. My employer has not mentioned anything to me about retraining. I know that I will be able to do maintenance development to my legacy application until the day that I retire. My job and my career are secure. Besides, my company allows me to use PC-based visual COBOL development tools. We are modern. We recently upgraded to a ˜latest versioned' COBOL compiler . . . uh, I am not sure if it was based on COBOL 85 or COBOL 2002. But either way, we have even used COBOL to develop a GUI front-end that rivals CICS to access our mainframe data. Worst case, a new standard will come out that will be upwardly compatible. In that case, it will be business as usual ”good old structured programming with a few syntax enhancements."

Do these comments sound familiar? Have you had similar thoughts? When is the last time you discussed any of those topics with your employer?

Taking Action: Do Your Homework

I suggest that you follow each of the Web links that I have provided. Then, ask your current employer some of these questions:

• Where are our COBOL 2002 migration plans?

• When will the object-orientation retraining schedule be published?

• When is the next major new development project starting up in our department?

You may discover that your employer has chosen to leave their COBOL legacy applications and their legacy developers as is ”in maintenance mode ^[7] ”avoiding the new COBOL 2002 standard, the object-oriented syntax, the XML support, and the XML Web services. From a business' point of view, this may be the most economically wise thing to do. This is great for your employer's bottom line, but it is not so great for your future marketability . I wish that I could say that this would only matter if (and when) you decide to seek employment elsewhere. From what I am hearing from several of my former mainframe coworkers, the latest trend is that companies are laying off entire groups of mainframe staff members ”in some cases choosing to replace them with alternative platform software solutions.

Now, maybe your employer is much fairer than the "worst-case scenario" employer that I am describing. Just keep your eyes open. Communicate with your employer ”the guardian of your career ”and find out if they have already started to create tomorrow's nonmainframe "mission-critical" applications over in the Internet development department using a group of highly paid contractors. Find out if there are rumors that those guys over in the Internet development department are using a development approach called rapid application development (RAD). Rumor has it that when developers start using Microsoft .NET, RAD is going to get even faster. Do not worry. CIOs never listen to rumors.

OK, have I shaken you up a little? Right now, it's a risk I need to take. We can patch up our author-reader relationship in later chapters. So, let's continue forward for a little more motivational preaching. I promise I'll lighten up later.

Taking Action: Exercise Your Freedom to Choose

Remember that it is ultimately your career. Be the guardian of your own career. Let the choice of what technology you want to learn be influenced by (but not controlled by) what technology your current place of employment happens to be using. If it comes down to it, it is always each developer's option to choose his or her place of employment.

Regarding the notion of abandoning the mainframe and/or exercising your freedom to choose a different place of employment: For the record, I am very sensitive to the financial concerns of the business world at large. A mass exodus of all mainframe programmers from their current mainframe responsibilities would not be healthy for the average organization, and thus it would not be healthy in the end for the average employee. My challenge to you is this: Look for ways to serve yourself and at the same time address the needs of your employer. Look for creative ways to accomplish your goals while being sensitive to the needs of the organization as a whole. Think seriously about taking your responsibilities with you, even while leaving one platform for another. Seek opportunities to leverage your employer's current investment in business rule logic. A solution from which you and your employer both benefit will be better for all. Go for the win-win situation.

This unearths a subtle point. An important difference between developing on the mainframe (even for those using PC-based COBOL development tools) and developing real Windows applications on a PC is that for a small investment you can have major processing power (including your very own database) right in the comfort of your home. For some, this is where you may need to begin your retraining. Your (current) employer's choice and your choice (at least in the beginning) can be independent. Remember, when doing nonmainframe development, you can design, develop, debug, and deploy (even distribute for sale) real Windows and Web applications, all on your own personal computer, your own personal server, or your own home-based local area network (LAN). Having your own computer is empowering!

Years ago when I was helping out my company's help desk, one of our mainframe business users called in with the following complaint: "Can you help me? I think my computer is broken." After helping the user and ending the phone call, I shared this user 's plea with my coworkers. I can still remember the good laugh that we had. Why was this so funny ? This was still in the days of the "centralized processing model." Remember, in those days there was only one computer ”in the computer room, on top of a raised floor. Certainly, the user was mistaken. There was no computer on the user's desk, just a monolithic monochrome cathode ray tube (CRT). Those were the days.

Today, it has become common for companies to equip their users and their mainframe programmers with personal computer workstations with 3270- emulation software. There is no shame in people now referring to the CRTs of the past as "dumb" terminals. Naturally, the word "dumb" has nothing to do with how they looked or functioned.

As far as political correctness goes, if a "PC" workstation takes on the limited functionality our CRTs did, a more pleasant reference such as "thin client" is used. The term "thin client" serves both as a software and hardware term . At any rate, if you are among the many to have a "thick client" personal computer as your workstation running the Windows operating system, you are indeed fortunate.

Taking Action: Equip Yourself for Your Retraining Effort

You will need to equip yourself at home. Seriously, consider making a small investment at your local electronics store. What are the recommended hardware requirements? Allow me to first point out that your computer hardware needs as a new Windows programming professional are much different than the needs of a person who only uses his or her computer for home finances, e-mail, and games .

Some of you may already own an older computer at home. There is a remote possibility that doing an upgrade on your older computer may be a cost-justified solution. Granted, money does not grow on trees. However, this is your future ”your career ”that we are talking about. You will need these tools. Besides, the hours that you are going to invest into retraining cannot and should not be done all on your employer's resources. Cut the umbilical cord and prepare to reap many financial gains from your own investment.

The computer that you want to use as your training hub should be a beefy workhorse.

In other words, plan to spend about $1,500. A PC with a Celeron chip will be much cheaper than one with a Pentium chip. Either way, aim for a chip with a minimum of 600 MHz processing power. With the money that you save from buying this alternative Celeron chip, plan to purchase a random access memory (RAM) upgrade. You will want to upgrade your RAM to at least 512MB of memory. The current Windows operating system is Windows XP (Home Edition or Professional). The average new PC will already have Windows XP Home Edition installed. However, be prepared to pay a little extra for the upgrade to Windows XP Professional. The Home Edition of Windows XP does not provide Internet Information Services (IIS) and .NET requires IIS installation. Therefore, the Professional edition is required. ^[8]

There is talk about the Microsoft .NET Framework eventually being available on other platforms. Otherwise , throughout this book, I take a Microsoft-centric view toward technology. Considering their dominant market share of Windows desktop applications and development tools, this is certainly a comfortable approach.

Windows 2000 has a server version. Additionally, Microsoft is expected to release a new server-versioned operating system (likely to be called Windows .NET) in the near future. If you choose to go down that route, be prepared to add more learning topics to your already full list. I suggest that you avoid the server-versioned operating systems for now. When you are ready to set up your own LAN at home, you will then prefer the actual server-versioned configuration.

For Windows and Web .NET development, the Professional-versioned Windows operating systems will be perfect. As you install all of your new software tools, you will appreciate having the 40GB hard disks that are now a standard feature. A CD-ROM/DVD player, modem, and Internet connection are all required features. If you are serious about your retraining, this equipping step is not optional.

Perceptions and Opinions

Picking this book up, some of you might have anticipated reading dire predictions for COBOL as a language and, worse yet, degrading commentary about the mainframe developer community. Rather, you found just the opposite . Still, my perception may interest you. I believe that mainframe-based development does have a future ”a future that may not include you. Having said that, you should be concerned about what is happening.

During the time that I continued to proudly call the mainframe my home, people constantly predicted that the PC was going to make the mainframe obsolete. Yes, everyone is entitled to his or her perceptions, opinions, and beliefs. Nevertheless, back in those days, I was always defending the mainframe platform (and myself ). Even the mainstream press joined the cause, often drawing analogies between the extinction of dinosaurs and the extinction of the mainframe and mainframe programmers.

I remember telling people that "The world is big enough for the two platforms to coexist." Years have passed, and Y2K has come and gone. The mainframe is still here. ^[9] Therefore, it looks like I was right after all. However, what is happening now (the latest assault) is much more worrisome. The mainframe platform itself, with these new COBOL 2002 standard changes and the various vendor implementations of the standard, could potentially make today's mainframe programmers (those that fail to retrain) obsolete. Notice that I used the phrase "today's mainframe programmers," not "the mainframe (hardware) itself." Talk about being stuck in the back!

Acknowledging Industry Perceptions

I want to inject a few other industry perceptions at this point. They are not necessarily relevant or even within the current context. Nevertheless, to exclude them while discussing the transitional life of the reformed mainframe programmer would make this text seem less realistic. Other theories and perceptions are out there; some of them are even controversial .

Here is one perception that you may consider controversial. There is a perception that seasoned mainframe programmers typically are able to teach the typical Web developer a thing or two in general about disciplined quality assurance, production support practices, and application life-cycle methodologies.

Following this train of thought, interest in the mainframe programmer talent pool would then have little to do with actual technological expertise (COBOL or otherwise). Therefore, a perceived technological inferiority is more or less tolerated in order to leverage the "harder to come by" assets. Are you ready for another perception? Remember, these are not facts, just opinions that some people have. You might be surprised to see what people and how many people subscribe to these theories.

Try this one on for size . When hiring for Internet/Web development positions , some people believe a fresh-out-of-college intern makes a better hiring candidate than a seasoned COBOL mainframe programmer. They may add a supportive belief that the "newbie" college graduate will not require any "untraining" of old habits. The things that some people believe really amaze me. Nevertheless, though the perceptions may not be real, they do exist. Moreover, like opinions, everyone has one.

Undoubtedly, you have your own perceptions and opinions as well. Which, by the way, brings me to my next discussion topic: Your perception/opinion of your very own "technology transition" (see, I told you "reformation" sounds more exciting).

^[5] I promise I will explain the thought behind this snide remark later in the chapter.

^[6] If COBOL's 40-year ticker is allowed to continue (what with all of the changes that the language is undergoing, including the Visual GUI COBOL development that has already begun), then one would have to also consider that Visual Basic's life actually started before the Visual was added to the Basic. In other words, both languages (COBOL and Visual Basic) are 40 years old. I am not taking sides ”just trying to be fair.

^[7] Your employer always has the option of bringing in a company such as Acucorp to "help" them with the maintenance of their legacy applications. Try to be objective and answer the following question: If you owned the company, what would you do with your legacy COBOL applications?