Re: Layers, objects, and granularity

Pete Dashwood wrote:
I've been talking a fair bit lately about the things in the topic above.

This post is intended to provide some conceptual background as to why I think they are important.

After nearly 10 years now, working with classes and objects in COBOL and other languages, I can "distill" the experience into what follows...

LAYERS ("Tiers before bedtime...?"):

The idea of separating code into layers is fairly anathema to traditional COBOL.

No it isn't. Long, long ago on the M/F Compuserve Forum you made reference to Three-Tier Systems which is much more meaningful than your current fancy word 'Layers'. The phrase 'Three Tier Systems' said it immediately for me :-

1 - Business Control/Business Logic or the ugly academic 'Problem Domain'

2. User Interface - COBOL Screens, GUI Dialogs, Web Pages. I suppose you could include printed reports ?

3 - Database Interface - COBOL files or (R)DBMS

You shouldn't really need to expand on that as you do below.


You get input, you process the input, you write the output. Where's the problem?

Separating these functions just introduces overhead.

While that may have been true in the early days of COBOL, anyone who worked on an IBM mainframe site will recall the impact that something like a new release of the Operating System, data access software, or screen handling caused. Review of all the code. Many man-days of lost programmer productivity.

Transporting code to a different platform didn't happen that often, but when it did, it was a nightmare. Many of the promised "platform independent" features of COBOL failed to materialise because the screens or data storage were proprietary.

Gradually we learned to "isolate" the actual functionality (Business rules) from the input and output and replace them with an interface. CICS and IMS/DC were both good examples of this: CICS used Basic Mapping Support (BMS) to interface to a display screen, IMS/DC used Message Input Description (MID), Message Output Description (MOD),Device Input Format (DIF) and Device Output Format (DOF) buffers and commands to separate the presentation functionality from the Business logic. The Business logic saw only a buffer and was able to request attention identifiers (PFKs and ENTER) and change screen attributes, if required. Other platforms used similar interfaces to their presentation software.

By the time Client/Server processing arrived, these early intimations had evolved into the "Three tier model". Three separate layers of design, connected by interfaces. Presentation layer, Business layer, and Data access layer. Instead of some business logic incorporating a READ or using ESQL directly, it could request data through the interface (with PERFORM or CALL). It simply used a buffer (or Global Working-Storage in COBOL's case...) to process data and placed the results in another part of the same interface.

Despite the "layer" imposing an overhead (compared to direct READ or FETCH) it did mean that changes to Business logic had less impact overall. Much duplication was eliminated. Furthermore, completely separate changes to the actual Data Access layer (like an upgrade of the software, some physical tuning, adding new stored procedures, or new tables on a database...) had no impact on the existing Business logic.

By insulating Business logic from its presentation and data requirements, there is much less trauma when change in one of these layers occurs.

OBJECTS:

Leaving aside the debate about OO programming versus Procedural programming, why are objects important?

Some of the reason is touched on below in GRANULARITY, but the simple answer is: Because they are small and independent.

If you can isolate a piece of Business logic and encapsulate it into something that has its own defined attributes and behaviours, that communicates with the rest of the world by a clearly defined interface, is predictable and does exactly what it is specified to do, is not dependent on or subject to variance in the rest of the environment, then you have something of great value. Properly written classes (an "object" is an instance of a class) can achieve this. If you can then place this class into widely varying technical environments (like the desktop or the Web or your cell phone or PDA) then you have a "component". Why are components important? Because you can build things with them... :-)

GRANULARITY:

So second thoughts on your recent use of the word 'Granularity', and accompanying snotty response. Your thoughts led to you now spelling it out a bit ?

Granularity concerns the size of a unit used for construction.

One of the major problems which has beset COBOL right throughout its life has been the cost of maintenance. Changing source code is labour intensive and expensive.

Fairly early on in the piece (late '60s, early '70s) COBOL shops began to realise that, while running a mainframe wasn't cheap, the major part of their budgets was spent on programming for development and maintenance, and maintenance cost MUCH more than development.

The problem comes down to granularity.

If the average size of a source program is 5000 lines (or even half that...) and you need to change 10 lines, you don't have to be a statistician to see that there are risks involved.

