Blog

12 Days of COBOL Programming

Image from Canva, Edited by the Author in Canva to add text

Since we’re entering a new year full of hope and new beginnings, particularly putting 2020 behind us, I wanted to do the “12 days of Christmas” from the perspective of a COBOL programmer, with a Production release coming up in early Feb 2021.

The tune is, of course, the “Twelve Days of Christmas”. Enjoy…

12 Days of COBOL Programming

On the first day of Christmas, my Manger sent to me
One Production release

 On the second day of Christmas, my Manger sent to me
Two user requirements, and
One Production release

 On the third day of Christmas, my Manager sent to me
Three new developers,
Two user requirements, and
One Production release

On the fourth day of Christmas, my Manger sent to me
Four business analysts,
Three new developers,
Two user requirements, and
One Production release

On the fifth day of Christmas, my Manger sent to me
Five program specs,
Four business analysts,
Three new developers,
Two user requirements, and
One Production release

 On the sixth day of Christmas, my Manager sent to me
Six days of coding,
Five program specs,
Four business analysts,
Three new developers,
Two user requirements, and
One Production release

 On the seventh day of Christmas, my Manager sent to me
Seven days of testing,
Six days of coding,
Five program specs,
Four business analysts,
Three new developers,
Two user requirements, and
One Production release

On the eighth day of Christmas, my Manager sent to me
Eight problem logs,
Seven days of testing,
Six days of coding,
Five program specs,
Four business analysts,
Three new developers,
Two user requirements, and
One Production release

 On the ninth day of Christmas, my Manager sent to me
Nine code fixes,
Eight problem logs,
Seven days of testing,
Six days of coding,
Five program specs,
Four business analysts,
Three new developers,
Two user requirements, and
One Production release

 On the tenth day of Christmas, my Manager sent to me
Ten programs migrated,
Nine code fixes,
Eight problem logs,
Seven days of testing,
Six days of coding,
Five program specs,
Four business analysts,
Three new developers,
Two user requirements, and
One Production release

 On the eleventh day of Christmas, my Manger sent to me
Eleven UA testers,
Ten programs migrated,
Nine code fixes,
Eight problem logs,
Seven days of testing,
Six days of coding,
Five program specs,
Four business analysts,
Three new developers,
Two user requirements, and
One Production release

 On the twelfth day of Christmas, my Manger sent to me
Twelve days of code freeze,
Eleven UA testers,
Ten programs migrated,
Nine code fixes,
Eight problem logs,
Seven days of testing,
Six days of coding,
Five program specs,
Four business analysts,
Three new developers,
Two user requirements, and
One Production release

Happy New Year for 2021 to all you COBOL Programmer types that happen upon this article and can appreciate both my pain and my satisfaction.

Wish me luck in 2021!

Coding Demystified–10 Steps in a COBOL Fix

Background from Canva, Edited in Canva

When people think of a COBOL programmer, they no doubt envision someone, head down, working in a bubble, coding all day, creating new, exciting software products. In reality, aside from the rare new development work that may actually result in all-day coding sessions, a programmer’s job involves a procession of coding fixes on already implemented code. This article discusses 10 of the main steps you will find in one of these pieces of work, from the perspective of an experienced programmer of over 27 years.

Analysis

1.  Understand the Problem

If you are a Programmer/Analyst, you will inevitably be assigned a coding issue to resolve. It will be some defect in the existing code, discovered by a tester or maybe a fellow programmer. This issue will be presented in writing or verbally. Your first job will be to interpret the problem and understand it yourself. This is what is referred to as analysis.

2.  Articulate the Problem

If the issue has been recorded in an incident report, there will already be a written description of the issue, made by the reporter. If it has been verbally reported, it will be up to you to explain the problem in such a way that others will understand it. For example, you, as a programmer, will be expected to describe system issues in a non-technical way for a User to understand.

3.  Discuss the Problem with the Client

Once you put the problem into your own words and have an understanding of the issue involved, you will need to make the client aware that there is a problem. This requires excellent communication skills in order to adjust to a business-oriented audience. This discussion should result in a written requirement.

Design

4.  Identification of the Fix

Since the problem has now been articulated and recorded, it needs to be fixed. A potential solution should take into account, not only the area where the problem has occurred but also other parts of the system that may be impacted. Designing a solution requires the programmer to basically have an understanding of the whole system.

