Presenting a Historical View to Understand Our Future

In our former technology world, the mainframe, we were kings and queens. Yet, we often stumble with confused looks on our faces when making this journey to "the other side," to PCs and Windows programming. Based on our expectations, this should be a simple transition, right? We only set out to change programming languages and use a smaller, more personal piece of hardware. Yet, it seems that our new peers in the "PC world" are not only programming in a different language, but also talking and thinking in a different language. Actually, I hope that you are reading this book before subjecting yourself to what might sound like a nightmarish learning curve (the remainder of this chapter aims to flatten that learning curve out).

Consider this phenomenon : There has long been a push to reinstate the teaching of COBOL ^[1] in the college curriculum. Isn't it interesting that you hardly hear mention of the teaching of other technologies that a typical COBOL programmer equally depends on? I will illustrate the importance of these other technologies by recounting the details of a real-life story that occurred years ago at one of my former mainframe corporate homes .

Note  

Bear with me while I go into significant depth. I am certain that you will later appreciate the relationship between this historical look backward and your .NET future. Remember, understanding (and remembering) our history helps us understand and plan for our future.

Years ago at company XYZ, ^[2] we hired a college graduate who had taken several COBOL computer-programming courses. For simplicity, I will refer to him as "Bob." Bob's job description called for a junior-level computer programmer. This looked like a good fit after a few adjustments. Our adjustments had more to do with our approach to training than anything else. Naturally, there was no need to "train" our new graduate how to code a program in the COBOL language.

Bob took great pride in being able to quickly recite the COBOL syntax rules and COBOL statements in alphabetical order. We (the mainframe veterans ) were impressed. Yeah, right! We constantly made joking comments about how this "newbie," "our rookie," was still wet behind the ears. Looking back, perhaps it was cruel . Admittedly, this new employee of ours would have put us to shame if we had to divulge our SAT scores. Nevertheless, we saw it as naive that someone would take a couple of COBOL classes and expect to be able to actually program afterward. To prove our theory, we gave Bob the simple task of creating restart/rerun documentation for a given production job stream. After seeing our new junior programmer struggle for a while, I am proud to say that we eventually created a training program ^[3] based on the following eight phases:

1. Roles and responsibilities

2. Production support

3. Systems support

4. Editing/browsing/program development environment

5. Third-party development aids

6. File access methods and utility programs

7. Relational database programming

8. Online interactive transactional programming

Phase 1: Roles and Responsibilities

We first laid out an entire map to communicate the roles and responsibilities of the various people and positions that existed in the organization. This went beyond the normal idea of an organizational chart. The focus was more on the tools, technologies, and responsibilities that existed in the organization. This map made clear how each technology's usage related to, interacted with, and depended on the others. In other words, we felt it was important to present the "big picture" ”the interrelationships that existed in our organization from a technical point of view. Not only did this enable Bob to operate efficiently , but it also helped give him an accurate perspective of and appreciation for his own role.

Phase 2: Production Support

The next training step really seemed to confuse Bob at first. We had him spend a few days in the shoes of the computer operator and then in those of the production control analyst. We felt that it would be important for him to meet and "live the life" of those who would be ultimately responsible for scheduling, executing, monitoring, and possibly helping troubleshoot his programs. This worked out great. By the time we rescued Bob, he understood the difference between the Multiple Virtual System (MVS) operating system and the Job Entry Subsystem (JES2). He even understood what system initiators were and how to use basic MVS and JES2 commands. Had we retrieved him later, the support staff would have introduced Bob to his first system initial program load (IPL). As Bob was saying good-bye to his new pals, he turned and jokingly said, "Watch out for those SB37 and S122 system completion codes." We exchanged a stare and smiled.

Phase 3: Systems Support

We wanted to strike while the iron was hot. Therefore, we rushed Bob over to chat with the systems programming staff. There, he met staff members who proudly explained their roles and responsibilities. Bob seemed impressed as he quickly noticed the difference between a "systems" programmer and an "application" programmer. I remember him taking notes, writing down terms such as "database administrator," "network support," "Customer Information Control System (CICS) support," "direct access storage device (DASD) management," and "security administrator."

At this point, we decided that Bob had wandered around the building enough. We asked the security administrator for Bob's user login and off we went to Bob's new desk.

Phase 4: Editing/Browsing/Program Development Environment

Our first area of actual technical training was in the efficient use of the Time Sharing Option (TSO) and the Interactive System Programming Facility (ISPF). I admit, we assumed that any student who had learned COBOL in a formal class setting already would have been introduced to these tools. Much to our surprise, that was not the case. The college that Bob had attended opted to use a lesser-known editing/browsing tool. Bob seemed convinced that this was "transferable" knowledge. As it turned out, it was to be a significant training effort. For example, we started by explaining how he would want to use each of the ISPF options.

The next thing we knew, we had several subtopics that would each need an individual focus for explanation. Among the subtopics were source code management, SuperC Compare Utility, dataset file allocation, and TSO commands. We went through all of these with Bob. Just when we thought we were done, Bob stumbled across another ISPF option that we had not explained. It, too, brought to the surface a couple more subtopics: System Display and Search Facility (SDSF) and Job Control Language (JCL).

