Back to our show

> From: furgalj@xxxxxxxxxxxxxxxx
> 
> Precisely what constitutes "business programming," and what would be
> acceptable proof, one way or the other? What is a real OO solution and
> what is a true functional/procedural solution? Where and why is one
more
> appropriate than the other, or is it just a matter of taste or what
you're
> comfortable with?

These are excellent questions, and they are the type of thing I
originally envisioned this list would address.  Where does Java work and
where does RPG work?  Can we design frameworks where we can plug RPG in
for speed and then replace that with pure Java for performance?  Are
there design patterns outside the ones that The Big Four envisioned that
are more amenable to the hard work of business applications?

Paul has already gone a long way toward creating a set of such design
patterns for the file maintenance portion of the business application
spectrum.  But even that statement is loaded; it assumes that you agree
with me that there really *IS* a spectrum of business applications.

So perhaps the first thing we need to hash out is a consensus as to
whether there are indeed definable sets of business application
programs.  I'd be happy to once again put up my three categories and
have the rest of list take potshots at it.

1. Master File Maintenance: These programs maintain master files.  They
include the Work With types of displays as well as the popup selection
windows that other applications use.

2. Executive Information Inquiries: These programs provide
multi-dimensional analysis of complex data relationships in the
database, including sorting, selection, totaling, drilldown, and even
reporting and graphing functions.  Side efforts include the ability to
provide these results in response to a variety of request types
including web services and remote procedure calls, and to output the
results in formats ranging from PDF files to standard spreadsheet
formats.

3. Transaction Processing: These programs act on the business rules of
the company to post external data (orders, inventory transactions, sales
figures) into historical and summary files as required to run the
business.  This includes the standard business applications such as cost
rollups, MRP generations, finite forward scheduling, three-way matching,
currency conversions, order processing and all the other things that
require multiple files and database switches for processing.

> Let's not kill ourselves
> trying to define the whole world of business application programming,
but
> maybe like the TP-C DBMS benchmarks, someone, or a group of us could
come
> up with a set of fairly typical operations and transactions. Design
and
> code these in RPG, COBOL, Java, C++, etc. and discuss them. Like real
> newsgroup/mailing lists used to do in the "olden days" of the '80's &
> '90's. Who knows, this might actually lead to something somewhere,
maybe
> even a class or a book.

Yup, this is exactly what I'd like to see.  A while back I did
benchmarks comparing SQL to native I/O.  While it won't be nearly as cut
and dried to address the more sophisticated programming of a price
lookup, it could still be to our community advantage to at least see if
we can't come up with some common definitions of these functions.

And hell, I KNOW there are one or two folks out there who would LOVE to
see us try this and have it turn out that I was dead wrong <chuckle>.
And if that's truly the case, then I'm perfectly willing to eat some
crow, because it's more important to me that the community be strong
than I be right.

Not that I like being wrong.  <grin>

Joe