5.  Get Approval to Implement a Fix for the Problem

When an appropriate fix has been identified and designed, communication skills again come into play. This time the programmer must communicate the proposed solution to the client in a way they understand. The goal here is to get approval to implement the intended fix.

6.  Document the Problem—Specifications

At this point, the programmer is almost ready to make the change. Before diving in to code, however, it is important to create system specifications. These specs are an aid for the programmer making the change as well as documentation that can be used as a reference later on. They may be in the form of a flow chart, pseudo code, or even a word document description.

Implementation

7.  Implement the Solution

Finally, it is time to start coding. Depending on the problem to be solved, the coding change may range from one line to many lines. It may take several days or just a few minutes. As well as making the coding change, this part of the solution involves compiling your change. The compiler will check the syntax of the new code and report any errors.

Testing

 8.  Unit Test the Fix

When the compiler errors have all been resolved, it is then time to unit test your implemented code. This is generally programmer testing to determine that the code is functioning as expected. Depending if it is an online or batch solution, you may test your code by accessing it through a CICS screen or by running a batch JCL job.

9.  User Acceptance Test

If the code has successfully run in Unit test to the satisfaction of the programmer, it will be made available to the client, or User, to perform User Acceptance testing. Before final implementation, the User will carry out enough tests to ensure that the solution fulfills the requirements decided on earlier.

Maintenance

10.  Maintain the Fix

The implemented code is still subject to future modifications. The requirements may change, resulting in necessary maintenance of the revised code. This will be ongoing for as long as the code is in use.

 

As you can see, writing code is just one skillset that a COBOL programmer is expected to master during their career. They must also excel as analysts, communicators, writers, and testers. It can be very satisfying to have a job that provides such a variety of challenges.

 

 

COBOL Plus JCL Equals Magic

Background from Canva, Edited by the Author in Canva

The Initiation

I’ve had a love-hate relationship with Job Control Language (JCL) ever since my first encounter with it back in the 1990s. If you wanted to program in COBOL, which I did, there was no way to avoid JCL. All beginner programmers had to complete a week-long JCL tutorial with information similar to that found in this current IBM Basic JCL Concepts tutorial. Of course, almost 30 years ago, my JCL tutorial was presented on a green screen in a non-graphic, dry way. I probably learned more in my first hour running my own JCL job than I did that whole week reading screen after screen of info that seemingly had no context.

The Effort

At the beginning of your career, which is what it will become if you have the tenacity to continue as a COBOL programmer, you can’t begin to comprehend how much time you will spend with JCL over the years. Early on, you may spend hours trying to figure out why your job isn’t running at all or why it abends in a step when it logically shouldn’t. You pour over the job output looking for clues, only to find that you’ve somehow added an extra space in your Jobcard, or your output file doesn’t exist when your job expects it to.

The Understanding

As time goes on, after you have run a few jobs and debugged a few outputs, it starts to become a bit clearer that there is a method to this madness. Maybe by this time, you have actually written a Batch COBOL program yourself that reads input, perhaps from a file, performs some processing, and writes output to another file. How do you get that program to run and produce that output? You wrap some JCL around it to tell it what file to use as input and where to save the output. Your job may even be scheduled to run at a certain time through a job scheduler like Control-M.

Graphic created by the Author

The Reward

In the end, if you stick with it, it can be a very satisfying experience to understand JCL, create a job, and run it successfully. There is something rewarding, almost magical, about producing JCL that runs your own COBOL program and produces an output that you can see. It took time, but it is a skill that I am happy I have learned and that I use almost daily.

What is your experience with JCL? Did you put in your own effort to come to understand it and, in the end, find it rewarding?

 

A COBOL Programmer’s Unique Story

“All of my friends who have younger siblings who are going to college or high school – my number one piece of advice is: You should learn how to program.” This is a famous quote by Mark Zuckerberg, CEO of Facebook.

The Discovery

I wish I would have had that advice presented to me when I finished high school. In the end, I did learn how to program, but my journey was very roundabout. I spent many years in University, getting a 3-year Psychology Degree and a 4-year Commerce Degree. With all that education behind me, I was still having trouble finding direction. As a result, I read an amazing, self-help book for job seekers called What Color is your Parachute? Surprisingly, the exercises in the book pointed me toward a career in programming, mostly based on my interest in the one programming course I had taken at University.

Photo of Author’s 1994 copy of the book
The Becoming

