On 07-15-97  20:09, waiting for 22, Neil Heller said:
 FS> They had a hard enough time converting from the old version of
 FS> COBOL (OS/VS COBOL) to the newer version (VS COBOL II).
 NH> COBOL II is several years old now, too.  Micro Focus has come out with
 NH> a "COBOL with Objects" for development geared towards client
 NH> platforms. It should be interesting when and if your shop goes to
 NH> that.
Well, the newest IBM COBOL for VSE is called (simply) COBOL/VSE.  I
think it's the VSE equivalent of COBOL/370 for MVS.  Since COBOL/VSE
only recently came out, and it's the first COBOL for VSE to even have
the full COBOL '85 standard (COBOL II did not have intrinsic
functions) I really doubt that we'll be seeing OOCOBOL any time soon!
When I get Windows 95 I'll probably get the Micro Focus OOCOBOL,
still.
Still, from the books I've looked at OOCOBOL is nowhere near as good
as C++.  COBOL just doesn't seem to lend itself to object oriented
programming.
 
 FS> I don't even know of DB2 is available for VSE.
 NH> I couldn't tell you.  I would think you would have a hard enough time
 NH> finding ANYTHING for VSE nowadays.
We get a lot of stuff that is really just ported from MVS and the
vendor says "Here's your VSE version".  And, of course, there are bugs
galore...
 
 FS> You write the programs in whatever language, with embedded
 FS> SQL calls, right?  Then you run them through the SQL preprocessor
 FS> which translates them into language calls.
 NH> That's the theory.  First you create the source code program with the
 NH> embedded SQL and call that module something with a different extention
 NH> (*.SQL?).  Then run it through a special preprocessor which converts
 NH> the SQL calls into something your compiler can handle and names the
 NH> resulting file *.C (or maybe *.CPP if you're lucky).  Then you compile
 NH> with your regular compiler.  If something is amiss however, you have
 NH> to go back to step one and work only with the *.SQL file.  As a result,
 NH> error messages from the compiler are next to useless (especially if
 NH> you're using many include files).
 NH> A far more civilized approach is to use ODBC (which was developed for
 NH> just this sort of occurrence).  It is yet another language, but a LOT
 NH> simpler.  The ODBC calls are placed into your C/C++ source code but
 NH> you only have to compile once.  There are many books out about ODBC;
 NH> the one I used is called "USING ODBC2" by Que.
Hmm, now that sounds interesting.  I'll have to take a look into it.
 
 FS> Do you build the database itself using the Access
 FS> software, say, and then write programs in C (or whatever) with SQL
 FS> to access the databases?  I pulled up Access the other day but I
 FS> couldn't figure out how to do anything with it.
 NH> Correct, you must first create the database (structure, links,
 NH> indices, etc.) with the native database tool.  I _think_ that Access
 NH> is very automated in that everything is point and click.  Anyway you
 NH> may have to go to the Access docs themselves in order to get the
 NH> complete poop on that; MS on-line documentation is VERY extensive,
 NH> also. 
The thing with mainframe programming is we application programmers
don't have to worry about building the databases.  That's what systems
programmers are for!  :-)
        Frank  (who hopes he won't get booted out for talking about
                COBOL in the C++ echo!)
... No one can hear when you're Screaming in Digital!
___ Blue Wave/QWK v2.12
--- Shotgun v1.38a
---------------