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

Pete Dashwood

2007-10-11, 3:55 am

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:470CFF65.6F0F.0085.0@efirstbank.com...
> < GemdnaPKRcdMgpHanZ2dnUVZ_tLinZ2d@comcast
.com>, LX-i<lxi0007@netscape.net>
> wrote:
>
> I don't know. I guess since they support instantiating Java objects from
> within COBOL you could use JDBC.
>
> I don't understand the reasoning behind your second statement, though. It
> seems to me (without having actual tried it!) that it would be desirable
> to
> have a database access class containing EXEC SQL statements. That is if
> you're stuck using static SQL, which I know Pete always comes out against.
> (I don't have enough experience to have an opinion on that matter).

Slight correction, Frank.

It is EMBEDDED SQL I'm trying to move away from, not static. As both static
and dynamic SQL can be embedded in COBOL I needed to make this point. (I am
not necessarily in favour of using only dynamic SQL; that decision needs to
be taken on a case-by-case basis...)

For most COBOL people the option is either:

1. Use stored procedures, with only triggers embedded in COBOL code.
2. Embed full SQL into COBOL as we have traditionally done since 1983.

In this scenario I favour option 1, for too many reasons to go into here,
but lack of impact on COBOL code if the RDBMS is changed or upgraded, is a
major one. (It means the conversion is "outside" of the application code and
I think that's a good thing...). There are many other reasons...

In the Windows Environment (where I am currently working) these are not the
only options.

1. Use stored procedures, with only triggers embedded in COBOL code.
2. Embed full SQL into COBOL as we have traditionally done since 1983.
3. Use Query Expressions and Lambdas which are intrinsic in the language
(C#, not in COBOL) and require no pre-processing. This means using DB
Classes in the FCL to provide Database Objects and Query Objects which can
then be manipulated like any other Classes.

Obviously, given that option 3 is virtually "future proof" and provides
Queries against ANYTHING (from in-memory arrays, to XML, to RDBs to flat
files, with mixing and matching possible in a single query, not to mention
deferred execution and automatic optimization for parallel processors), I am
currently investigating option 3... :-) (This is the "Brave New World" for
Data Manipulation; it is made possible by DotNET).

>
> Assuming that you were working with mainframe COBOL and you, for whatever
> reason, are not using JDBC for database access, what type of OO
> methodology
> and database access would you use? I assume (perhaps erroneously!) that
> coding EXEC SQL statements in the main body of each program is not the
> best
> OO way to go. Then again, perhaps it is?

It is not, in my opinion the best way to go, whether you are using OO or
not. (see above).

(BTW, JDBC is simply a Java API to provide a consistent way of accessing DBs
from Java...JDBC bridges directly to ODBC when it needs to...Like ODBC, it
has nothing to do with SQL as such.)

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

Robert

2007-10-13, 6:55 pm

On Sat, 13 Oct 2007 06:35:13 -0400, "Rick Smith" <ricksmith@mfi.net> wrote:

>
>"Robert" <no@e.mail> wrote in message
> news:vp80h3tni3fo63b6e427g7qu7n1r4d3sfv@
4ax.com...
>[snip]
>(ESRX). SQL
>deep.
>equivalent
>run on a single
>demonstrated here); SQL
>
>This may be only tangentially related; but I just found out
>that my new motherboard has a dual-core processor.
>A COBOL program I run regularly seemed to be much
>slower. Timed tests showed about a fifty percent drop in
>program execution speed for a single COBOL program
>and a twenty percent drop for two COBOL programs,
>compared with the previous single-core CPU. While the
>CPU has about the same clock frequency (2600MHz vs.
>2.4GHz), each core seems to run at about half the single
>core speed.
>
>Thus, it appears that "multi-core" may not be equivalent
>to "many CPUs", while I thought it should be equivalent.

CPUs don't run at a constant clock speed. They have sophisticated power management that
controls heat by lowering the clock speed. It is semi-common for a 2.4 GHz to be running
at 800 MHz.

Do the chips have the same size L2 cache? The reason some chips are lower priced than
others is because their cache is smaller. The lowest priced Intel chips don't even have an
L2 cache.

Dual core CPUs require dual memory. If someone misconfigured your motherboard, they might
be fighting over memory access.

Do they have the same instruction set? If not, the program may be throwing exceptions that
are handled (slowly) by the OS. If the single core was 32 bit and the dual core is 64 bit
and you didn't recompile, you're running in emulation mode.

Rick Smith

2007-10-13, 9:56 pm

"Robert" <no@e.mail> wrote in message
news:ekf1h3hbig4kod1hleenp7u8jid9njvcin@
4ax.com...
> On Sat, 13 Oct 2007 06:35:13 -0400, "Rick Smith" <ricksmith@mfi.net>
wrote:
>
US[color=darkred]
layers[color=darkred]
than[color=darkred]
>
> CPUs don't run at a constant clock speed. They have sophisticated power
management that
> controls heat by lowering the clock speed. It is semi-common for a 2.4 GHz
to be running
> at 800 MHz.
>
> Do the chips have the same size L2 cache? The reason some chips are lower
priced than
> others is because their cache is smaller. The lowest priced Intel chips
don't even have an
> L2 cache.
>
> Dual core CPUs require dual memory. If someone misconfigured your
motherboard, they might
> be fighting over memory access.
>
> Do they have the same instruction set? If not, the program may be throwing
exceptions that
> are handled (slowly) by the OS. If the single core was 32 bit and the dual
core is 64 bit
> and you didn't recompile, you're running in emulation mode.

Current dual core

Intel Pentium 4, 2.6GHz, 512KB L2 cache, IA-32,
768MB common memory.

Previous single core

AMD Athlon XP, 2.4GHz, ? L2 cache, IA-32,
256MB memory

Sponsored Links