Given a new path toward programming, I decided to go the quickest route and get a programming Diploma. I used my University courses to get exemptions in the non-programming courses and finished a two-year Computer Programmer Diploma in a year. I loved it. Luckily, I was able to get a job as an entry-level COBOL programmer shortly after I graduated, which has led to a rewarding 25-year career as a Programmer-Analyst and IT Specialist.

The Next Step

The natural continuation of this lifelong journey is to write about it. To answer some questions that can only come from experience. What is it like to be a woman in technology? What has it been like to work with newer technologies at the same time as older ones? What is it like to be in the computer field with multiple generations of people?  There is so much to write about–so many topics to explore, drawing on my many years of experience. All the facets of the past have come together to create my story, which is, I hope, unique enough to share.

What’s your story? Where are you on your own journey? Are you still becoming, or are you considering your next step?

Who is the Online COBOL Audience?

Image from Canva, Edited in Canva by the Author

When you want to get to know someone in person, how do you generally accomplish that? Initially, you probably try to learn their characteristics, then you determine how to talk to them. The process is similar for online connections. First, you want to get to know their demographics and their psychological traits (psychographics), then you find ways to communicate with them.

Demographics and Psychographics of Listeners

Assuming that the majority of the online COBOL-related audience are COBOL programmers, their average age would be 55. Also, in an Evans Data Corporation survey, 27.5% of software developers in the world are women. Thus, the demographic of an online COBOL audience is probably men around age 55. Based on this demographic, some psychographic information about this group is that they are conservative, upper-middle-class, and are followers. In addition, according to the survey mentioned, one-fifth of men software developers have a personal interest in the technologies they are using. Consequently, one in five of COBOL listeners have a personal interest in COBOL technologies.

How to Communicate

Now that we have identified some characteristics of COBOL online listeners, one of the ways to find out how to communicate with this audience on social media is to search on Twitter. In this case, a Twitter search on #cobol came back with several related people to follow. Similarly, a search on COBOL in Google Trends resulted in 23 related queries and 19 related topics to investigate. In terms of Facebook communities, related groups and pages included a COBOL Programmers group with 16,000 members and a COBOL page with 3200 members.

A Screenshot of a COBOL search in Facebook

Listen Before Communicating

It is important to remember not to initiate a conversation too quickly in an unfamiliar COBOL online community. Some are primarily for job postings and others are used to sell online courses. Become a listener.  Get to know the demographics and psychographics of the group you are interested in before you start communicating.

What is your online style? Are you mainly a listener? Which online communities do you enjoy following?

 

 

COBOL and Digital Transformation

Original Photo, Edited by the Author to add text

The concept of “Digital Transformation” seems to be everywhere on the Internet lately and is the new catchphrase. The term has also frequently been paired with COBOL. As a result, I wanted to take a deeper look into what that might mean to business and the people involved.

What is Digital Transformation?

According to Red Hat, Digital Transformation “is the process of fundamentally changing something using digital tools and describes adopting technology and—potentially—cultural changes to improve or replace whatever existed before”.

Similarly, The article, 4 Types of Digital Transformation, organizes the idea nicely into Business Process, Business Model, Domain, and Cultural/Organizational categories. This is a detailed discussion of converting processes by introducing newer technologies and using these new technologies to update traditional business models and create new markets.

What I am understanding from these descriptions is that, essentially, what Digital Transformation means is modernizing your existing processes, whatever those may be.

The Current Way of Thinking:

How can COBOL, as a 60-year-old language, fit in with the idea of introducing new technologies? Bartolik (2020), in the article COBOL Forms the Basis for Digital Transformation, discusses how COBOL is the foundation and the core that operates 70% of the world’s transaction processing systems. The article further cites statistics from a Microfocus 2020 Press Release where COBOL-connected respondents from 40 different countries were surveyed. Of those who responded, 63% indicated that they would improve their existing COBOL systems in 2020, and 70% would prefer to modernize them rather than replace them. In terms of the modernization strategy, 92% felt that their COBOL applications were strategic.

These results indicate that organizations having existing COBOL applications would be open to digitally transforming their existing COBOL systems.

COBOL + New Technologies = Digital Transformation:

