Re: Infinite Loops and Explicit Exits

From: Robert Wagner (spamblocker-robert_at_wagner.net)
Date: 12/07/04 

Date: Tue, 07 Dec 2004 15:57:57 GMT

On Wed, 8 Dec 2004 02:12:43 +1300, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:

>
>"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
>news:l029r0990r1d0116d8nihu34cgrbhs9i0b@4ax.com...

>> >black box where you simply give it the employee you want paid and it
>returns
>> >the amount to pay him. All of his various rates would be accessed from
>> >databases, along with the hours or part hours for each rate. Tax and
>> >deductions, FICA, pension fund, whatever, would all be found on databases
>> >and manipulated by this one Object Method using rules based processing,
>> >implemented by soft rules, that can be changed outside the object.
>>
>> OO is not required to do that. For decades, people have done it with
>> called programs, remote procedure calls, etc.
>>
>No, people have TRIED to do it with those devices and had varying degrees of
>success. OO lends itself to this type of solution, but I agree it does not
>preclude other solutions.

I agree that OO lends itself, but people were doing it quite well
before OO. Typically, it was seen in large-scale projects, not demo
programs or simple application systems.

>> Sure it is. On Oracle, at least, stored procedures can be written in
>> any language, including Cobol. The technical term is External
>> Procedures. They work just like stored procedures, with an entry in a
>> Library table pointing to a .dll or .so.
>>
>The difficulty is when you get into extended SQL which has facilities that
>are database dependent and not available in COBOL.

This is FUD. You're not talking to management here. First, the syntax
for calling an External Procedure is exactly the same as calling a
stored procedure. The caller doesn't know or care how it was
implemented. Second, a Cobol program can issue any valid SQL
statement. It is not limited to a subset just because it's Cobol.

>So you embed this SQL
>into COBOL. What for? It is perfectly capable of standing alone on the
>database without a COBOL wrapper.

Such procedures are normally tested standalone, without a Cobol
caller. One brings up a general-purpose SQL tool such as Toad, Msquery
or SQLPlus to call it and see the result. The procedure doesn't know
or care whether it's being called by Cobol or something else. It could
just as well be called by a Web page, script or another database
procedure such as a trigger.

>I understand you are talking about writing
>stored procedures in COBOL and I know this facility has been available for
>some years now. But with extended SQL you simply write the procedures in SQL
>and there is no requirement for any other host.

One cannot write procedures in ANSI Standard SQL. It's a
non-procedural language. They are usually written in a *proprietary*
language supplied with the database, for example PL/SQL.

Relevant Pages

  • Re: Infinite Loops and Explicit Exits
    ... The behaviour could only be changed by changing the database. ... >>designing proper databases and using stored procedures on them, ... are database dependent and not available in COBOL. ... But with extended SQL you simply write the procedures in SQL ...
    (comp.lang.cobol)
  • Re: help with tables
    ... SQL0060W The "COBOL" precompiler is in progress. ... result set, however, in embedded SQL I've always used the cursor and FETCHed ... I'd expect it can be done with any database, because .NET people take sets for granted. ... At the moment there is some debate as to whether the addition of LINQ ...
    (comp.lang.cobol)
  • Re: Infinite Loops and Explicit Exits
    ... the whole payroll system would be dependent on proper database ... I design large systems the same way. ... Stored procedures ARE application code. ... any language, including Cobol. ...
    (comp.lang.cobol)
  • Re: Infinite Loops and Explicit Exits
    ... OO lends itself to this type of solution, ... >>are database dependent and not available in COBOL. ... a Cobol program can issue any valid SQL ...
    (comp.lang.cobol)
  • Re: Bitwise OR just like SUM or COUNT
    ... the database, **by definition**. ... I don't look at or directly manipulate metadata in ANY of the SQL ... do when I am wearing my programmer hat. ... COBOL & SQL program from an EBCDIC machine ...
    (microsoft.public.sqlserver.programming)