Re: Conversion of data & associated logic from ISAM to RDB
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 5 Apr 2007 11:59:49 +1200
"DaveM" <renfrew76@xxxxxxxxxx> wrote in message
news:1175712344.282357.44480@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Pete,
Your response was VERY helpful, and I am grateful to you for taking
the time and patience to put it together. We will check out the sites
you recommend, and I will pass along all of your suggestions and
examples to my team as well as management.
Also, please forgive me if I misspoke in my final para, as I would
never presume the right to ask anyone for the favor of writing me up
an entire detailed game plan on how we should carry out the whole
conversion project.
Nothing to forgive... :-) I understood what you were requesting. You just
gave me an opportunity to point out that the conventional wisdom to use
embedded SQL is not necessarily the best solution. A whole raft of new
techniques for data access and manipulation are starting to filter through
to the mainstream and the next couple of years will see some major changes
in the way we access data, particularly on PC platforms. By advising the use
of ADO.Net I am ensuring you at least are on the playing field for this
stuff.
SQL Server is a good choice, although I don't know of any current RDBMS that
are actually "bad". DB2, Ingres, Oracle, and even MySQL (which is free; your
management should love that :-)) I have found to be completely adequate
systems. I have one system that uses MySQL and SQLServer together and it all
works fine. (It evolved that way... when I first started building it I
couldn't afford SQL Server :-) Later, I added some components that used SQL
Server and thought... I'll get round to "unifying" it some time... That was
four years ago... :-))
The kind of information that I meant to ask for
is what you have indeed since given me, and I thank you!Thanks for the acknowledgement (You'd be surprised how many people here
Dave Miner
never even reply or let us know whether what was posted was useful...).
I imagine you have completed the conversion of your ISAM data structures to
Databases, and are now seeking to load them. In case you haven't, I have a
tool I wrote some years back that can automate that process. (ISAM2RDB). You
feed it your ISAM COBOL definition (Source code) and it creates a Relational
Database in third normal form. It builds linked tables for repeating groups
(COBOL OCCURS) and also copes with REDEFINES in the COBOL source.
I also have a Declaration Generator tool I wrote that will analyse a table
on a RDB and generate a COBOL record definition for interfacing to it. This
is the same facility provided by DECLGEN in IBM mainframe environments. It
actually can go one step further than generating a COPY book to include in
your COBOL, by also generating a COBOL access module that can mainatain the
table (INSERT, UPDATE, SELECT *, and DELETE) so that programmers with no
knowledge of SQL can still access and update the database, but are shielded
from the details. The source code generated is COBOL with embedded SQL, and
can be useful as a learning aid while people are learning SQL.
Given that your management are not prepared to spend money on training
(which SHOULD be their top priority), it is highly unlikely they'll spend
any on tools :-), however, as I wrote these things many years ago when first
looking at converting to RDBMS, and as I am moving away from Embedded SQL
(ESQL) the value of these tools to me now is pretty low. If you are
interested, I can let you have a free demo... send me some COBOL ISAM
definitions and I'll return you an ACCESS DB generated by the tools (this is
easily exportable to SQL Server, but takes less space for mailing.)
I have some stuff going on at the moment that is occupying my time and
effort but I hope within the next month or so to have a Web site up that
will offer certain facilities as a Web Service. (Now that I've cracked
getting COBOL COM and DCOM+ components to run as a Web Service... :-)). I
guess I could put these tools up there too, and people could then use them
remotely on an "as needed" basis... or maybe I'll just take a break :-)
Pete.
.
- References:
- Conversion of data & associated logic from ISAM to RDB
- From: DaveM
- Re: Conversion of data & associated logic from ISAM to RDB
- From: Pete Dashwood
- Re: Conversion of data & associated logic from ISAM to RDB
- From: DaveM
- Conversion of data & associated logic from ISAM to RDB
- Prev by Date: Re: DATA MANIPULATION TEXT TO SIGNED NUMERIC RM COBOL
- Next by Date: Re: Command-Line / Environment variable acess (new thread)
- Previous by thread: Re: Conversion of data & associated logic from ISAM to RDB
- Next by thread: DATA MANIPULATION TEXT TO SIGNED NUMERIC RM COBOL
- Index(es):
Relevant Pages
|
