The Many Faces of Application Creation: Part 1
While my career has mostly been consulting, marketing, systems programming and management, I’ve also had numerous engagements in application programming and design. A class in COBOL was my first IT experience, and in my MBA program, I learned Fortran and General Purpose Simulation System (GPSS) in Operations Research classes. In 1975, I rewrote a broken PL/I student records system, learning the programming language from a textbook. Those experiences energized my love of IT, a practice I adored. I unwittingly set the stage for an IBM career, independent consulting and lifelong vocation.
So I had a head start on exploring the many ways to professionally produce code, not just via program language, but editors, print utilities, testing tools, subroutines, linkage-editors, screen definitions, file layouts, shared copy books, Job Control Language (JCL) and productivity tools. The resultant source code could be turned into executable instructions that perform specific operations to modify data, create screens and other processes to achieve an objective. Those early experiences—performed from manuals or textbooks—opened a new world to me.
Programming Languages for Every Need
By the mid-1960s, 20+ programming languages (some precursors to others) were in use on various processors (Burroughs, IBM, UNIVAC, Bell & Howell, Hewlett Packard, etc.). The main machine dependent programming language at the time was Assembler (assembly code), while COBOL, PL/I, and Fortran were dominant business or scientific languages. RPG, APL, Autocode and others were special-purpose coding techniques. These languages spawned new languages as technology grew, such as Java, CC++, C#, Python, SQL, JavaScript, PHP and more.
Basic Assembler Language (BAL) is a language that terrifies some programmers, but I learned a great deal about how a computer works at the hardware instruction level from coding an insurance claims application in BAL for an insurance client. The reason the prototype was written in BAL was because BAL programs generally run more efficiently using less computer resource than any other language, and minimum overhead was the top metric. While not much BAL code is still used, leftovers from the past and situations where high performance is top priority may be the right choice. I had a long-term contract with a client to support BAL code, who used the adage, “If it ain’t broke, don’t fix it!”
COBOL stands for "common business-oriented language," a programming language designed for business use. It’s procedural and was enhanced to be object-oriented shortly after Y2K. It’s the language I’ve worked with most, no surprise since it’s the most widely available and utilized language, running on every IT platform. It’s hard to pick a typical COBOL project because it’s been involved in almost every application development project I’ve directed. Whether it’s mainframe CICS TS or its little brother TX-Series (midrange and workstation/server transaction manager), the application involved COBOL.
While I haven’t much experience with Fortran, I am the proud owner of a circa 1956 Programmer Reference—making it one of the earliest languages—and have used it in a few where the application was scientific or mathematical. I found Fortran easy to learn and use, and often the application was more complicated than the code. It excels at computing applications where many numeric interactions or a large number of calculations are involved.
In addition to the PL/I MBA students system records I rewrote, I and another IBM system engineer used PL/I to produce an IBM Field Program called Trend Analysis under CICS. PL/I is arguably the most flexible, straightforward and functionally-rich language I’ve ever worked with. I learned it without training, and IBM has consistently upgraded it to support such facilities as Object-Oriented extensions. PL/I is more dynamic and better at performing tasks where data structures and usage are not as rigidly defined as COBOL. The reason it’s not as prevalent as COBOL is that COBOL was in IT shops first.
I’ve also worked with Java in a CICS-to-PAYPAL application a mail-order client contracted me to create. The purpose was to process order payments as product purchases were made, to process the payments, reject the order if the payment failed, confirm time and date of the transaction, and to provide payment failure information where the transaction was rejected. Two interfaces were involved: One between CICS and Java, and a second interface that interacted between the Java code and PAYPAL.
Product Programming Interfaces
Using a programming language isn’t the only way to produce or enhance application code; many products such as CICS TS, IMS DB/DC, and Db2, for example, provide application programming interfaces that can either provide function via commands (e.g. an SQL statement using ISPF), a procedure language (REXX), or embedding source code into an existing program that invokes the software interface. Prior to program compilation, a preprocessor uses the keywords and accompanying parameters to produce programming language (COBOL, PL/I. etc.) statements that issue some form of call to invoke programming interface functions.
A useful example of a programming interface is CICS Command Level (also implemented in TXSeries for multi-platforms). Commands are keyed into source code just like program language statements, and begin with keywords “EXEC CICS” which notifies the CICS Command Level preprocessor that the following statement is a CICS command specifying a read file operation with parameters to further define the process:
EXEC CICS READ FILE INTO (RECORD-AREA) RIDFLD (RECORD-ID) LENGTH (RECORD-LENGTH).
- RECORD-AREA, RECORD-ID, and RECORD-LENGTH are Data Division storage definitions
- RECORD-ID has been initialized with record key or CICS will populate it after the record is read
- RECORD-LENGTH is processed the same way regarding record size
- RECORD-AREA is processed the same way regarding the storage where the record will be placed.
- Error conditions are provided if an error occurs
- If the command succeeds, file or database contents can be accessed via RECORD-AREA storage
Similarly, SQL using Db2 can be used standalone or embedded in source code, invoke its pre-compiler and be compiled into a load module like Command Level. For CICS, EXEC SQL keywords will invoke the pre-compiler to parse and translate the SQL statement into the same source language as the transaction program, as well as establish appropriate linkage so the SQL request will be routed to Db2 for execution, resulting in requested data retrieval, then passing it to CICS and the requesting transaction.
In the case of CICS TS and TXSeries, there’s another capability that enables interaction between programs of different languages, in this case between different instances of CICS TS and/or TXSeries: the EXEC CICS LINK and the EXEC CICS XCTL commands. Both commands provide similar function to a COBOL, PL/I or other program call, but with language independence. The EXEC CICS LINK passes control from a currently-processing program to a program in the same or another copy of CICS or TXSeries on the same or different processor, or even a non-CICS system on the same MVS.
When LINK is used, transaction control is unconditionally passed to the LINKed program specified in the PROGRAM parameter one logical level below the LINK-issuing program. That second program can also LINK to another program on the second logical level, etc. When lower level programs have completed via RETURN commands they return control to the program above them. Programs using XCTL transfer control to another program and terminate without return. Either way, a COMMAREA or CHANNEL specification passes data with control, all language independent.
Abundant Tools and Potent Functions
The choice between languages, interfaces and which to use have grown dramatically since these tools were just emerging. At that time, commercial applications were growing from infancy, so choices were few. Businesses were just beginning to see IT’s positive impact on their enterprises, and as hardware and software advances accelerated—based on the impact Social Security Act of 1935 had on IBM’s computer production—aggressive development of automated applications to streamline company processes became an avalanche.
Writing code was originally cumbersome and functionally limited, with most application development starting from scratch and little software beyond an operating system—itself bare-bones—so programming language development began in earnest. The choices and benefits today are plentiful, and the choice of programming interface often depends on choice of systems and software development, although sometimes the opposite is true. The products and methods used to produce business applications are constantly evolving and will continue. Most languages in this article are multi-platform. Making good choices is imperative.