Heirloom Elastic COBOL Interactive Development Environment is powered by the Eclipse open source platform so developers can adapt and extend their development environment to match their needs and increase their productivity. Here are a few examples of where productivity will improve for building new COBOL applications or maintaining existing ones.
During the coding phase
Elastic COBOL leverages Eclipse techniques that have been used in the Java world for years. A syntax-directed editor shows keywords, variables, constants, etc. in different fonts and colors to make a program more readable. Command-completion makes it easy to enter new COBOL statements or find variables that were designed above. A COBOL Outline View will show data division sections and procedure division paragraphs allowing one to quickly jump over large sections of code.
Suppose the programmer accidentally deleted a few lines of code and saved the modifications. Integration with Eclipse source code control plugins such as GIT and Mercurial HG allows you to "commit" changes to a repository shared across multiple workstations or with a global workforce. Even if you don't commit, you see local changes. More than a simple undo/redo facility, Show Local History will show all changes made that day or prior days on that workstation. Compare To will display a multi-pane diff panel allowing some or all changes to be selectively reverted.
How do you do that with ISPF development on a mainframe? You cannot, because the file was saved; there is no undo here, so the programmer would need to either recover the backup copy or retype it.
Programs that use COBOL line numbers in the first 6 columns as a way of identifying documentation can be renumbered automatically by the Elastic COBOL IDE from within the editor either in whole or in part.
During syntax checking (Compilation)
The Elastic COBOL IDE will Build Automatically and check syntax on Save providing immediate feedback to the developer. Errors, warnings and informational (programming practice hints) messages are displayed on the line they are indicated. No need to exist the Eclipse environment to build in batch as would be required on the mainframe. This is exactly the same behavior that Eclipse uses for all syntax errors in other file types, like HTML, JSP, Java, XML, and others.
Although the COBOL developer might not be interested, his Java brethren can quickly see an alternative perspective of the COBOL as Java. Switching from the Elastic COBOL Perspective view in Eclipse to the Java Perspective allows one to see how Elastic COBOL transpiled it into a new language. Based on settings the conversion can be verbose (with original COBOL code and comments) or terse (just new COBOL). Other Elastic COBOL project settings can optimize OCCURS DEPENDING ON arrays to reduce time and space, or carry out a faithful translation of a COBOL array to a Java array. Code changes to the generated Java can be carried out by people more familiar with the Java language or whole modules (sub programs)
By comparing these perspectives, the Java programmer will see how Elastic COBOL leverages the Java class structure to provide the exact same (100% compatible) functionality in Java of any of 15 different COBOL dialects. COBOL COMP-3 elements become instances of the PackedDecimal class. COBOL Main or sub programs simply are embodied as entire Java classes of the same name. Arrays are arrays, paragraphs are methods, etc. The parallels are remarkably similar and the Java object-oriented principles are leveraged to provide compatibility. Java and COBOL developers and maintainers can sit in the same meetings discussing algorithms and best practices for advancing the organization's core application assets without the need to bring up programming language syntax.
Elastic COBOL will generate full cross-reference and listing files if you request, some of which are in XML allowing external tools to analyze your business rules. View these logs in Eclipse or store them off-line.
Although you may already have tools to help you in this area, this is probably the most interesting area, and the one where productivity could increase substantially. You can choose to debug locally or attach to Heirloom Elastic Transaction Platform (CICS) or Elastic Batch Platform (JES/JCL) server environments and debug transactions or job steps remotely. The same step-by-step debug, display and variable dump facilities are available as you set breakpoints, continue executing between points, stop when modules are available in local and remote. You can change data content, recover from data exceptions and more. Hover the cursor over a group variable to see what the record will look like if it has just been read or is about to be written or rewritten. Hover over an element to see the data item in its numeric and hexidecimal format. Use the Call Stack View as you would in Java to see how which programs called what sub programs and with with arguments. You can unit test an individual subprogram with the Elastic COBOL IDE. Every subprogram is also a main program and can be invoked with an Eclipse Debug Configuration that test it. Tracing is available on the program or paragraph basis so your program will write a detailed trace as its executing.
Plus, it is extremely easy to use. There are no parallels to this extensive debugging within ISPF on the mainframe or in similar mainframe offload products because Heirloom Computing is able to leverage the thousands of person-hours that have been put into making the Java development experience extremely productive for that community.
During QA or pre-production
Remote debugging of job steps within EBP or transactions within ETP offers an extremely important productivity improvement tool vs. analyzing dumps and logs on the mainframe application development. Although the extent to which these facilities are used in your organization are totally under your control, imaging being able to remotely attach to a QA or pre-production CICS region or JES subsystem and being alerted if the application steps into an unwanted error or recovery module. Even breaking and waiting for the attention of a developer to look around at variables, logs, files before deciding to proceed or, perhaps, to elect to invoke another recovery module (paragraph, program or subprogram) before continuing.
“End to end” debug
Remember that Elastic COBOL IDE is an extension of Eclipse and so a developer would be able to use this same tool to develop and
debug composite applications. For example, if you have an application that is written with HTML/JSP/Java that connects to COBOL/CICS through Java connectors, you could perform what we called an “end to end” debug: the same debug perspective will show all the different
language types, and you could make breakpoints in any of those languages.
Heirloom Computing Elastic Batch Platform and cloud-based scheduler are completely controlled through RESTful Web services. You can start up your own copy of EBP, the JES system and JCL interpreter, running under the Apache Tomcat Java container server from within your workstation's Eclipse session. You can trigger those services from scripts or from within Eclipse to define job classes, start intiators, or submit jobs to the internal reader. When the applications they invoke "hit" a breakpoint your workstation automatically switches to the Debug Perspective where program execution details can be examined.
Heirloom Computing Elastic Transaction Platform similarly runs under the auspices of a JEE server such as Apache Geronimo (IBM Websphere Community Edition), JBOSS, Oracle Weblogic and others. You can start up your personal "CICS Region" from within your Eclipse workstation environment. And, ETP ensures that all your CICS transactions can be invoked as RESTful Web Services as easily as other regions can Distributed Program Link (DPL) to your personal region. This makes testing of composite applications that use modern AJAX or JSP front ends to invoke CICS transactions under ETP.
Its hard to put a number on productivity improvement when using Elastic COBOL Interactive Developer Environment under Eclipse compared with writing and maintaining similar applications on a mainframe. But, conservatively, a 50% improvement can be seen from the editor, source code control paradigm and debugger alone. Factor in the ability to start/stop Database, JES and CICS subsystems from within the same environment, and productivity could increase 5-fold. Maintenance jobs that took 20 people before can be done with 4 or a single project can be completed in 20% of the time. And the skill-sets of those people can all COBOL, mixed COBOL and Java and people trained only in Java development and maintenance. Elastic COBOL allows all of these subject matter experts to work together.