In effect. the fewer lines of code there are in the unit you are tinkering with, the lower is the risk of getting it wrong, or perhaps even worse, upsetting something else completely unrelated to what you are fixing. When all data is Global (as it is in Working-Storage) and different logical processes are sharing it, it would be surprising if everything went off without a hitch. The more times you have to touch the code, the greater the risk...

(I am reminded of the Drake Equation for determining the likelihood of other life like us in the Universe... :-):
http://www.activemind.com/Mysterious/Topics/SETI/drake_equation.html )

Your Mr. Drake did nothing for me - but there again you are turned on by looking skywards at the stars. Although man got there, I still remember my childhood wonderment looking up at the moon and seeing a smiling face :-)

Maybe some here of a more mathematical bent than me could produce a similar formula, outlining the risk in maintaining COBOL and incorporating the factors mentioned above...plus any others you may think of... :-)

Even without the lines of code, there are all the other factors like continual business requirement for change, poor programming style, lack of knowledge of the application, pressure of deadlines, corporate culture, motivation, and so on which can play a part in more maintenance being required.

On the other hand, if your application is built from small classes, each comprised of, at most, a few hundred lines of code (I'm talking COBOL here; typically, C# code is MUCH smaller (because it is tighter and more powerful) than what COBOL requires to do the same job...) , with each component having a clearly defined interface and behaviour(s), then you are starting to minimise the risk of messing with it. In a worst case scenario, you could drop or rewrite an offending object; it is much more serious when the units are many times larger.

So COBOL-wise you are promoting small methods, correct ?

>>Did you for some $12 get a second-hand copy
>>of Arranga/Coyle from amazon - most of their methods are no more than a
>>few lines of code.
>
>
> Most of mine are not either. In C#, Java or COBOL. (And even in the
> occasional VBScript or JavaScript).

Am I wrong, or am I wrong ? :-

> IDENTIFICATION DIVISION.
> METHOD-ID. HandleDB AS "HandleDB".
> ENVIRONMENT DIVISION.
> DATA DIVISION.
> WORKING-STORAGE SECTION.

*** Nearly missed that - can you use W/S in Methods with Fujitsu ?.
Ironically it was their rep on J4, Thane, who kiboshed W/S from methods
- meanwhile the gentleman from Las Vegas representing M/F, just twiddled
his thumbs. You ALWAYS could use W/S within methods with M/F. Still it's not part of the Standard so far as I know. Still again, What's the COBOL Standard relating to OO :-)

> 01 saved-SQLSTATE pic x(5).
> 01 saved-SQLMSG pic x(512).
> LINKAGE SECTION.
> 01 DBaction pic x(8).
> PROCEDURE DIVISION using DBAction.
> MAIN SECTION.
> P001.
> if DBaction NOT = 'init'
> move MOST-instance-stamp to HV-DB
> EXEC SQL
> SET CONNECTION :HV-DB *> ensure we are using the right
> connection...
> END-EXEC
> move SQLSTATE to MOST-SQLSTATE
> MOVE SQLMSG to MOST-SQLMSG
> if SQLSTATE NOT = '00000'
> go to p001-end
> end-if
> end-if
>
> evaluate DBaction
> when 'init '
> perform SQLInit
> when 'start '
> perform SQLStart etc...
> .....................
> when 'delete '
> perform SQLDelete
> when other
> move '99999' to SQLSTATE
> move 'Invalid action passed to HandleDB...' to SQLMsg
> end-evaluate
> if SQLSTATE = '00000'
> move space to DBaction
> end-if
> .
> p001-end.
> exit method.
> *---------------------------------------------------
> SQLInit section.
> si001.
> *
> * Get a DB connection...
> *
> * CONNECT TO DATABASE ON %DBDSN% SERVER
> move MOST-instance-stamp to HV-DB *> uniquely identify
connection for
> this stream
> EXEC SQL
> * DSN, User and password must be set in the ODBC info file
> * which is external to the MOST handler.
> CONNECT TO 'TestDB' AS :HV-DB
> END-EXEC
> * CHECK CONNECTION RESULT
> IF SQLSTATE = "00000"
> move "Connection to %DBDSN% server through ODBC OK..."
> to SQLMsg
> Log-Message
> else
> move SQLMsg to Log-message
> END-IF
> move SQLSTATE to MOST-SQLSTATE
> MOVE SQLMSG to MOST-SQLMSG
> invoke SELF "LogIt"
> end-invoke
> .
> si999.
> exit.
> *---------------------------------------------------
> SQLStart section.
> ss001.
>
> ...and so on...
>
> You can see the factory instance stamp provides a unique DB connection
> identifier.

