The Many Faces of Application Creation: Part 2

This is a continuation of last month’s article, which chronicled application tools and options in context of development projects I’ve worked in and programming alternatives used, including design, coding, and validation. I’ve used various programming facilities, along with their strengths and weaknesses. My experiences start in the early 1970s, and the evolution I’ve experienced spans program languages, interfaces, command processors, tools for design, debugging and quality assurance.
 
Part 1 of this article covered the creation, strengths, weaknesses and progression of early languages, primarily Fortran, COBOL, PL/I, RPG, and Assembler. This treatise described where they were used, what they were used for, why they were used and some related applications. Programming interfaces—proprietary functions usually embedded in vendor products and codified to simplify programming—were also discussed using examples of where and how interfaces could be implemented. We now continue the discussion:

Program Generators

I have hands-on experience with two program generators: Telon (it’s not an acronym), and Entry Level Interactive Application System (ELIAS), and both contain functions to simplify, automate and improve application design, development, usability, and implementation. Functions include interactive, online code generation of database, file, online transaction, security, application and special-purpose subroutines that implement unique methods, or programs executing extremely complex or proprietary techniques. The generators support multiple languages and platforms.
 
Based on my generator’s usage, I have mixed feelings. The positives:

• A program generator does improve productivity via an online code creation interface, logic error detection, standards enforcement and simplified access to documentation
• Program generators assist development maintenance by producing flowcharts, design specifications, data administration, prototyping and a design facility
• Generated code can be maintained, enhanced and debugged in native language 

The negatives:

• There’s often a price to pay in performance. The best way to handle performance concerns is to perform tuning during QA, where some performance restrictions can be tuned.
• There may be programming the generator cannot produce, mandating standalone coding
• The more complicated the process, the less effective the generator, e.g. inquiry-only programs are simpler than updaters, limited-function programs are easier than complex ones. Simple function generates easier than complicated logic.

A COBOL client of mine initially used an application generator extensively while also coding substantial standalone COBOL, soon using standalone more than generation. They installed the generator for productivity, and they created a few small applications before deciding to limit use to small projects and subroutines for use with more complicated applications. As has been true with other programming tools and facilities, most program generators have improved as they matured and some shortcomings have been mitigated.

Screen Definition and Layout

While code generation had limited value to this client, its Panel Specification screen was heavily used and greatly valued for online applications, where screen design is a key component of application usability, and because screen definition for CICS applications which used Basic Mapping Support (BMS) was convoluted and cumbersome. BMS consists of macros that must be coded to specify characteristics like screen position (line and column), length and other vital parameters, lacking the ability to show the screen until the BMS definition was compiled into a program and executed in a test system.

Command Languages

Command languages are primarily used to create procedures, and aren’t usually used for business applications, but there are times they’re extremely useful—automated operations, computer/network administration and other system functions, especially supervisory functions for applications. Command languages consist of commands, variables and sometimes relational operators. Command examples include:

• CD: Change Directory
• DEL: Delete
• OPEN: Open file, connection, device
• AL: Allocate
• STOP: Terminate a job or process
• REORG: Reorganize a file or database, etc.

Command language code is created from commands modified by parameters (syntax varies with platform and operating system). Scripts using command language with parameters and substitution fields can be written to perform many system level functions very simplistically. They can be either operator or conditionally initiated, with or without console input values. Sample functions include taking a file offline, submitting batch jobs, initiating backups, archives or job initiations based on job statuses, manually entered, and other events.

Primitive Programming Interfaces

My definition of a primitive programming interface is a code fragment that provides a singular, fundamental function, plus mandatory aspects (i.e. error handling), which can be invoked by other code to perform its purpose. It’s a facility that hearkens back to the advent of programming, when it became apparent inter-program interaction was vital. A primitive programming interface provides a basis for more sophisticated programs to implement. Primitive interfaces can be exploited and utilized by putting transformative code—a.k.a. “matchmaker” code—between programs to simplify development of large or difficult projects.
 
My most recent and interesting experience with a primitive programming interface was implementing encryption for Payment Card Industry (PCI) data with a mail-order firm. This client had no experience with encryption, its systems didn’t have the capability, and I had little cryptographic experience, producing a formidable challenge. The first step—install cryptographic software and hardware—was relatively straightforward because I had a strong background in that sort of work. I researched and recommended a product called Integrated Cryptographic Service Facility (ICSF), developed a plan and rode herd over product installation, which went smoothly.
 
ICSF only provided a primitive interface—native, cryptic subroutine calls—and only returned encrypted card number plus error codes. The client’s programmers hadn’t a clue on coding an ICSF call, what its parameters meant or how to handle error codes. Since virtually all applications handled cardholder data, most programs were affected; ignorance plus gargantuan project size was problematic. Even worse, PCI standards dictated cardholder data must be encrypted immediately upon reaching the computer, a requirement that mandated a process called tokenization.
 
Tokenization is a methodology whereby a value—in this case, record key of encrypted cardholder data—is replaced with a placeholder value for the original key using a randomizing algorithm to create a token, a process that substantially increased coding effort and complexity. This meant more training and time spent programming to perform a project imposed on the client by the PCI. Having an already heavy backlog of projects, my client felt trapped between a rock and hard place, and I felt likewise, because I couldn’t fulfill my contract without their staff.
 
So I locked myself in my office and took a self-imposed crash course of all ICSF, client-supplied and PCI-compliance documentation, then designed and coded both online and batch matchmakers that insulated programmers from the vagaries of ICSF calls, interpreted and handled error conditions, and tokenized cardholder data. Programs used EXEC CICS LINK to connect to the matchmaker for both online and batch, cleanly separating the primitive interface from application code, the same approach more advanced interfaces implemented to “make a match” between user programs and primitive interfaces.

Cross-Platform Development

Most programming tools are multiplatform, which enables multiplatform development. I and my staff took on a project to convert an insurance company’s IMS/DB/DC insurance claims processing system to CICS TS and Db2, and we started by downloading their IMS programs and data onto Windows-based desktops running MicroFocus CICS, SQL, and IMSVS86 Option DB/DC. We loaded IMS databases into IMSVS86 and IMS DC programs into text files, then converted IMS DC calls to CICS commands and IMS DB calls to SQL. Workstation testing was limited but extensive, then programs were uploaded, recompiled, and validated.
 
The ultimate verification was on the mainframe, where converted code would run against large test databases. After building a mainframe test system, the client’s QA unit devised scenarios and executed them. They validated screen design, transaction results and test cases. Errors, transaction flow issues, or design inconsistencies were documented and sent to us for correction. We resolved all issues, created supporting documentation, and after extensive validation, the customer moved to production.

Multiple Options, Diverse Tools

A pair of articles can barely scratch the surface of the vast landscape of programming tools and practices that span the sprawling world of technology, but they provide an overview of alternatives available to the business world. It’s good and bad news: Many options mean a lot of work to choose the right solutions, and can consume much time and trial-and-error experimentation, yet the expanse of solutions means there’s one that suits your needs. It’s a constantly moving and changing target that both challenges and rewards firms that seek to optimize staff performance.
 
 

---