The article, Why COBOL Modernization Should be a Priority and How to Make it Happen, provides a summarized approach to integrating COBOL with the Cloud and Mobile Apps to access Host-based processing and data. In other words, keep the back-end COBOL processing and data access layers and connect them up with newer technologies on the front end. They see updating Mainframe legacy systems, such as COBOL, as vital in this era of Digital Transformation.

From an application programmer perspective, it sounds like a good organizational strategy to leverage the backend COBOL applications that have been successfully used for years while giving the users the benefit of an updated frontend experience.

Some Challenges:

A big question in all of this though is the security of the data. The financial institutions, such as banks and insurance companies, and the government departments that run COBOL systems will have to ensure the safety of the data being displayed and processed with the new technologies. It will mean cultural change as well as technological change. Digital Transformation is not a strategy to be taken on lightly.

What do you think this will mean to the jobs of legacy programmers? What will be the potential impact of cultural change on traditional organizational infrastructures?

 

 

COBOL from a 1969 Perspective

Photo of the Author’s personal copy of Jean E. Sammet’s 1969 book, including a section on COBOL

While researching my article, Jean E Sammet-One Woman Programmer’s Lifelong Success Story, I started thinking about buying a copy of Jean Sammet’s book, Programming Languages: History and Fundamentals. The more I thought about it, the more I wanted to own that piece of history. Somehow it is very attractive to me to be able to look back and see the history of the COBOL language as told by someone who was involved from the beginning. In spite of having worked with COBOL for almost 25 years, I haven’t thought much until recently about its origins and where it fits in. Even though Jean’s book is over 50 years old, I was able to easily find a used copy online.

A Piece of Programming History

Considering it was written by one person, I wasn’t prepared for the amount of detail the book contains in its 737 pages. There is a general discussion of 120 languages, along with sample programs that include the basic components of 30 languages. It was described on the book cover as a single source where “the reader can find basic information about all of the major and most of the minor higher level languages developed in the U.S.” All in all, it is an incredible snapshot of the world of programming in the year 1969. I’ve included a picture below of the sample COBOL program found in the book.

A section in Jean Sammet’s 1969 book that shows a sample COBOL program
COmmon Business Oriented Language

COBOL is found in a section titled “Languages for Business Data Processing Problems”. It is, of course, the major Business language described. I love the fact that Jean included a footnote in her “History of COBOL” indicating that she had inside information on how COBOL came into being because she was there from the beginning in 1959. This is the note in her own words:

“Since I was present not only at this initial meeting (representing Sylvania Electric Products), but also chairman of two different task groups of the Short Range Committee, the historical description of the early COBOL work is based on firsthand knowledge and participation, and is supported by appropriate documents (some of which I wrote at the time).”

The detailed history described in this book is only 10 years old at the time of writing, and it is interesting to see the stages in the early development of a major computer language during the late 1950s and early 1960s.

The Committees

According to Jean’s description, there were initially supposed to be 3 committees involved: Short Range, Intermediate-Range, and Long Range. The Short-Range Committee included 6 competing computer manufacturers of the time: Burroughs, IBM, Minneapolis-Honeywell, RCA, Remington Rand Division, and Sylvania Electric Products. They were only supposed to identify what was wrong with existing business computers, but they ended up trying to develop a new language in a 3-month timeframe. They succeeded and created the first usable version of COBOL by the end of 1959.

That seems like a major accomplishment in such a short time, but Jean notes in her discussion that they did not have enough time to include everything that would be needed to do business data processing programming. As a result, during the 1960s, a Maintenance Committee, made up of users and manufacturers was organized and reorganized for the purpose of changing and improving the original version. The members of this committee came from several major organizations of the time: Bendix Computer Division, Control Data, DuPont, General Electric, National Cash Register, Philco, and U.S. Steel.

Imagine all the major companies getting together today to develop a programming language in just 3 months. It would probably never happen. In recent times, individuals in one company, as opposed to groups of companies, develop computer languages. A couple of examples are James Gosling, who worked at Sun Microsystems and founded Java and Guido Van Rossum, who worked at Google and invented Python. An interesting observation that Jean mentioned in her book was that she had never known a group of competitors to work together to develop a language that they could all use for the overall benefit of the customers.

The Future

The fact that COBOL is still widely used, over 60 years later, by large organizations such as insurance companies, banks and government is a tribute to the strong beginning that started with a committee of rivals working together for a common good. Maybe this is the type of collaboration that is needed to develop a language to replace COBOL, and that is why a suitable alternative was never developed.

