Layers, objects, and granularity : cobol

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.

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:

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..._equation.html )

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.

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.

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. 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.

Pete.
--
"I used to write COBOL...now I can do anything."



--
"I used to write COBOL...now I can do anything."

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..._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

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:jBwOk.292$Dm5.179@newsfe01.iad...
> Pete Dashwood wrote:
<snip>>
> So COBOL-wise you are promoting small methods, correct ?
>

As I rarely write COBOL these days, I'm not "promoting" anything COBOL
related.

I do believe that objects and their behaviours in ANY language should be
small wherever possible.

> >>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 ? :-

You are wrong on two counts:

1. The sentence above has the qualifier MOST at the start of it. It doesn't
say this is ALWAYS the case. There are exceptions (this is one of them
because this Method is generalised code and has to deal with a number of
different possibilities. Originally each of the sections was a separate
method but, using the primitive SQL available in COBOL, I could find no way
to share a cursor across different methods, so it had to be handled in ONE
method. However, each of the functions within that method is in a section
and the sections are small.

2. I never signed a contract with Arranga, Coyle or you that said I would
abide by what you consider to be good practice.

I said I agreed with the principle and GENERALLY applied it, having come to
the same conclusion many years ago.

But most importantly, why would I apply your black and white judgements to
something that requires subtlety and consideration?

The code requires more than one section so it got more than one section. Get
over it.

> > 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 ?.

Does it matter?

As there is a WS section coded and it has entries in it, and given that the
code works, I should have thought the answer to your question is axiomatic.



>
> > 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 ?

As I stopped printing program code some years ago, I have no idea.

Each of the sections is small and I already explained why the Method NEEDS
to accommodate all the possible actions.

The code works. What's your problem exactly?

I do note in passing that you made no comment on what the code was
demonstrating, so obviously your priority is to try and make an issue about
something that is not an issue.

>>
>> 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'.

Oh, I can't wait. Be still my beating heart...

> Hopefully I've included sufficient comment in the code to guide the
> uninitiated readers, just a little.

I have no intention of "shooting" at anybody. It strikes me as sad that you
see the need to.
<snipped>

Pete.
--
"I used to write COBOL...now I can do anything."