From: Clark Morris on
The following posting on bit.listserv.ibm-main (listserv
ibm-main(a)bama.ua.edu) is an interesting discussion on COBOL, business
practices and includes a reference to a Register article on SQL.

On 21 Apr 2010 07:41:41 -0700, lynn(a)GARLIC.COM (Anne & Lynn Wheeler)
wrote:

>Howard Brazee <howard.brazee(a)cusys.edu> writes:
>> The perception is that mainframe CoBOL shops are dying out. New
>> companies increasingly don't believe that in-house training is
>> worthwhile (why train for your employee to go to a competitor?). The
>> perception is that it's easier and cheaper to buy a package and adjust
>> one's business practices to the package so that no modifications are
>> needed.
>
>some of this view reflects the culture of the executives ... they are
>brought in to plunder the company and then they move on to plunder the
>next company.
>
>in the past decade, SOX was passed to strengthen countermeasures to the
>plundering tactics. However, it appeared because SEC wasn't doing
>anything ... the GAO started database of financial filings by public
>companies that it believed were fraudulent ... showing a significant
>increase in fraudulent financial filings in period since SOX was
>passed. a scenario was that the fraudulent financial filings boosted
>executive bonuses ... and even if the filings were later corrected, the
>executives didn't forfeit the bonus. I made joke about how to spin with
>respect to SOX:
>
>1) sox audits had no effect on fraud
>2) public companies were motivated to increase fraudulent financial
>filings under sox
>3) if it hadn't been for sox, every public company would start making
>fraudulent financial filings.
>
>in the madoff congressional hearings, there was testimony by somebody
>that had tried for a decade to get SEC to do something about Madoff (and
>nothing happened). They also had a separate tidbit related to SOX
>... informers turn up 13 times more fraud than audits; also SEC didn't
>have a tips hotline ... but had a 1-800 for companies to complain about
>audits.
>
>slightly related recent post
>http://www.garlic.com/~lynn/2010h.html#35 First among SQLs; COBOL for lawyers
>
>regarding this recent article
>
>First among SQLs; COBOL for lawyers
>http://www.theregister.co.uk/2010/04/20/verity_stob_sql/
From: Pete Dashwood on
Clark Morris wrote:
> The following posting on bit.listserv.ibm-main (listserv
> ibm-main(a)bama.ua.edu) is an interesting discussion on COBOL, business
> practices and includes a reference to a Register article on SQL.
>
> On 21 Apr 2010 07:41:41 -0700, lynn(a)GARLIC.COM (Anne & Lynn Wheeler)
> wrote:
>
>> Howard Brazee <howard.brazee(a)cusys.edu> writes:
>>> The perception is that mainframe CoBOL shops are dying out. New
>>> companies increasingly don't believe that in-house training is
>>> worthwhile (why train for your employee to go to a competitor?).
>>> The perception is that it's easier and cheaper to buy a package and
>>> adjust one's business practices to the package so that no
>>> modifications are needed.
>>
>> some of this view reflects the culture of the executives ... they are
>> brought in to plunder the company and then they move on to plunder
>> the
>> next company.
>>
>> in the past decade, SOX was passed to strengthen countermeasures to
>> the plundering tactics. However, it appeared because SEC wasn't doing
>> anything ... the GAO started database of financial filings by public
>> companies that it believed were fraudulent ... showing a significant
>> increase in fraudulent financial filings in period since SOX was
>> passed. a scenario was that the fraudulent financial filings boosted
>> executive bonuses ... and even if the filings were later corrected,
>> the executives didn't forfeit the bonus. I made joke about how to
>> spin with respect to SOX:
>>
>> 1) sox audits had no effect on fraud
>> 2) public companies were motivated to increase fraudulent financial
>> filings under sox
>> 3) if it hadn't been for sox, every public company would start making
>> fraudulent financial filings.
>>
>> in the madoff congressional hearings, there was testimony by somebody
>> that had tried for a decade to get SEC to do something about Madoff
>> (and nothing happened). They also had a separate tidbit related to
>> SOX ... informers turn up 13 times more fraud than audits; also SEC
>> didn't
>> have a tips hotline ... but had a 1-800 for companies to complain
>> about audits.
>>
>> slightly related recent post
>> http://www.garlic.com/~lynn/2010h.html#35 First among SQLs; COBOL
>> for lawyers
>>
>> regarding this recent article
>>
>> First among SQLs; COBOL for lawyers
>> http://www.theregister.co.uk/2010/04/20/verity_stob_sql/

I read and thoroughly enjoyed this very well written piece of observation.
Thanks for posting it, Clark.

Although SQL is imperfect, it is pretty much all we have at the moment. I am
slowly moving to LINQ in my own work but many people don't have that
option., and, as noted elsewhere, LINQ has to generate SQL anyway at the
moment.

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.

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


From: Howard Brazee on
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.

--
"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