As Bob sat there looking dazed, I vaguely recall him mumbling something that sounded like "They lied. They had promised us that the college's editing tool was going to be transferable knowledge." This was the first time I had actually witnessed the deflation of an ego in real time. It was not a pretty sight. In fact, we were afraid that Bob might decide to not return to work the next day. We gave Bob a few days to absorb all of his new knowledge. Then we continued .

Phase 5: Third-Party Development Aids

We then decided to introduce Bob to the remaining set of tools accessed from ISPF. As you know, this would include tools such as the software packages that handled Job scheduling, tape management, Abend recovery, dump reading, and Abend-AID. Additionally, we introduced Bob to the DASD maintenance, interactive, and report archival and retrieval tools that are also accessed from ISPF.

Phase 6: File Access Methods and Utility Programs

It turns out that Bob's COBOL training had included introductions to the Virtual Storage Access Method (VSAM), partitioned datasets (PDS), and the Queued Sequential Access Method (QSAM). The problem was that he had received only brief introductions. Bob understood what a VSAM file was. However, he had no idea about VSAM-related topics such as alternate indexes and the IDCAMS utility program. We quickly discovered that other essential utility programs such as IEBGENER, DFSORT, Dyl280, and even IEFBR14 were all foreign to Bob the graduate. Poor Bob.

Weeks passed, and as you might have guessed, Bob survived. He reviewed, he studied, and he became a well-rounded COBOL batch programmer.

Phase 7: Relational Database Programming

About 9 months into Bob's employment, we provided opportunities for him to learn more advanced levels of programming. We introduced him to database programming using Database 2 (DB2). He studied Structured Query Language (SQL) syntax on weekends. We grilled him daily at work on the various forms of normalization and other relational database concerns. Bob quickly became acquainted with going to the various ISPF options to access the database utility software packages. He said that his favorite was DB2 Interactive (DB2I) and SQL Processor Using File Input (SPUFI). Later, he expressed a strong preference for Query Management Facility (QMF). He bragged about how fast he was able to accomplish some of his ad hoc reporting tasks using his library of saved queries.

Phase 8: Online Interactive Transactional Programming

The day came when Bob celebrated his 1-year anniversary. We were all very proud of him and his accomplishments. As we celebrated with him, we emphasized that he had graduated from his first year of training with honors. As an anniversary gift, we told him that his entire second year of training would be limited to just one new training topic. Bob seemed relieved as he jumped up and down for joy. Then it occurred to him. Slowly, he looked us in the eyes and asked, "Did you say the entire year? Will it take that long?" We replied, "Yes, Bob, welcome to the programming world of CICS."

For the next 12 months, Bob was immersed in new concepts such as multi-tasking and multithreading. He studied to exhaustion the various CICS support tables: program control table (PCT), processing program table (PPT), terminal control table (TCT), and file control table (FCT). Later, we explained to Bob how he would need to build basic mapping support (BMS) mapsets to represent each of his screens. He then went on to conquer various CICS service transactions: command-level interpreter transaction (CECI), master terminal transaction (CEMT), and execution diagnostics facility (CEDF/CEDX). We emphasized to Bob the power of these transactions and how he would use them to test, troubleshoot, and control other CICS transactions. As you can imagine, he finished the remaining year perfecting the usage of CICS commands in his COBOL programs and learning how to properly use CICS's communication area, Execute Interface Block (EIB), and temporary storage queues.

That concludes our walk down memory lane. Bob, have a nice life.

Staying Onboard the Speeding Technology Train

Keeping up with technology is the main requirement for not having the train leave without you. However, you need to have a healthy perspective when doing so.

There is one critical point I would like to make here:

If all you do is take one programming course (in any language), do not expect to hit the ground running. To write enterprise-ready programs, you have to jump in for the long haul.

Failure to thoroughly understand this point, I feel, is the root of many failed reformation attempts. Often, we veteran mainframe programmers venture into the "new" world ”the nonmainframe world. We take one programming course (Visual Basic, for example). Upon completion of the course, we figure, "OK, I am ready to program." Then we, like Bob, are faced with a large dose of reality.

There is an entire infrastructure for any programming language on any platform. Naturally, learning the syntax of a particular programming language is important. However, you cannot stop there.

 

^[1] If that ever were to happen, I cannot help but wonder which "flavor" of COBOL they would teach. Would their approved textbook include any of the COBOL vendor-specific extensions?

^[2] The company's name is not relevant. Nevertheless, in my 20-plus years of information technology experience, I have called the following corporations home at one time or another: HRT IND (aka Hartfield/Zodys); Tenet (aka National Medical Enterprises); Merisel (aka Softsel); Home Savings; The County of San Bernardino; FiServe (aka DataLine); Princess Cruises; Arco Products; Flying Tigers; Wyle Electronics; Pacific Life; Northrop; Experian (aka TRW); and Cendant (aka Coldwell Banker).

^[3] Incidentally, our training program included the practice of having a mentor.