We can only guess what may become the common business language 50 or 60 years from now. Will it be as durable and longlasting as COBOL? Only time will tell.

References

Sammet, Jean E., (1969). Programming Languages: History and Fundamentals (shown below), Prentice-Hall, Englewood Cliffs, NJ.

Modernization, Redesign, Renewal–A Revamp of a Legacy COBOL System

Original Photo, Edited by the Author to add text

Given an outdated COBOL legacy system that is possibly 30 or 40 years old, there are multiple ways to do a rewrite that will breathe some new life into it.

Modernization:

First, you could do a COBOL modernization. Modernizing an application involves rewriting an existing COBOL application in a newer language, such as Java. It means interpreting the existing logic and converting it into the new language without reusing any of the existing COBOL code. The existing data storage may be reused in this method if you can connect to it through the new technology. For example, a Java to DB2 database implementation, replacing a COBOL to DB2 database implementation.

Redesign:

Another overhaul method is a redesign, which would entail rebuilding the current COBOL-coded logic into a newer design. This would, in effect, mean replacing the inevitable mishmash of spaghetti code that accumulates after 30 or 40 years of continuous coding changes. For example, the logic could be redesigned into a three-tiered model that separates out the presentation, business, and data layers. This type of modularization makes the code more efficient and easier to debug.

Renewal:

A third example of a revision is a renewal. This type of rewrite requires an analysis of the existing COBOL code, looking for possible improvements, and focusing efforts on those areas. Other items in the code that are functional are basically left ‘as is’ in this method. For example, this could mean pulling repetitive logic out of the existing system code and replacing it with a Business Rules lookup procedure. This would make the logic more efficient and easier to maintain.

 

As a COBOL coder for the last 25 years, these are the main types of rewrites that I have been part of or have seen. I am sure this is not an exhaustive list and there are probably as many permutations and combinations of possible restorative methods as there are system designers.

What are some of the COBOL Legacy overhauls you have seen? Why were they initiated? Did they go to completion? Were they successful?

 

5 Reasons Why COBOL is Ideal for Remote Computer Work

Background from Canva, Edited in Canva by the Author

Especially with the recent world events, today’s society has so many available forms of remote communication software, such as video conferencing, teleconferencing, chat, and email, to name just a few. It should be a given that every Information Technology organization offers workers, who have proven their reliability and work ethic, the opportunity to work remotely at least for a few days a week.

Due to the stability of its environment, COBOL is particularly suited to a work at home scenario. This discussion assumes that the employer has given their employee remote access to log on to the corporate Mainframe. Presuming that the environment is also set up and accessible remotely, as an experienced COBOL programmer, these are 5 reasons why I think that COBOL programming should be considered a remote job:

  1. Environment Setup:

A Mainframe session can be connected to remotely and the programmer has ready access to the whole Mainframe development environment. There is no need to have servers or separate software on the remote computer. The programmer can log on to the mainframe, write and compile programs. They would also have access to CICS sessions to execute online programs, as well as JCL to run their programs in batch.

  1. Access to Connecting Applications

If your application needs to call, or be called by, another application, logging on to the Mainframe remotely facilitates access to these other applications. Some coordination is required to ensure that all of the applications have current versions and up to date data available, but all systems can work on the same mainframe, with the programmers doing the work remotely.

  1. Access to Test Data

The types of businesses that use COBOL are banks, insurance companies, government, etc. Due to the nature of these businesses and the fact that they support large amounts of data, a Mainframe is ideally suited for their purposes. As a result, when the remote COBOL developer logs on to the Mainframe to do their programming, they also typically have security-restricted access to large amounts of Mainframe test data.

  1. Ease of Coding

Since the syntax of COBOL is similar to natural language, it can be easily coded from system specifications. Given such specs, a remote programmer can effortlessly translate the user requirements into COBOL code without the face to face interaction that an analyst might need to have with the user in order to create the specifications.

  1. Many Programmer Roles

A COBOL Programmer generally wears several hats in their role. The programmer may have to interpret the system specs given to them by the analyst. In this context, they take on an analyst role. When their coding is complete, the programmer will also perform basic unit tests before handing it over for system integration and user acceptance testing. In this way, they become a tester. Since the programmer has so many responsibilities, they are always busy with measurable tasks. This is something fitting to remote work, since their work can be easily tracked.

