Cobol - Re: OO and IBM z series COBOL was Re: Discussions of COBOLphilospphy

Author

Re: OO and IBM z series COBOL was Re: Discussions of COBOLphilospphy

Robert

2007-10-12, 9:55 pm

On Fri, 12 Oct 2007 23:35:43 +1300, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:

>
>
>"Robert" <no@e.mail> wrote in message
> news:7uotg3hr7ilbu09726uatk94hm924n8d65@
4ax.com...
>
>Possibly... I've seen very few live databases with more than a few tables,
>that were ever normalized; often redundancy is built back into them because
>some DBA thinks it is a good idea :-)

I've seen fully normalized tables at the most profitable company in the US (ESRX). SQL
statements routinely joined 10-15 tables, and subselects were five layers deep.
Surprisingly, despite 500 line SQL statements, batch jobs ran FASTER than equivalent
legacy code. The reason was simple: parallel processing. Cobol programs run on a single
CPU (with the rare exception of those that spawn threads, as I demonstrated here); SQL
runs on many CPUs.

>Even if we had a perfect database, there is still a case for making it
>smart. There are functions (particularly with Dates) that are much better
>suited to "back end" processing than doing them in application code.

How many languages do not have a date type? Well, there's Cobol. VB has it; Java and C++
have it .. I can't think of any others that don't. Should we design systems around
language inadequacies?

Cobol can use SQL's date functions like so:

SELECT (TO_DATE(:TO) - TO_DATE(:FROM)) INTO :DATE-DIFFERENCE FROM DUAL

Robert

2007-10-16, 9:55 pm

On Tue, 16 Oct 2007 09:43:55 -0600, Howard Brazee <howard@brazee.net> wrote:

>On Sun, 14 Oct 2007 10:56:49 -0500, Robert <no@e.mail> wrote:
>
>
>Does this include Unix PCs?
>
>
>
>My wife has Parallels running on her Mac, which runs a Windows VM.
>Another company has come out with one that I've read grabs a processor
>and thus runs Windows faster - as a single-processor system.
>
>I wonder what other VMs in mainframes and elsewhere do this.

Cache coherency is a hardware issue having nothing to do with VMs.
Hardwae regards all software as a single 'user'.

There are two techniques for maintaining coherency: directory and snooping/snarfing.The
latter is faster but isn't scalable. The writer was referring to the directory technique,
which could be likened to a single-threaded lock table that knows what's in each CPU's
cache(s). A memory write by one CPU has to invalidate or update the word in other CPUs'
caches before the write to main memory can be allowed. That's what causes the slowdown.

There's no need for this if CPUs share a single cache. Intel dual cores have a single L2
cache; AMD dual cores do not. On both brands, each CPU has its own L1 cache.

Sponsored Links