COBOL Is Simple
COBOL is a simple language (until the most recent version, it had no pointers, no user-defined functions, and no user-defined types). It encourages a simple, straightforward programming style. Curiously enough, though, despite its limitations, COBOL has proven itself well suited to its target problem domain (business computing). Most COBOL
programs operate in a domain where the program complexity lies in the business rules that have to be encoded rather than in the sophistication of the data structures or algorithms required. In cases where sophisticated algorithms are needed, COBOL usually meets the need with an appropriate verb such as SORT or SEARCH.
12
Chapter 1 ■ IntroduCtIon to CoBoL
Earlier in this book, I noted that the limitations of COBOL meant it could not be used to teach computer science concepts. And in the previous paragraph, I noted that COBOL is a simple language with a limited scope of function.
These comments pertain to versions of COBOL prior to the ANS 2002 version. With the introduction of OO COBOL, everything has changed. OO COBOL retains all the advantages of previous versions but now includes the following:
• User-defined functions
• Object orientation
• National characters (Unicode)
• Multiple currency symbols
• Cultural adaptability (locales)
• Dynamic memory allocation (pointers)
• Data validation using the new VALIDATE verb
• Binary and floating-point data types
• User-defined data types
COBOL Is Nonproprietary
The COBOL standard does not belong to any particular vendor. It was originally designed to be a “machine independent common language8” and to be ported to a wide range of machines. This capability was demonstrated by the first COBOL
compilers when the same program was compiled and executed on both the RCA and the Remington-Rand-Univac
computers.8 The ANSI COBOL committee, and now the ISO, define the non-vendor-specific syntax and semantic
language standards. COBOL has been ported to virtually every operating system, from every flavor of Windows to every flavor of Unix; from IBM’s VM, zOS, and zVSE operating systems, to MPE, MPE-iX, and HP-UX on HP machines; from the Wang VS to GCOS on Bull machines. COBOL runs on computers you have probably never heard of, such as the Data General Nova, SuperNova, and Eclipse MV series; the DEC PDP-11/70 and VAX; the Univac 9000s and the Unisys 2200s; and the Hitachi EX33 and the Bull DPX/20.
COBOL Is Maintainable
COBOL has a 50-year proven track record for application production, maintenance, and enhancement. The
indications from the Y2K problem that COBOL applications were cheaper to fix than applications written in more recent languages ($28 per function point versus $35 for C++ and $65 for PL/1) have been supported by the 2012
ComputerWorld survey12 and the 2011/12 CRASH Report.40 When comparing COBOL maintenance costs to those of Visual Basic, C#, C++, and Java, the ComputerWorld survey reported that 72% of respondents found that COBOL
was just as good (29%) as these languages or better (43%). Similarly, the CRASH Report found that COBOL had the lowest technical debt (defined in the report as “the effort required to fix problems that remain in the code when an application is released”) of any mainstream language, whereas Java-EE, averaging $5.42 per LOC, had the highest.
One reason for the maintainability of COBOL programs was mentioned earlier: the readability of COBOL
code. Another reason is COBOL’s rigid hierarchical structure. In COBOL programs, all external references, such as references to devices, files, command sequences, collating sequences, the currency symbol, and the decimal point symbol, are defined in the Environment Division.
When a COBOL program is moved to a new machine, has new peripheral devices attached, or is required to
work in a different country, COBOL programmers know that the parts of the program that will have to be altered to accommodate these changes will be isolated in the Environment Division. In other programming languages, programmer discipline might ensure that the references liable to change are restricted to one part of the program but they could just as easily be spread throughout the program. In COBOL programs, programmers have no choice.
COBOL’s rigid hierarchical structure ensures that these items are restricted to the Environment Division.
13
Chapter 1 ■ IntroduCtIon to CoBoL
Summary
Unfortunately, the leaders of the computer science community have taken a very negative view of
COBOL from its very inception and therefore have not looked carefully enough to see what good
ideas are in there which could be further enlarged, expanded or generalized.
Jean Sammet, “The Early History of COBOL,”
ACM Sigplan Notices 13(8), August 1978
The problem with being such an old language is that COBOL suffers from 50 years of accumulated opprobrium.
Criticism of COBOL is often based—if it is based on direct experience at all—on programs written 30 to 50 years ago.
The huge monolithic programs, the tangled masses of spaghetti code, and the global data are all hallmarks of COBOL
programs written long before programmers knew better. They are not characteristic of programs written using more modern versions of COBOL.
Critics also forget that COBOL is a domain-specific language and criticize it for shortcomings that have little relevance to its target domain. There is little acknowledgement of how well suited COBOL is for that domain.
The performance of COBOL compared to other languages in recent surveys underlines its suitability. The 2012
ComputerWorld survey12 compared COBOL with Visual Basic, C#, C++, and Java and reported that, among other things, respondents found it better in terms of batch processing, transaction processing, handling business-oriented features, and maintenance costs. Nor is this a one off: similar results have been reported by other surveys.
There is enormous pressure to replace COBOL legacy systems with systems written in one of the more
fashionable languages. The many failures that have attended replacement attempts, however, have given legacy system stakeholders pause for thought. The well-documented dangers of the replacement approach and the relative success of COBOL system migration is leading to a growing reassessment of options. Keeping the COBOL codebase is now seen as a more viable, safer, cheaper alternative to replacement. But this reassessment reveals a problem.
Keeping, and even growing, the COBOL codebase requires COBOL programmers, and the COBOL workforce is aging and nearing retirement.
For some years now, programmers have luxuriated in a seller’s market. The demand for programmers has been
far in advance of the supply. But student numbers in computer science courses around the world are recovering from the Y2K downturn. As these graduates enter the job market, it will become more and more competitive. In a competitive environment, programmers may find that having a résumé that includes COBOL is a useful differentiator.
References
1. Dijkstra EW. How do we tell truths that might hurt? ACM SIGPLAN Notices. 1982; 17(5): 13–15.
http://doi.acm.org/10.1145/947923.947924
doi: 10.1145/947923.947924. Originally issued as Memo EWD 498. 1975 Jun.
2. Mitchell RL. Brain drain: where Cobol systems go from here. ComputerWorld. 2012 Mar 14.
www.computerworld.com/s/article/9225079/Brain_drain_Where_Cobol_systems_go_from_here_
3. Sneed HM, Erdoes K. Migrating AS400-COBOL to Java: a report from the field. CSMR 2013. Proceedings of the 17th European Conference on Software Maintenance and Reengineering; 2013; Genova, Italy. CSMR; 231–240.
4. Glass R. Cobol—a contradiction and an enigma. Commun ACM. 1997; 40(9): 11–13.
5. Glass R. How best to provide the services IS programmers need. Commun ACM. 1997; 40(12): 17–19.
6. Glass R. COBOL: is it dying—or thriving? Data Base Adv Inf Sy. 1999; 30(1).
7. Glass R. One giant step backward. Commun ACM. 2003; 46(5): 21–23.
8. Sammet J. The early history of COBOL. ACM SIGPLAN Notices. 1978; 13(8) 121–161.
9. Brown GDeW. COBOL: the failure that wasn’t. COBOL Report; 1999. CobolReport.com (now defunct) 10. Jones C. The global economic impact of the Year 2000 software problem. Capers Jones. 1996; version 4.
11. Barnett G. The future of the mainframe. Ovum Report. 2005.
12. ComputerWorld. COBOL brain drain: survey results. 2012 Mar 14.
www.computerworld.com/s/article/9225099/Cobol_brain_drain_Survey_results
13. Topolski E. IBM unveils new software to enable mainframe applications on cloud, mobile devices. IBM News Room. 2012 May 17. www-03.ibm.com/press/us/en/pressrelease/41095.wss
14
Chapter 1 ■ IntroduCtIon to CoBoL
14. Terekhov AA, Verhoef C. The realities of language conversions. Software, IEEE. 2000; 17(6): 111,124.
15. Sneed HM. Migrating from COBOL to Java. ICSM 2010. Proceedings of International Conference on Software Maintenance; 2010; Timisoara, Romania. IEEE; 1-7.
16. The Standish Group. Modernization: clearing a pathway to success. Report. Boston: The Group; 2010.
17. Organizational tool manufacturer cuts costs by 94 percent with NetCOBOL and NeoTools. Microsoft. 2011.
www.gtsoftware.com/resource/organizational-tool-manufacturer-cuts-costs-by-94-percent-with-net-
cobol-and-neotools/
18. Productivity tools maker cuts costs 94% with move from mainframe to Windows. Microsoft. 2009 Jul.
www.docstoc.com/docs/81151637/Daytimer_MainframeMigration
19. Waters J. Testing mainframe code on your laptop. WatersWorks blog, Application Development Trends (ADT).
2010 Jul 27. http://adtmag.com/blogs/watersworks/2010/07/ibm-mainframes-cobol-recruits.aspx
20. Robinson B. COBOL remains old standby at agencies despite showing its age. Federal Computer Week. 2009 Jul 9.
www.fcw.com/Articles/2009/07/13/TECH-COBOL-turns-50.aspx
21. Thomas J. Manta’s IBM i COBOL training trifecta. IT Jungle. 2012 Oct 22. www.itjungle.com/tfh/tfh102212-story10.html
22. Veryant announces new COBOL training class. Veryant. 2012 Apr.
www.veryant.com/about/news/cobol-training-class.php
23. Atwood J. COBOL everywhere and nowhere. Coding Horror. 2009 Aug 9.
www.codinghorror.com/blog/2009/08/cobol-everywhere-and-nowhere.html
24. Campbell G. 2009 Aug 10. Comment on Atwood J. COBOL everywhere and nowhere. Coding Horror. 2009 Aug 9.
www.codinghorror.com/blog/2009/08/cobol-everywhere-and-nowhere.html
25. Kwiatkowski ŁM, Verhoef C. Recovering management information from source code. Sci Comput Program. 2013; 78(9): 1368-1406.
26. Brin D. The practice effect. 1984. Reprint, New York: Bantam Spectra; 1995.
27. Verhoef C. The realities of large software portfolios. 2000 Feb 24. www.cs.vu.nl/~x/lsp/lsp.html
28. Case study: Owens & Minor. Robocom. 2011.
www.robocom.com/Portals/0/Images/PDF/Owens%20&%20Minor%20Case%20Study.pdf
29. Medical supply distributor avoids costly ERP replacement with migration to Windows Server and SQL Server.
Microsoft. 2010 Feb.
www.docstoc.com/docs/88231164/Medical-Supply-Distributor-Avoids-Costly-ERP-Replacement-with
30. Veerman N. Revitalizing modifiability of legacy assets. J Softw Maint Evol-R. 2004; 16: 219–254.
31. Holloway N. Micro Focus International plc: Irish Life delivers cost savings and productivity gains through application modernzation program with Micro Focus. 4-Traders.com. 2013 May 30. www.4-traders.com/
MICRO-FOCUS-INTERNATIONAL-12467060/news/Micro-Focus-International-plc-Irish-Life-Delivers-Cost-
Savings-and-Productivity-Gains-through-Appl-16916097/
32. Mainframe-to-Windows move speeds agility up to 300 percent for global publisher. Microsoft. 2007 Sep.
www.platformmodernization.org/microsoft/Lists/SuccessStories/DispForm.aspx?ID=6&RootFolder=%2Fmi
crosoft%2FLists%2FSuccessStories
33. Sneed H. A pilot project for migrating COBOL code to web services. Int J Softw Tools Tech Transf. 2009; 11(6): 441–451.
34. Brand M, Deursen A, Klint P, Klusener AS, Meulen E. Industrial applications of ASF+SDF. Amsterdam, The Netherlands: CWI; 1996. Technical report. Also Wirsing M, editor. AMAST’96. Proceedings of the Conference on Algebraic Methodology and Software Technology; 1996; Munich, Germany. Springer-Verlag; 1996.
35. Social Security Administration. The Social Security Administration’s software modernization and use of common business oriented language. Audit Report. Office of the Inspector General, Social Security Administration. 2012
May. http://oig.ssa.gov/sites/default/files/audit/full/pdf/A-14-11-11132_0.pdf
36. Property firm migrates from mainframe to Windows, cuts costs 60 percent, ups speed. Microsoft. 2006 Jul.
http://cloud.alchemysolutions.com/case-studies/Watch-Stockholmshem-describe-the-modernization-experience
Or www.gtsoftware.com/resource/property-management-firm-migrates-from-mainframe-to-windows-cuts-
costs-60-percent-ups-speed/
Or http://download.microsoft.com/documents/customerevidence/27759_Stockholmshem_migration_case_study.doc
37. Datamonitor. COBOL—continuing to drive value in the 21st century. Datamonitor; 2008 Nov. Reference code CYBT0006.
38. National Council of Social Security Management Associations Transition White Paper. 2008 Dec.
http://otrans.3cdn.net/bfb27060430522c5ae_n0m6iyt3y.pdf
39. Hoover JN. Stimulus funds will go toward new data center for Social Security Administration.
InformationWeekUK. 2009 Feb 28.
www.informationweek.co.uk/internet/ebusiness/stimulus-funds-will-go-toward-new-data-c/214700005
40. Executive Summary—The CRASH report, 2011/12. CAST. 2012. www.castsoftware.com/research-labs/crash-reports
15
Chapter 2
COBOL Foundation
This chapter presents some of the foundational material you require before you can write COBOL programs. It starts by identifying some elements of COBOL that programmers of other languages find idiosyncratic and it explains the reasons for them. You’re then introduced to the unusual syntax notation (called metalanguage) used to describe COBOL verbs and shown some examples.
COBOL programs have to conform to a fairly rigid hierarchical structure. This chapter introduces the structural elements and explains how each fits into the overall hierarchy. Because the main structural element of a COBOL
program is the division, you spend some time learning about the function and purpose of each of the four divisions.
COBOL programs, especially in restrictive coding shops, are required to conform to a number of coding rules.
These rules are explained and placed in their historical context.
The chapter discusses the details of name construction; but because name construction is about more than
just the mechanics, you also learn about the importance of using descriptive names for both data items and blocks of executable code. The importance of code formatting for visualizing data hierarchy and statement scope is also discussed.
To whet your appetite for what is coming in the succeeding chapters, the chapter includes a number of small example programs and gives brief explanations. The chapter ends by listing the most important COBOL compilers, both free and commercial, available for Windows and UNIX.
COBOL Idiosyncrasies
COBOL is one of the oldest programming languages still in use. As a result, it has some idiosyncrasies, which programmers used to other languages may find irritating. One of the design goals of COBOL was to assist readability by making the language as English-like as possible.1 As a consequence, the structural concepts normally associated with English prose, suc
h as division, section, paragraph, sentence, verb, and so on, are used in COBOL programs. To further aid readability, the concept of noise words was introduced. Noise words are words in a COBOL statement that have no semantic content and are used only to enhance readability by making the statement more English-like.
One consequence of these design decisions is that the COBOL reserved-word list is extensive and contains
many hundreds of entries. The reserved words themselves also tend to be long, with words like UNSTRING, EVALUATE, and PERFORM being typical. The English-like structure, the long reserved words, and the noise words makes COBOL
programs seem verbose, especially when compared to languages such as C.
When COBOL was designed, today’s tools were not available. Programs were written on coding forms
(see Figure 2-1), passed to punch-card operators for transfer onto punch cards (see Figure 2-2), and then submitted to the computer operator to be loaded into the computer using a punch-card reader. These media (coding sheets and punch cards) required adherence to a number of formatting restrictions that some COBOL implementations still enforce today, long after the need for them has gone. This book discusses these coding restrictions but doesn’t adhere to them. You should be aware, though, that depending on the coding rules in a particular coding shop, you might be obliged to abide by these archaic conventions.
17
Chapter 2 ■ COBOL FOundatiOn
Figure 2-1. COBOL coding sheet
Figure 2-2. COBOL punch card for line 11 of the coding sheet 2
18
Chapter 2 ■ COBOL FOundatiOn
The final COBOL irritant is that although many of the constructs required to write well-structured programs have been introduced into modern COBOL (ANS 85 COBOL and OO-COBOL), the need for backward compatibility means
Michael Coughlan Page 4
