Thread: cobol storedprocedures

cobol storedprocedures

From
"MICHAEL BATTANI"
Date:
I've been scanning the postgres website and yours to find out any
information on cobol stored procedures.  Is there any plans on incorporating
this
in future releases?




Michael Battani
Companion Technologies
8901 Farrow Road
Columbia, SC  29203
803.264.3569
michael.battani@companiongroup.com

Re: cobol storedprocedures

From
Dawid Kuroczko
Date:
On 8/15/05, MICHAEL BATTANI <MICHAEL.BATTANI@companiongroup.com> wrote:
> I've been scanning the postgres website and yours to find out any
> information on cobol stored procedures.  Is there any plans on incorporating
> this
> in future releases?

I don't think anyone is working on such a thing right now.

The procedural languages development usually follows this route:
1. Someone skilled in C needs some procedural language, be it Perl,
Python, Ruby, etc.
2. This person "hacks" a "glue" code in C for such a language -- this
step is actually relatively easy -- you just have to create code
similar to already existing procedural languages.
3. This person releases the code, probably as a pg_foundry code,
announces it and so on.
4. If language receives significant response it may be moved into core
system.  If it does not or for some reason (is not mature enough, user
base is too small, nobody feels a need to drive the process), it is
still available as pg_foundry or similar project -- you have to
download it seperately -- it is the case with PL/Ruby, PL/Java, PL/J.

The problem is finding that 'someone'.  The law of big numbers states
that given large enough population of <this language> developers, you
will find this 'someone' in this
group. ;)  Personally I do not know Cobol, do not know any active
Cobol coders and
do not know any Cobol implementation internals (how difficult is it to
plug it in as
an embedded language).

One question you have to answer yourself is what do you need Cobol for?
There is a high chance that PL/perl, PL/python, PL/ruby or PL/R will do the
thing you need, but have advantage of being "already there".

   Regards,
      Dawid

Re: cobol storedprocedures

From
Martijn van Oosterhout
Date:
On Wed, Aug 17, 2005 at 01:05:07PM +0200, Dawid Kuroczko wrote:
> On 8/15/05, MICHAEL BATTANI <MICHAEL.BATTANI@companiongroup.com> wrote:
> > I've been scanning the postgres website and yours to find out any
> > information on cobol stored procedures.  Is there any plans on incorporating
> > this
> > in future releases?
>
> I don't think anyone is working on such a thing right now.
>
> The procedural languages development usually follows this route:

It's even more complicated than this I think in this case. Pretty much
all of the procedural languages currently supported are interpreted,
it's easier that way. Compiled (C) functions need to be compiled and
loaded specially, which I imagine is not what the original poster
wanted.

Looking on the web for a free (open source) COBOL interpreters[1][2]
has not been fruitful which just places another roadblock. I know
nothing about COBOL so I have no idea how hard it would be to write
one. Perhaps translating to another interpreted language would be
easier. At least COBOL to C converters seem to be in abundence.

[1] http://www.thefreecountry.com/compilers/cobol.shtml
[2] http://www.ecuadors.net/compilers.htm

Hope this helps,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Attachment

Re: cobol storedprocedures

From
Christopher Browne
Date:
> I've been scanning the postgres website and yours to find out any
> information on cobol stored procedures.  Is there any plans on
> incorporating this in future releases?

Not really.

The 'preferred' sorts of languages to include for stored procedures
tend to be interpreted languages.

There is something of a paucity of free cross-platform COBOL
implementations, and what I've heard of have been compiled, which
makes them somewhat less ideal...

The best chance might be to locate some COBOL-to-Java translator, and
look into linking the results in to one of the Java stored procedure
systems...
--
(reverse (concatenate 'string "moc.liamg" "@" "enworbbc"))
http://cbbrowne.com/info/cobol.html
If we were meant to fly, we wouldn't keep losing our luggage.