These are some of the reasons why cities and organizations still ran well during a country lockdown with mandatory work at home rules. COBOL is basically a plug and play computer language.

As long as there is remote access to a Mainframe that has already been set up to code COBOL and an experienced programmer to write the code, working at home is quick and easy and should be considered on an ongoing basis.

 

Have you had experience with other languages that may be as easy to code remotely as COBOL? What would be the pros and cons of remote workers programming in other languages?

 

 

COBOL on Social Media

Photo from the Author’s phone screen
The Programming Professional on Social Media

When you think of the various Social Media Networks, LinkedIn is the first one that comes to mind as the main professional Social Media resource. Professionals looking for, and providing, information in their field would tend to look there first. Unfortunately, what’s often missed, are the sometimes hidden gems of information garnered through Facebook pages and groups, Twitter tweets, or Pinterest pins. For the purposes of this discussion, I’m going to use the example of “COBOL Programming” to illustrate that there is information to be found on each of these Social Media Networks for Programming Professionals

Facebook as a Programming Resource

After doing a search for the word “COBOL” on my Facebook account and scrolling through the results, I can see that there are several types of information that are available and useful to both the new and experienced COBOL Programmer. Of course, given the volume, you would need to take time to filter through each type and determine if it is current, valid, and useful to your context. On a cursory first glance though, in the list of pages to “like” and groups to join, one group that stands out is “COBOL Programmers”, which currently has 10,775 members and has daily activity. Members frequently post interesting information and other members ask related questions. With almost 11,000 experts at your fingertips, how could it not be a useful resource?

The COBOL Facebook search result also came up with PDF links for COBOL tutorials, programmer guides, and professional blogs (such as the Micro Focus Company blog). If they were to be cited as professional sources of information, these documents would have to be verified as reliable resources. This article, “How Can I tell if a Website is Credible”, provides some helpful ideas for what to look for in determining the credibility of a source.

Professionalism in Twitter Tweets

A search for COBOL on Twitter revealed a smaller presence than on Facebook. However, there are some Twitter COBOL-related profiles that are recently active and have tweets with interesting links. One of note is “COBOL60” that celebrates the 60th birthday of COBOL in a professional manner. The tweets on this profile typically contain links to courses or related websites. Again, some time would be necessary to read through thoroughly and filter the information, for credibility.

Below is a screenshot of my COBOL search result on Twitter. As well as several COBOL-related “People”, there is also professional noteworthy information under the “Photos” and “Videos” sections from such companies as Micro Focus, Red Hat, Raincode and others.  COBOL information for the professional is also present on Twitter.

Pinterest for Computer Professionals                                                                               

Pinterest is a Social Media, online service, that allows users to organize and share images and videos. A search on COBOL in Pinterest resulted in many, many pins. From a Professional perspective, several of the pins are for COBOL courses and tutorials of varying levels, debugging tools, and related programming information.

To be honest, I hadn’t considered Pinterest as a resource for job-related information before. After this first look, I can see that there could be a whole separate discussion on the programming information and categories available on Pinterest. I can’t wait to get back to it to start organizing and filtering some of the useful information I’ve seen.

The future of Professionalism on Social Media

With Social Media advancing at such a fast rate, it’s hard to predict its future.  A recent article,“What Will Social Media Look Like in the Future” discusses possible future trends such as:

    1. More privacy and security
    2. More video
    3. Less personal content
    4. Premium services and fewer ads
    5. Mobile focused experience
    6. Less typing, and more visuals

Only time will tell if the future will find Social Media moving more toward the informal or more toward the formal.

If you haven’t done it already, think of your own work-related topic and try to research it on Social Media. You might be surprised by the wealth of information you find.

Jean E. Sammet–One Woman Programmer’s Lifelong Success Story

Background from Canva, Edited in Canva by the Author

Computer Programming is now considered to be a male-dominated field. However, early in the history of computers, there were several women involved in developing the original languages.

One of these accomplished women was Jean E. Sammet, born March 23, 1928 in New York, New York. According to the history of computers, she was a member of the CODASYL COBOL committee, from 1960 until 1964; chairman of the Short Range Subcommittee, which developed all the statements of COBOL language; originator and developer of FORMAC, one of the earliest formula manipulation languages; leader in language systematization and historian of computer languages.

Jean’s book, Programming Languages: History and Fundamentals (shown below), Prentice-Hall, Englewood Cliffs, NJ., 1969, contains a description of the histories of many languages, along with technical information.

