Post by Jan-Erik SoderholmIf you want a true Cobol precompiler I can just think of "Oracle Oracle"
or "Oracle Rdb". If I remember correctly, you could download and run
Rdb for free once, at least for "hobbyist" use.
Well, I knew about Oracle. Other databases have to have them,
too otherwise the database turns out to be pretty useless.
Well, not many databases has precompilers on *VMS*.
Well, I was hoping....
Post by Jan-Erik SoderholmNot everyone wants to use PL/SQL. :-)
Maybe not, but that has nothing to do with precompilers.
I do not see the connection. You can call your PL/SQL
stored procedures by SQL calls using embedded SQL and
your precompiler.
Sorry, too subtle for anyone not currently in the COBOL world. There are
are a lot of people (think PHB) who see PL/SQL and Crystal Reports as a
replacement for not only COBOL, but any real programming language doing
database access.
Post by Jan-Erik SoderholmDoes anyone know if Rdb is still available for free?
I know Oracle is (not the VMS version
however) but running Oracle is a lot of overhead. Pretty much
takes a fulltime DBA to keep it running properly.
Probably depends on the size of the database operation as
such. But yes, Rdb is known for beeing able to run more or
less "lights-out" with no DBA intervention for years.
I'll look into wether or not Rdb can be used for something like this.
But, I have my doubts.
Post by Jan-Erik SoderholmIf you skip the precompiler and can use some C middleware maybe
MySQL might work.
And that would be an immediate showstopper. No text is going to
cover doing that and no real business is doing that. The idea of
getting COBOL and VMS back into the edu world is to show that it
is the way business is being done.
MySQL (just to mention one) lacks any SQL pre-compiler at all.
Seems to be pretty popular anyway.
Exactly. Writting C libraries to access it from COBOL is not something
that any serious COBOL operation is going to be interested in and thus
not something acceptable for the purpose of this course. I am trying
to convince people here that COBOL is still needed for serious business
and, trust me, it's a real hard sell in academia. (Kinda like selling
VMS to the same group!!)
Just as an aside, I wrote COBOL wrappers for the Postgres C libraries
that worked quite well and eliminated the need for the COBOL developer
to know anything but COBOL. And, I am trying to convince a grad student
here to make his thesis project an SQL Pre-compiler for COBOL which
could then mmove into the Open Source world making GNUCOBOL (formerly
Open COBOL) a more viable option for serious COBOL programming.
Post by Jan-Erik SoderholmEmbedded SQL for C has been deprecated as of Microsoft SQL
Server 2008.
That's because they are trying to push their own option to SQL.
Post by Jan-Erik SoderholmSo embedded SQL through SQL precompilers is not generally
"the way business is being done" today.
Well, having done it for a living within the last couple years and
knowing a lot of places that are still doing it, I disagree. :-)
Never confuse the actions of MicroSoft with what the business world
is or wants to do. Like academia, they are more interested in steering
the bus than getting their riders to the destinations they want.
Post by Jan-Erik SoderholmThen there is what is called "SQL Modular language", don't know if
anything but Rdb supports that, but it is a realy nice way to separate
the application logic in the Cobol code from the SQL code running
the database operations.
The whole idea is to show COBOL doing with databses what used to
be d one with files. If you are going to separate the database
from the COBOL people will ask, "Why are we learning COBOL if you
can do all this without it?"...
Without it? You need to have all your business (non-SQL)
application logic somewhere, not? That is what Cobol is for.
Many people today think the PL/SQL is the answer to that. This attitude
was one of the primary reasons I left that last COBOL gig I was doing.
Post by Jan-Erik SoderholmThere are Rdb pre-compilers for Ada, C, Fortran, Pascal, PL/I and Cobol.
There is nothing special around Cobol here.
I never said there was, other than the very strong need for COBOL programmers
in the business world. In the IBM world PL/I is still going strong. And
Fortran is out there but I doubt there are many people doing database
business applications in it as that wasn't Fortran's forte. We did COBOL,
Fotran and PL/I on Univac mainframes using DMS-11 a long time ago. A lot
of those applications are actually still out there. :-) I really can't
imagine there is much call for Ada programmers who can do the same. Come
to think of it, I really can't imagine there is much call for Ada programmers
period. :-)
Post by Jan-Erik SoderholmYou use Cobol becuse it solves your bussines logic as
you like, not specificaly becuse it has a SQL precompiler.
Where did you get this logic from what I said? COBOL with database access
is how most of it has been done for at least 20 years. Maybe the fact that
most COBOL courses were still teaching sequential, direct access and ISAM
was one of the reason for it's fall from grace, who knows. But my intent
in getting a COBOL course going again is to help design a course based on
what businesses need in a COBOL programmer today. If what they learn isn't
going to help them get a job, no student is going to take the course.
Post by Jan-Erik SoderholmAnd we are back to PL/SQL. And we
are also back to the way the anti-COBOLists want it to be even
though we have those millions of lines of COBOL still running
out there.
I do not follow your logic. You do not seem to understand
the concept of pre-compiled (also called embedded) SQL and
definitely not "SQL module language".
I can only talk about what I saw (recently) in use at COBOL shops.
It wasn't a lot of "pre-compiled SQL" it was a lot of:
CONNECT, DECLARE CURSOR, FETCH, INSERT, SELECT, UPDATE, etc. All
set off by EXEC-SQL/END-EXEC pairs which get expanded into system
calls by the pre-compiler..
Post by Jan-Erik SoderholmThe SQLMOD compiler compiles SQL files into standard object files
that is simply CALL'ed from and linked to the main Cobol code just
as if it had been written in any language.
And that is yet another niche language...
Well, it is "Feature ID: E182 Module language" in all SQL standards
since at least SQL:1999.
Yeah, and COBOL has had OO since 2002. And most of the millions of lines
of existing code (and most of the serious new development as well) don't
use it.
Post by Jan-Erik SoderholmFully supported by Rdb. On Oracle you are forced to the less flexible
embedded SQL through pre-compilers.
And yet, Oracle is the number one databse in the world, even though
others, including free ones, have more capabilities and features.
What you see as "less flexible" businesses see as the way they have
been doing it for decades. They don't need flexibilty, they need to
get the job done.
Post by Jan-Erik SoderholmAnd of course also limited to
those languages that *have* a pre-compiler at all.
Like COBOL. Which is the only one I am interested in at this point
in time.
Post by Jan-Erik SoderholmBut yes, many uses embedded SQL anyway, in particular for
smaller project
Define "smaller". The IRS? The Navy? All your credit card transactions?
Post by Jan-Erik Soderholmwhere it might be that the programmer writing
the Cobol code also writes the SQL code...
If he can write it in a form that matches the COBOL language, why not?
How is that any different from picking out which records or fields in
a file he works with? I've done it. On some really big systems.
Post by Jan-Erik Soderholmthat time has to be wasted
teaching when the intent is to teach something the students can
actually apply when they leave school. My intent is to re-introduce
COBOL, not show that there are alternatives. They already know that,
it's called Java.
Right. You obviosly don't get it. Yes, you can teach basic
Cobol to your students. But do not involve databases then.
If you are going to involve database work, you have to
choose your path. Maybe VMS/Cobol/Rdb. Maybe MVS/Cobol/DB2.
Maybe something else. You learn a specific environment incl
the database that is popular in that specific envrionment.
All of the systems I have seen use pretty much the same EXEC-SQL
directives. If they learn any they will find it easy to adapt.
They aren't going to be "involved in database work" any more than
they would have to know how the filesystem works if they were doing
sequential files. The database is merely a datasource and from COBOL
it is accessed only slightly different than if it were a file. Heck,
I have had to fix programs where the conversion (2 decades ago!) from
flat files to databases involved writting a module in COBOL to read
the database, write the data to a flat file and then process the flat
file. Obviously, because they were government contractors specifically
hired for the conversion they were not the brightest bulbs in the
lamp. But it showed just how similar the methodologies were. My
goal is to have the students taught what the business world wants them
to learn. Like it or not, their primary reason for being here is to
prepare for a job and anything that detracts from that is a waste of
their time and their parents money.
Post by Jan-Erik SoderholmBut fine, learning some basic Cobol might be a good thing,
you can later take a Cobol job and learn the specifics there.
Your gonna have to do that no matter what you study. No student
leaves school as an expert. I just want our students to have a better
set of tools than the people they will be competing with in the job
market. And I (and others at other schools lately) think that COBOL
is a good tool to add to the toolbox.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
***@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>