Cobol - Re: Using Cobol - Inserting same data into a DB2 table every every week/until a condi

Author

Re: Using Cobol - Inserting same data into a DB2 table every every week/until a condi

Lovelin

2007-04-09, 6:55 pm

Stored procedures are good, but it this would be best achieved by a
Scheduled batch job. A cobol DB2 program.

Pete Dashwood

2007-04-09, 6:55 pm

"Lovelin" <lovelin@gmail.com> wrote in message
news:1176153400.624676.36260@y66g2000hsf.googlegroups.com...
> Stored procedures are good, but it this would be best achieved by a
> Scheduled batch job. A cobol DB2 program.
>

"Best" huh?

A brave assertion.

There are several ways to achieve this and the "Best" is purely a matter of
opinion.

The original poster stated a requirement.

That requirement lends itself to a triggered process. So that was what I
suggested. However, as we don't have the full details of what is actually
being done or why, it is simply speculation as to what the "Best" approach
may be.

MCM pointed out that a different conceptual approach might be a better
solution.

It is totally arguable as to whether this is "best achieved" by a COBOL DB2
job with embedded SQL.

Here are just some of the arguments as to why that might NOT be the "Best"
solution:

1. It requires a batch job to be run EVERY DAY.
2. It requires a COBOL program to be written and activated, with all the
unnecessary overhead that entails, just to do a DB update that can be easily
handled by a stored procedure.
3. Conceptually, this is a "polled" solution as opposed to an "interrupt
driven" one. Few people would argue that polling is more efficient than
interrupting...

If you are unfamiliar with the use of triggers and stored procedures, then
embedded SQL may well seem to be the "Best" solution.

(To a man with a hammer, everything is a nail.)

But that doesn't mean that it is.

Pete.

Michael Mattias

2007-04-10, 7:55 am

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:57vv98F2crtakU1@mid.individual.net...
> 3. Conceptually, this is a "polled" solution as opposed to an "interrupt
> driven" one. Few people would argue that polling is more efficient than
> interrupting...

Well, perhaps not argue it, but on my BASIC-language Peer Support website
("Internet BBS" for we old farts) we get tons of posted code which uses
polling rather than availing itself of the countless (Ok, so it's more like
dozens, which is surely 'countable') 'interrupt-like' services provided by
the Windows operating system.

But to make your point, this polling code is often prefixed with "Can anyone
help? My code below is sucking up CPU resources... "

MCM
(If anyone cares: http://www.powerbasic.com, click "Support" or "forums" or
anything that looks like that, you'll get there. No registration required to
browse, only to post).

Sponsored Links