Photo of the Author’s personal copy of Jean Sammet’s book

When Jean Sammet passed away on May 20, 2017,  her obituary quoted her as saying in a 2000 interview, “I thought of a computer as some obscene piece of hardware that I wanted nothing to do with.”

However, she also indicated that, in the late 1950’s, jobs as computer programmers were easy to get. In fact, Jean told an interviewer for Glamour Magazine that “At that point — and this is my opinion; I know other people my age don’t agree — there was relatively little discrimination against women, because programmers were very scarce. And so it didn’t matter whether you had three heads.”

Despite the acceptance of women in the programming field at the time, according to the Memorandum written on her death by the Association for Computing Machinery (ACM), when Jean decided in 1958 to leave her job to work for a company with computers as its focus, she found there were no relevant classified ads for such jobs for women: the classifieds at the time were segmented by gender. She applied to ads for men instead, and she was hired by Sylvania to oversee software development for the U.S. Army’s Mobile Digital Computer (MOBIDIC).

An article of the top 10 women in Tech reported that it was programming calculations onto cardboard punched cards, fed into a computer, that first made Jean love computing. As a result, she joined IBM in 1961, where she worked until she officially retired in 1988. Grace Hopper is often called the “mother of COBOL,” but Jean Sammet was one of the six people who actually designed the language.

The ACM also indicated that, in 1977, she organized the first History of Computing Committee for the American Federation of Information Processing Societies (AFIPS), and served as its chairperson. In addition to encouraging the creation of archives for materials, the committee publicized the importance of industry professionals’ saving materials.

Jean commented on her own experience with saving papers:  “From childhood on, I hated to throw papers away. As I became an adult, this characteristic merged with my interest in computing history. As a result, I created important files and documents of my own, and became concerned with having other people publish material on their important work so the facts (rather that the myths) would be known publicly.”

As a result of her long and successful history as a woman in technology, Jean Sammet serves as an inspiration to the next generation to continue her work in documenting and sharing technical information.

If you’re a member of the IT community, think about how the environment looks today. Do you find discrimination in the IT world? Are there some people who still think of computers as a negative? Can you think of any current famous female role models in technology?

How Do You Demystify COBOL?

Photo from Canva, edited in Canva

How do you go about demystifying a programming language? As an experienced COBOL programmer, I could write endlessly about syntax, design, debugging, development environments, etc. In the end, the real way to take the mystery out of COBOL is to explore its past through the people who have coded it and the history behind it. As a language that just turned 60, there’s a lot of background to search through and connections to be made.

Introduced in 1959, COBOL has managed to stay relevant through 5 generations of people, massive technological changes, as well as changes in the demographics of its coders. Did any of these influences affect methods and style of coding? Of course, they all had an impact on how COBOL applications were being designed and developed through the history of the language.

Future posts may be opinion pieces, based on subjective experience, or research essays, based on observations of others. However, over time, it is the hope that future posts on this blog will include topics of discussion taken from each of these 3 factors in an attempt to demystify COBOL.

Traditionalists to Generation Zers

For example, there are 5 generations of COBOL coders: Traditionalists, Baby Boomers, Generation X, Millennials, and Generation Z. This Generational Differences chart summarizes the differences between the first 4 generations and provides characteristics of each. Not included in this chart, the most recent generation, Generation Z, is the generation that was born between 1996 and 2010. This age group has grown up with the Internet and Social Media. Several interesting possible future blog posts would be how the values, attitudes and work ethics of each of these 5 groups may have influenced coding in programming languages, specifically COBOL.

Changing Technology

With technological advances, coding tools have also changed over the years. COBOL has managed to compete with newer coding languages like Pascal (1970s), C++ (1980s), Java (1990s) and has stood the test of time. This timeline of programming languages provides a good illustration of programming languages in history . Also, the introduction of personal computers allowed for Graphical User Interfaces (GUIs) as well as Integrated Development Environments (IDEs). The advent of cloud technology will no doubt lead to many fascinating future COBOL impacts.  As a result, due to the number of years that it has existed, evolving technologies can lead to a variety of comparative discussion topics involving COBOL.

Women in Technology

