Micro Focus Plc makes a very good living out of a programming language that many believed would be long dead by now yet still shows no signs of fading away – but if object-oriented programming fulfils its promise and sweeps away the paraphenalia of the first 35 years of the computer industry, Micro Focus is […]
Micro Focus Plc makes a very good living out of a programming language that many believed would be long dead by now yet still shows no signs of fading away – but if object-oriented programming fulfils its promise and sweeps away the paraphenalia of the first 35 years of the computer industry, Micro Focus is going to have to be ready and waiting if it is not going to be swept away too. And the Newbury, Berkshire company is not unaware of the fact – last September, it slipped out an early release Object Oriented Option for its Cobol Workbench development environment. The first misconception to be got out of the way is that object-oriented Cobol is a new language with a spurious affinity to the ANSI ’85 version. Rather the Cobol community is treating the language as an evolving standard that will embrace the object-oriented paradigm in a controlled, standardised manner.
To this end the Object-Oriented Cobol Task Group was set up by the American National Standards Institution in 1990 and will report back sometime this year with recommendations that will eventually find their way into the next version of ANSI Cobol around 1997. And the language will not be known as Cobol++, COOL or anything other than Cobol. Micro Focus can’t afford to wait until 1997, and is making its marker and sounding out the market now. The Cobol approach to object-oriented programming will mainly be one of incremental re-engineering of venerable applications rather than a rush to write new programs, hence the need to retrofit new Cobol into old code. Micro Focus has been had an object-oriented research programme under way since 1989 to explore what it really means to have re-usable code in practice. It came to the conclusion that in many ways the object-oriented paradigm simply emphasises best practice for existing approaches to coding. However, the object-oriented paradigm offers increasing benefits when followed through from analysis and design to a language – that in fact the whole process becomes much more meaningful when surrounded by a software engineering environment. Micro Focus decided to implement the object-oriented paradigm in a product that will have many of the features of the completed standard and that will become fully ANSI-compliant when the standard emerges. This product is the Micro Focus Object-Oriented Option to Workbench v1.1 which is currently on an early release programme in the US and the UK for the MS-DOS Windows and OS/2 development and run-time environments. But how does the Cobol community move from a static, strongly typed language to the dynamic object-oriented paradigm? Raymond Obin, Micro Focus product development manager has many of the answers. To begin with, the basic unit of programming for object Cobol is the traditional Cobol program that comprises a lump of data and a lump of procedure. The object-oriented paradigm necessitates that programs are cut up into methods that define both the data and the procedure. To do this Micro Focus is building on the ANSI ’85 standard that sub-divides procedures into Nested Programs (where a program is specified within a program and is then used in the context of the larger program). This definition has been modified with the addition of some syntax to turn nested programs into objects. In this way the object-oriented paradigm can be accomodated in a form that continues to look like a Cobol program, combining method, local data and procedure code. Obin is quick to point out that this approach is simply a good starting position for the Cobol community, which can easily accept that an existing program is an object. For while the program is an object there are necessarily multiple small pieces of code within it.
By Katy Ring
This, again, should be no big deal for Cobol programmers, who have already got used to the notion of writing modular code. It is a simple extension of that approach to then use methods to invoke pieces of procedure and function. He concedes that the object-oriented paradigm needs to deal with both large objects (applications) and small objects (d
own to characters or numbers within files), but argues that in the Cobol business context, a fine level of granularity is often not required. For example, he criticises the Smalltalk approach for creating a lot of work for the developer. In his opinion, while the Smalltalk syntax is very simple, its simplicity obscures simple programming tasks. With object-oriented Cobol, as with traditional Cobol, a manager should not need to understand the language to see what is happening. Readability will remain the first principle of Cobol, no matter what paradigm fashion dictates it must embrace. In other words, part of the essence of Cobol clarity is being preserved at the expense of what some would argue is object-oriented programming’s inherent expressiveness at the fine object level. Object-oriented Cobol can be used to write as small an object as you care to write but the price paid for its necesssarily verbose clarity is reduced performance. That being said, if you are in the market for a pure object-oriented programming environment then Object Cobol is not going to be your first choice anyway and nor does Micro Focus expect it to be. Rather the company envisages the use of Object Cobol with object-oriented analysis and design, and an analyst will not go into the detail of strings and numbers, but simply view things like accounts and customers as objects. In the business world, it is felt that this is the degree of flexibility that is required. Obin takes exception to the assertion that Cobol is strongly typed, arguing that you can, for example, add ASCII format to a more optimised format. The ANSI Task Group is attempting to develop a best-of-both-worlds approach with both strong and free typing, and ways to move between the two approaches. To this end it is creating a universal type for Cobol ’97 to enable any message to be sent or any method to be invoked.
However, there are obvious complications: what happens if the source code is universally typed and the target code is not? It seems most likely that the Task Group will go for a more strongly typed Cobol, similar in this respect to C++. Micro Focus, meanwhile, is offering a fully dynamic system that it claims is as polymorphic as Smalltalk in that it supports dynamic look-ups and can implement an untyped system. In the end the company may offer a dynamic subset for prototyping and ANSI-approved static typing for real world applications. To date, the early release programme in the US has found most favour in financial and academic institutions and the re-engineering of existing Cobol applications is the most popular application for the object-oriented option. So far Clarke says the feedback from the trial has led to enhancements in the error handling capabilities of the object-oriented option along with more work on its ability to handle a larger number of objects and a lot of message sends without damaging critical performance features. He is clearly disappointed with the low take-up of the early release programme in the US, but understands that this is because customers already have their hands full coping with downsizing. For those for whom only a pure object-oriented language will do, Micro Focus is also offering a Smalltalk/V-Cobol environment so that Smalltalk can be used as a front end to Cobol programs, offering quick prototyping capabilities. In summary, when Cobol ’97 arrives, existing Cobol ’85 programs will compile with Cobol ’97 products. Users will not be forced to take up object-oriented features if they don’t want to, but they will be able to can add bits of object-oriented programming as they wish, and insulate existing Cobol programs by making an object out of an existing data structure. And yes, Micro Focus says that it will be using Object-Oriented Cobol internally.