Can COBOL keepUp its reputation cleverly?...

Hello everyOne,

I was curios about this topic for quite someTime and thought I
would toss it out for an open debate.

When designing and developing new complex large commercial business
applications, what is the preferred charting scheme as part of the
program and system documentation?. I know in the IT world its
always horses for courses and depending on where you are working,
however, maintenance, modification and enhancements are always
a major part of any large business application in the long run.

There are some methods that seem to be favored and work very well
for describing different sections of a program or a system, which
I can list three of them here -- perhaps there is a better approach
that you would like to pointOut, which makes maintainability a much
easier task:

1). Data Flow Diagram: to show the flow of data thru the complete
system and its subSystem modules.

2). Decision Table: to show listing of the actions required for
numerous if..else..and case evaluate conditions.

3). Data Structure Diagram: to show system data and relationship
between the data entities within the file system or dataBase.

Regards, Kellie.

I don't want CoBOL to keep its current reputation.

In article <1118077577.759503.124850@g49g2000cwa.googlegroups.com>,
Kellie Fitton <KELLIEFITTON@YAHOO.COM> wrote:

[snip]

>
>When designing and developing new complex large commercial business
>applications, what is the preferred charting scheme as part of the
>program and system documentation?.

The one which causes the person who signs the checks to smile.

DD

Hi Howard,

why not?  if mighty COBOL managed to keepUp its reputation and survived
for the
past 45 years, it must be doing some thing pretty good, don't you
think?
so many languages have came and gone and were rendered history in a
short time.
even if some of these languages still here today --- I don't think they
can compete
with mighty COBOL when it comes to the realWorld business applications.

Regards, Kellie.

Hi DocDw,

Mighty COBOL is the one who signs checks almost everyWhere, and makes
lots
of folks pretty happy. Most professional organizations today have an
embossing
machine stamp, that allows the software to control and print the
signature on the
payRoll checks. So, the question is: How to make mighty COBOL smile?

Regards, Kellie. :---)

On  6-Jun-2005, "Kellie Fitton" <KELLIEFITTON@YAHOO.COM> wrote:

> Hi Howard,
>
> why not?  if mighty COBOL managed to keepUp its reputation and survived
> for the
> past 45 years, it must be doing some thing pretty good, don't you
> think?
> so many languages have came and gone and were rendered history in a
> short time.
> even if some of these languages still here today --- I don't think they
> can compete
> with mighty COBOL when it comes to the realWorld business applications.

I don't think it has the same reputation it used to have.   I think it deser
ves
a significantly better reputation than it has.

In article <1118081853.125562.256590@g43g2000cwa.googlegroups.com>,
Kellie Fitton <KELLIEFITTON@YAHOO.COM> wrote:
>Hi DocDw,
>
>Mighty COBOL is the one who signs checks almost everyWhere, and makes
>lots
>of folks pretty happy. Most professional organizations today have an
>embossing
>machine stamp, that allows the software to control and print the
>signature on the
>payRoll checks. So, the question is: How to make mighty COBOL smile?

That depends on the platform and the compiler, usually.

DD

On 06/06/2005 1:06 PM, Kellie Fitton wrote:

> When designing and developing new complex large commercial business
> applications, what is the preferred charting scheme as part of the
> program and system documentation?. I know in the IT world its
> always horses for courses and depending on where you are working,
> however, maintenance, modification and enhancements are always
> a major part of any large business application in the long run.
>
[...]
> 1). Data Flow Diagram: to show the flow of data thru the complete
>     system and its subSystem modules.
>
> 2). Decision Table: to show listing of the actions required for
>     numerous if..else..and case evaluate conditions.
>
> 3). Data Structure Diagram: to show system data and relationship
>     between the data entities within the file system or dataBase.
>

I've learned the hard way that when designing UI components, it's always
good to prototype first.  Show the prototypes to the intended audience
and see what comes of that.  This doesn't mean to do what this
hypothetical audience wants, but it can be enlightening to see exactly
what they did or did not like.

Another thing to consider is that different people might need different
things from your charting.  Providing just the amount of information
people need within the appropriate context for the work that they do is
pretty important.

How hard is it to prototype for the environment you are in?   I'm
guessing or assuming that you could hack something together in ReXX.  Or
even COBOL, but I recommend you throw away your prototype once you
decide on your approach.

That's my $1.19.  Inflation, you know.

Kellie Fitton wrote:
> 1). Data Flow Diagram: to show the flow of data thru the complete
>     system and its subSystem modules.

This can be good.

> 2). Decision Table: to show listing of the actions required for
>     numerous if..else..and case evaluate conditions.

For a "large, complex system", this would quickly become so large as to
be unmanageable.

> 3). Data Structure Diagram: to show system data and relationship
>     between the data entities within the file system or dataBase.

You'll definitely want that - the more information your maintainers can
derive from your documentation, the smaller the chance that they'll mess
things up.

You've concentrated on data diagrams, and they're good, and have their
place.  However, another technique that can help users, original
developers, and maintainers understand how the system is used.  That
way, they can better understand what their little piece does within the
larger scope of the system.  They can be time-consuming to produce, but
there is a payoff - and, if you're using RAD / eXtreme Programming, you
can develop the system to fulfill the first few use cases as you're
determining future ones.

So, you've got your data diagrams, but these use cases, while not
necessarily graphical in nature, can help give the bigger picture of
what transformations of data occur under what conditions.

--
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~   /   \  /         ~        Live from Montgomery, AL!       ~
~  /     \/       o  ~                                        ~
~ /      /\   -   |  ~          daniel@thebelowdomain         ~
~ _____ /  \      |  ~      http://www.djs-consulting.com     ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e    ~
~ h---- r+++ z++++                                            ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~