Prev: Need to know of a good cobol compilier that runs in the Windows 64 OS
Next: very OT: Joy of music WAS: Re: cannot build opencobol-1.1 under cygwin
From: Pete Dashwood on 27 Apr 2010 08:21
Howard Brazee wrote:
> On Fri, 23 Apr 2010 11:09:39 +1200, "Pete Dashwood"
> <dashwood(a)removethis.enternet.co.nz> wrote:
>
>> I have a feeling that a new generation of RDBMS is "around the
>> corner" and they will be driven by LINQ or LINQ-like syntax. (It is
>> more "generic" than SQL and definitely more logical, in my opinion.
>> LINQ also supports functional programming so that whole sub-queries
>> can be represented by a symbol.)
>>
>> The "interesting" thing about this is how any SQL replacement will
>> address the enormous investment currently made in SQL systems.
>>
>> In the meantime, introducing data access layers to systems and
>> keeping embedded SQL out of new application code would seem to be a
>> prudent move.
>
> Still, the will be lots of SQL embedded into systems next to the
> CoBOL. With all the interactivity in new systems, replacing is much
> more difficult than it has been in the past.

Only through ignorance, not by necessity.

COBOL systems can call a data access layer just like anything else. Embedded
SQL doesn't HAVE to be embedded in business processing.

I contend that it SHOULDN'T be. The advantages in separating it are HUGE.

Business code gets and processes thedata it needs INDEPENDENTLY of how and
where this data is stored. Everything is accessed through buffers in memory
and the mechanics of storage and retrieval are nothing to do with the
business process. This simplifies both the Data Access Layer and the
Business Process Layer.

You could swap out the entire RDBMS system for example, without any impact
on the Business logic. It continues to see what it has always seen: a buffer
in memory.

By the same token, the physical data retrieval and storage can be tuned and
optimized in the certain knowledge that this process cannot possibly affect
the applications.

Personally, I like the Business Layer to interact with the data access layer
by means of objects (and I have tools that generate these DAL objects
automatically, analysing the DB schema and the COBOL record layout and
producing code that automatically constructs and deconstructs the COBOL view
to and from the RDB), mainly so that code written in ANY language can enjoy
the same data access facilities as the COBOL does. But even in a
non-Object-Oriented shop, separate "access modules" can be cloned from a
common template, or a "general purpose" module can be invoked with dynamic
parameters which allow it to access specified table/data sets.

All interaction with data is via a buffer in memory. (Mostly it is a COBOL
01 record layout in working-storage which gets passed to the Data Access
Layer.). It is just as easy to invoke a method of a Data Access Layer object
which returns the COBOL record (for instance). as it is to embed SQL in your
program to load host variables with the same data and then repeat that in
every program that needs that data. With the object, it is only ever ONE set
of code. You instantiate it and use it when you need to. (You could also
just CALL a module with the same processing capability.) Either of these
approaches is far superior to writing specific SQL code into a business
process.

It ISN'T technically difficult. (the first time I ever did this was with a
VSAM based system back in the late 1970s. All access to the indexed files
was by means of templated modules which all had the same capabilities, but
were tailored to support a specific indexed file, and "knew" about the
records on it.Application programs simply passed a buffer address and
requested an action. Data, status, and control information were all
returned. Things like file open and closes, corrupted indexes and recovery,
exception handling at disaster level were all handled by the access layer.
Applications either received data, or got an explanation as to why they
hadn't, or the process was closed gracefully if it could not continue in any
meaningful way.

These days, with the support of a modern RDBMS which may return around 400
possible SQLSTATEs, the possibilities are much more sophisticated, but the
principles remain the same.

Proliferating embedded SQL nto Business processes is just irresponsible,
when there is absolutely no need to.

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


From: Howard Brazee on 27 Apr 2010 09:43
On Wed, 28 Apr 2010 00:21:26 +1200, "Pete Dashwood"
<dashwood(a)removethis.enternet.co.nz> wrote:

>> Still, the will be lots of SQL embedded into systems next to the
>> CoBOL. With all the interactivity in new systems, replacing is much
>> more difficult than it has been in the past.
>
>Only through ignorance, not by necessity.

I'm not sure it's only through ignorance, although I agree that it's
not by necessity. Many (most?) shops and even software companies
don't want to touch stuff that is "working". They make a conscious
decision that it's cheaper (at least in the short term), to leave it
alone, and set up policies that follow this decision.

>COBOL systems can call a data access layer just like anything else. Embedded
>SQL doesn't HAVE to be embedded in business processing.
>
>I contend that it SHOULDN'T be. The advantages in separating it are HUGE.
>
>Business code gets and processes thedata it needs INDEPENDENTLY of how and
>where this data is stored. Everything is accessed through buffers in memory
>and the mechanics of storage and retrieval are nothing to do with the
>business process. This simplifies both the Data Access Layer and the
>Business Process Layer.

I see an advantage of putting more and more of the business rules into
the database - especially in the data warehouse. When users create
reports from the warehouse, we want the business rules automatically
included.

--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."

- James Madison
From: Pete Dashwood on 28 Apr 2010 04:52
Howard Brazee wrote:
> On Wed, 28 Apr 2010 00:21:26 +1200, "Pete Dashwood"
> <dashwood(a)removethis.enternet.co.nz> wrote:
>
>>> Still, the will be lots of SQL embedded into systems next to the
>>> CoBOL. With all the interactivity in new systems, replacing is
>>> much more difficult than it has been in the past.
>>
>> Only through ignorance, not by necessity.
>
> I'm not sure it's only through ignorance, although I agree that it's
> not by necessity. Many (most?) shops and even software companies
> don't want to touch stuff that is "working". They make a conscious
> decision that it's cheaper (at least in the short term), to leave it
> alone, and set up policies that follow this decision.
>
>> COBOL systems can call a data access layer just like anything else.
>> Embedded SQL doesn't HAVE to be embedded in business processing.
>>
>> I contend that it SHOULDN'T be. The advantages in separating it are
>> HUGE.
>>
>> Business code gets and processes thedata it needs INDEPENDENTLY of
>> how and where this data is stored. Everything is accessed through
>> buffers in memory and the mechanics of storage and retrieval are
>> nothing to do with the business process. This simplifies both the
>> Data Access Layer and the Business Process Layer.
>
> I see an advantage of putting more and more of the business rules into
> the database - especially in the data warehouse. When users create
> reports from the warehouse, we want the business rules automatically
> included.

Yes, there is definitely a place for this. A "smart" DB is like an extension
of the data access layer.

I managed a site in the UK where ALL business logic was in stored
procedures, held on the database. For the most part, it worked very well.

But they had very skilled SQL programmers who didn't do application
programming as such.

I was impressed at how quickly they could implement new rules and they used
tools that generated SQL as well. However, it was quite a problem when
things DIDN'T work as they should, or unexpected cases were encountered,
because debugging the code had impacts on data, and changes to data could
impact existing code.

I hadn't seen it before so I had an open mind about it, but I left persuaded
that separation is still the best approach.

They were in the process of replacing all of these applications with a
Siebel package. A huge investment over a couple of years.

Pete.

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


 | 
Pages: 1
Prev: Need to know of a good cobol compilier that runs in the Windows 64 OS
Next: very OT: Joy of music WAS: Re: cannot build opencobol-1.1 under cygwin