Re: Is it possible to use the value of the PROGRAM ID within the source code?

From: Robert Wagner (robert.deletethis_at_wagner.net)
Date: 06/24/04 

Date: Wed, 23 Jun 2004 23:51:53 GMT

riplin@Azonic.co.nz (Richard) wrote:
>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>> Wrong. I stopped using GO TO in the '60s.
>
>Until the universal availability of scope terminators there were
>several ways that flow could be controlled around the problem areas
>where a single full stop would terminate all scopes. Some of these
>led to complexity problems of having too many small paragraphs, others
>led to repitition of condition tests.
>
>It is a matter of balancing 'purity' against complexity and
>reliability. You may well have a level of purity that approached
>sainthood (in your own church at least), but for others a more
>pragmatic resolution was required.

I didn't repeat conditions (nor use many indicators), have an
excessive number of small paragraphs nor find it particularly
challenging. I think it's all in structure, how one packages logic
into paragraphs. That's what spaghetti coders don't know how to do.

>> True, but Cobol is plagued with large programs more than other
languages. It
>> seems a feature of 'Cobol culture' as practiced in big shops.
>
>I suspect that you have a rather limited experience. Large Fortran
>programs used also to be found. But this is a matter of 'selection of
>the fittest'. If large programs were a 'plague' then this would have
>been resolved by the programming shops themselves. If they didn't
>work or were too expensive in some way, the business case would have
>removed them.

I see little new development in Cobol, only maintenance. When systems are
replaced, new code is in another language. Businesses _are_ removing
Cobol slowly, by attrition.

>> >What particular OO features do you think that batch programs need ?
>>
>> Reusability.
>
>But 'reusability' is not a unique feature of OO design. That is, it
>is not necessary to have object orientation to have code reusability.

The alternatives are called programs and copy-and-paste. Big shops don't
like called programs because they think a change requires retesting all
callers. They use lots of copy-and-paste, which creates multiple copies of
the same code. When that code needs maintenance, they do it in the program
that 'needs' the change. They wind up with multiple versions of the same
code slightly out of synch with each other. Years later, when someone
unfamilar with the history needs to do maintenance, he has a knot to
unravel.

>> Packaging logic close to the data it operates on.
>
>That is a convenience for the source editing, perhaps better editing
>tools will help you there.
>
>> Packaging ALL logic that operates on a particular datum in one place.
>
>Why is that actually an advantage ?

It goes to Yourdon & Constantine's ideas about Cohesion. The goal of
Structured Design is Functional cohesion. Most batch programs are
organized for Temporal cohesion. The first line performs
Initialization, which opens all files. The very last physical line is
Stop Run. Why? Because that's how we used to design batch jobstreams --
temporal.

When we do maintenance, we're not interested in timeline, we're interested
in a few particular variables. Under what conditions is this thing changed?
Finding hits in numerous programs makes the process unreliable. It's worse
when the variable is called by different names, for example one name in
working-storage and a different name in the database. Or when some code
that changes it is hidden in a stored procedure.

Packaging all logic in one place would make maintenance more reliable.

As with OO Programming, Structured Programming means using Structured
Technology to impliment a Structured Design. Most Cobol programmers
think eliminating GO TO and using EVALUATE, while keeping old-fashioned
design, is good enough to claim they do Structured Programming. They're
packaging old wine in new bottles.

>You seem to want, for example, a simple print report program to carry
>all the baggage of the logic that would be used to update the file.
>Instead of the programmer being able to focus on the _procedure_ being
>performed, you want them to deal with all the other complexities.

My report programs concern themselves with the structure of the report.
They are usually passed the data as an input structure. If not, they obtain
it with a database read or program calls.

>> Ability to define structures more complex than a record or array.
>
>Really ? Do they _need_ this ? Why ?
>
>> Ability to perform operations on those structures more complex than
>> Copy, facilitating abstraction in design.
>
>Really ? Do they _require_ this ? Why. Give examples.

For example, the aforementioned document processor wants to perform
operations at the document level without tediously operating on lines
and words.

A manufacturing program wants to recost or delete finished goods
without traversing the bill of materials tree.

>All that you have done is listed a few features from an OO primer and
>stated these are _required_.

I'm citing real problems from my experience.

>Garbage _may_ be paged out of real memory, except where it resides in
>the same pages or segments that non-garbage resides in. These objects
>are created on the heap and drop out of scope in random ways. Some
>remain and some are now garbage. Because of the granuality of the
>address space being larger than a typical object the garbage may
>reside in real memory. Garbage collection will allow that space to be
>reused.

I didn't tell them to use fixed-length pages. My operating system
used object-sized pages. When I argued for that last year, I was
the village idiot. As a result, I don't want to discuss virtual memory.

>> For instance, I wrote a 'program' (a series of modular
>> programs) that parses freeform text documents, a very common data
>> warehousing problem.
>
>You are attempting to use one extreme example to justify a general
>case. I very much doubt that '500Mbyte' is 'very common'.

Are you kidding? In data warehousing, tables with 500 million ROWS are
common. The two databases I was feeding, one Oracle and the other Sybase, each
had 75 billion rows.

Relevant Pages

  • Re: Code problems with Perform Thru Exit causes fall through
    ... around 90% of the life-cycle cost of most software is in maintenance. ... between design and implementation. ... OOD in COBOL 85. ... adding a paragraph means placing that paragraph within ...
    (comp.lang.cobol)
  • Re: Parameterization of Object Models
    ... Establish maintenance categories - Corrective, Perfective, and Adaptive ... The reference is System Analysis and Design by Michael L. Gibson pp.110. ... Logical errors System analysis and design documentation ... needs of business personnel often change because of changes in the business ...
    (comp.lang.misc)
  • Re: A 6% fix from Microsoft Security Bulletin MS03-040 - 828750
    ... >> the vendor knows of a defect that's being exploited In The Wild, ... That's why I see prudent modular design as being as much in MS's ... complete the job before Windows starts writing to disk. ... ignoring personal data scope; that's what SR tries to do. ...
    (microsoft.public.security)
  • Re: A 6% fix from Microsoft Security Bulletin MS03-040 - 828750
    ... >> the vendor knows of a defect that's being exploited In The Wild, ... That's why I see prudent modular design as being as much in MS's ... complete the job before Windows starts writing to disk. ... ignoring personal data scope; that's what SR tries to do. ...
    (microsoft.public.security.virus)
  • Re: A 6% fix from Microsoft Security Bulletin MS03-040 - 828750
    ... >> the vendor knows of a defect that's being exploited In The Wild, ... That's why I see prudent modular design as being as much in MS's ... complete the job before Windows starts writing to disk. ... ignoring personal data scope; that's what SR tries to do. ...
    (microsoft.public.win2000.security)