That sure looks like a *B-I-G* Method to me - you've shown TWO Sections in the same method and presumably there are more to follow, flowing from your Evaluates - just how many pages of paper will this 'small' method need to print ?

Given that objects in a class can inherit from each other, extending functionality is pretty simple. You can add a new behaviour to the class, secure in the knowledge that what went before will not be affected (none, part, or all of the previous behaviours can be inherited or changed (overridden) by the new one, without any impact on anything using the existing behaviours.) Any process using an object sees only what the object wants it to see. You can decide how much of it is "visible" when you write the class.

Bottom Line: By keeping granularity small, the risks for maintenance are minimised.

Summing up:

Over the years we've had fierce debates here about the merits of OO as opposed to Procedural programming. While a few of us were persuaded that OO was important, there wasn't a background of experience with classes and objects across different environments to be able to grasp the essence of it and explain it succinctly. People here are now are starting to realise that the future belongs to objects. Why this is so, I have tried to lay out above.

And it will continue to be debated. Many of course are just sweating retirement. One can talk concepts or theory until you are blue in the face. You'll get your chance to shoot back - wait for 'Last Hurrah - OO Factory'. Hopefully I've included sufficient comment in the code to guide the uninitiated readers, just a little.

There is nothing wrong with COBOL (Procedural or OO). The problem is in the changing needs of the world, and the costs of meeting those needs. When there was no other option, what we did made sense. Now, there are other options and COBOL doesn't really compete.

Michael posted and showed that at least MF OO COBOL is a pretty impressive implementation.

Not doing an M/F plug, but price aside, I have always considered it a superb product - and I'm just talking about using N/E 3.1, whereas Michael W. is updating you as of N/E V 5.1 for dotNet.

But it is an interim solution that can extend existing application life, not carry those applications far into the future. (Actually, it technically CAN carry them far inot the future for as long as there is support available, but, in practice, it won't, because, as programmers become more familiar and comfortable with OO programming. they realise it is better implemented in other languages. It's not like you CAN'T do something, it is more like it is tedious to do it compared to a different language. As programmer productivity has a major bearing on the budget bottom line for most IT departments, it isn't too long before COBOL dies of attrition.
(Of course there are other factors which are leading to the removal of IT departments for development altogether, but that is beyond the scope of this discussion.)

The future belongs to classes and objects, and that will be the basis for system design, as well as for programming.

Agreed and very likely attainable for quite a while yet using a decent OO COBOL compiler. (And F/J's compiler without decent tech support ? - although back in yonder days you used to extol its virtues, brooking no criticism from ANYONE).

Just remembered - no wonder they wouldn't converse with you about their latest and greatest - did you perchance, like you did in a recent message, use the phrase 'pidgin English' to one of them in the past :-)

Jimmy
.

Relevant Pages

  • Layers, objects, and granularity
    ... working with classes and objects in COBOL and ... from the input and output and replace them with an interface. ... Presentation layer, Business layer, and Data access ... Leaving aside the debate about OO programming versus Procedural programming, ...
    (comp.lang.cobol)
  • Re: Why read CLC?
    ... My number 1 is "Design top-down, ... everything top-down, and to trivialize programming. ... the interface", ... It is an echo from the days when COBOL was the only game in town ...
    (comp.lang.cobol)
  • Re: COBOL to MS Excel
    ... controlling Excel from it. ... this was a COBOL programmer requesting a COBOL solution. ... up Excel to view them - the interface is automatic. ... "nuts and bolts" of programming become buried ever deeper under the covers, ...
    (comp.lang.cobol)
  • Re: Relevance of languages WAS: Re: Date Validation in COBOL
    ... Very good response from both you and Howard. ... COBOL replacing Assembler was one ... programming to the masses was a very bad move and there would have ... because COBOL controls everything and is not designed for responding ...
    (comp.lang.cobol)
  • Cobol and OO programming: the final chapter!
    ... The history of Cobol today is often modeled as an evolution in steps ... reflection of the OO programming influence, ... ideological fight for pimp standards has basically already been fought ... must assume it does give us the fittest ideology for the times. ...
    (comp.lang.cobol)