One of the major demographic factors in any discussion topic involving programming, and its evolution over time, is gender. Women have played major roles in the history of technology, from Grace Hopper, who is credited as being the inventor of COBOL, to Ginni Rometty, who is the current CEO of IBM. There have been many fascinating women associated with the COBOL programming language. Something to share in this forum is how exciting it is to be a woman in technology today with a perspective on the past and anticipation for the future.

 The Future

As the name suggests, this blog, over time, will attempt to demystify COBOL with its posts, links and overall theme. The conversation will focus on the stability and relevance of the language, while the associated coders, technologies and the demographics have all continued to evolve over the 60 years of COBOL’s existence.

Even though these subjects will be the main focus of future posts, if you have a specific COBOL related topic you would like to see covered, feel free to suggest it.

Yes, COBOL Coding is Social

Image from Canva, Edited in Canva by the Author

The picture of a COBOL programmer hunched over their desk, day in and day out, in isolation, pumping out thousands of lines of code is unrealistic, especially with the Agile mentality of today’s IT world. Currently, to be a successful programmer, in any language, you need to interact continuously with your client and your team in an effective way both orally and in writing.

Client Service

In fact, coding is essentially a client service. Someone has requested a piece of work from you, and you provide that client with a finished product, in accordance with their requirements. The client is then able to see the work as it progresses and provide feedback. In another version of client service, the coder may not communicate directly with the client. They may provide service to an intermediary, such as a business analyst who in turn passes along status updates and other information to the client. In any case, the COBOL coder is constantly involved in providing client service.

Teamwork

The COBOL coder typically works closely with a team. The team may be comprised of a team leader, business clients, analysts, testers, coders, designers and whatever other specialized roles may be required. As previously mentioned, it is unusual for a COBOL coder to work in isolation. At a minimum, the program(s) being developed are attached to business requirements, often integrate with programs written by other coders and need to be tested.

Effective interactive communication

In addition to writing program syntax in a logical way, the COBOL coder must also be able to communicate verbally as well as in writing. Programmers may need to attend several meetings a week to provide updates and answer questions as required, so they need to be able to communicate effectively vocally. In today’s context, they may even be expected to present, or demo, their work. Excellent written communication is also a must-have for a programmer. Their job may depend on being able to receive requirements and specification updates by email and being ready to respond to any questions/concerns that might come up.

Contemporary Programming

Programmers have moved on, but the out-dated misconception of them as loners, who rarely move out of their cubicle to interact with the outside world, has not. Programming can be a very exciting, interactive career, not the lonely one that is often portrayed.

If you are a programmer, do you agree? Disagree?

If you are not a programmer, take a minute and think of what your picture of a computer programmer is. What’s the first descriptive word that comes to mind? Is it a positive or a negative word?

The First Computer Bug Ever — Literally

Image from Canva, Edited in Canva by the Author

In the modern information age, most of us take the terms “computer bug” and “debugging” for granted. In fact, computer literate people probably can’t remember a time when an alternate meaning for “bug” wasn’t an “error in a software program or hardware system”. There is, in fact, an interesting story behind the adoption of the bug reference.

The Background

The tale begins with Rear Admiral Grace Brewster Murray Hopper. Born in 1906, Admiral Hopper was a gifted mathematician. She was one of the first programmers of the Harvard, Mark I computer. One of her other claims to fame is that she was responsible for the development of the COBOL (Common Business Oriented Language) computer programming language. COBOL is still widely used today in software programs that power banks, insurance companies, and governments. In 1952, she also invented a compiler that converted instructions written in the English language into computer code. This YouTube video from Biography is a summary of Grace Hopper’s accomplishments as a computer scientist and military leader.

The First Bug

For many years the term bug was used by engineers to refer to anomalies. According to history, the world’s first computer bug was found on September 9th, 1947 by Grace Hopper in the Harvard, Mark II computer. The story goes that a computer at Harvard wasn’t functioning properly. When it was opened, a dead moth was found in the relays. The crew taped the bug to their logbook entry and wrote “First actual case of bug being found”. The log update is widely thought to have been done by Grace Hopper. The bug and the page it’s attached to are on exhibit in the Smithsonian’s Museum of American History.

The Future

With Artificial Intelligence becoming increasingly popular, it’s hard to predict how software bugs will evolve in the future. Maybe in a few years, a common “bug” will be the fact that our electronic assistant doesn’t remember our favorite restaurant or theatre.

What’s the worst computer “bug” (software or hardware glitch) you’ve ever had?