Advice on which database issues matter
April 5, 2006
Transoft's Business Solutions Division manager Robert Collins offered advice awhile back on migration, the kind of overview that can be the first step to moving off an HP 3000. It's a 30,000-foot view, with some close-ups. But his counsel outlines several issues relative to relational databases — the ones nearly every 3000 manager will adopt in place of IMAGE/SQL.
Collins said, "You have several options. Just depends on what your company goals are:"
Using various tools (like those we sell), you can move to Eloquence or you can make more changes to the new environment you are going to. Or you can run in more of an emulated mode where you change the back end of the application to be more modern (RDBMS, VB, etc) but the code still looks and feels the same.
For instance, you can move the IMAGE database to an RDBMS such as SQL Server or Oracle, while keeping the COBOL code looking and feeling just like it always has. You can even move your KSAM files to the RDBMS but make no changes to the source.
Same on the JCL. You can run the JCL in an emulated mode on the target platform.
Same on VPlus, but with some added benefits. You can emulate VPlus on the target platform and your users still get character screens. Or you can point them to VB or ASP type screens with no code changes on the back end.
Or you can go more “native” and convert everything to use more of the native OS features. You can change the IMAGE calls to native SQL. You can convert the JCL to VB script or UNIX korn shell script, and so on and so forth.
RDBMS have become more prevalent due to several facts, one big one already mentioned is SQL. The other is flexibility.
Doing something like adding a field in a hierarchical database can force changes across the entire application. Which is typically not the case with a relational database.
Some shops are willing to live with the limitations because Retrieving data from Hierarchical databases is historically faster due to the same organizational structure that limits the flexibility.
You can implement an RDBMS without changing the DBGET’s to SQL.
We have a piece that sits between the program and the RDBMS to intercept the database calls, convert them to the appropriate SQL calls to the RDBMS. (I think there are a couple of others out there who do this as well.)
We built it because of the simple fact many shops want to go to SQL Server or Oracle. But the amount of code changes to go native SQL code would be massive. The product is called the Transoft Data Access Module (TDAM).