Architecture Toolbelt Emerges for 3000s
March 14, 2011
When Connie Sellitto of the American Cat Fanciers' Association (CFA) asked for help preparing for a migration, the 3000 community hacked out suggestions and pointers. But much of the toolset designed to identify what's to be migrated off a 3000 can also be put to use in sustaining projects. Sustaining is what a manager should be doing to homestead, if they are not migrating. As the word suggests, sustaining is an activity that goes beyond glancing at a console to see if the 3000 is running, plus ensuring there are enough backup tapes.
The advice from 3000 managers and experts was aimed at Sellitto's deadline of tomorrow; she needs to present a "wireframe" diagram of the system's database architecture by March 15. The document will go into the hands of a web design company the CFA's board has chosen, one which has won the right to migrate its HP 3000 to a Windows environment.
Wireframe is architectural terminology for the map of website design, page by page. In the environment at CFA, databases and applications take the place of website pages. Alan Yeo of ScreenJet, which has built the EZ View modernization kit for 3000 user screens still in VPlus, said the ubiquitious PC tool Visio that Sellitto was learning quickly might be overkill.
If you have Adager/Flexibase/DBGeneral, or already have a good schema file for the databases, just generate the schema files and import them into Word or Excel and give them to [your migrators]. If they can't put together the data structure from that, no amount of time you can spend with Visio is going to impart any more information.
A schema file isn't difficult to understand, and if they can't, there isn't much you can do to help them.
Yeo added a few pointers on understanding the schema file.
A Primary Key is a sorted key, and indications that a specific numeric has (n) implied decimal places should be the most they should need, plus a couple of pages from the IMAGE manual that describe the data types. IMAGE structures aren't complex.
But 3000 consultant and developer Roy Brown wrote us to advise further, with detailed pointers on how anyone who needs to chronicle and maintain the architecture of a 3000 can get the job done -- whether they're migrating, or sustaining.
Visio (Professional, let's hope they gave her Professional) can read the details of a SQL database and produce a visual schema automagically, so it's not like she's got to chart them manually. And standard HP 3000 tools let you generate SQL views of TurboIMAGE databases, for Visio to chomp on.The SQL extensions to IMAGE are covered in the HP Communicator at docs.hp.com/cgi-bin/doc3k/B3021690178.13563/65
Brown added that IMAGE/SQL specifications, to help train any migration contractor, are also online at HP's 3000 web pages.
It's been a while since I used these tools, but they let you work on TurboIMAGE databases as if they were SQL ones. We were using them to pull data into Business Objects.
I recall using one of the tools (IMAGESQL) to even extend the definitions of the items, so the SQL access would know how many decimal places numeric fields had, something not held in IMAGE schemata. All these tools run on MPE, on the HP3000.
With all the above defined, you can then use the supplied ODBC client on a PC linked to the HP 3000, so that ODBC-compliant programs 'see' a SQL representation of the TurboImage database, and can work with this just as if it was a SQL one. Birket Foster (whose company created ODBCLink/SE) will probably know a great deal more about this than I do. And also in what ways his paid-for ODBCLink is superior.
But if I recall correctly, you configure things so the ODBC-compliant program on the PC knows: to use the ODBCLink driver; where the HP 3000 is (IP address or hostname), and how to authenticate -- and away you go.
Visio has free and open source competition, software which HP support veteran Lars Appel pointed out. "Perhaps Visio has similar 'database graph' features such as free or open source tools like dbVisualizer or SquirrelSQL."
Stan Sieler of Allegro noted that "You might look at our DBHTML product, with example output on our website, although it doesn't draw pretty pictures."
Sellitto checked back in on the 3000 newsgroup and reported some progress, but her migration contractor really seems to want those diagrams.
The SCHEMA file produced by Adager and/or FO from QUERYNM provides sufficient detail as to the tables (datasets) and fields (items) of an IMAGE database. I have provides these, along with an explanations such as ‘X6’ means a ‘char’ of 6 characters, ‘search item’ would be an ‘index’ and so on. In addition, I provided narratives of what each ‘table is used for, FO listings of representative records, and screen shots of how our users access the data. Should be sufficient -- and they seemed to indicate an understanding.
But now, with a few days before they visit our office, they have again requested the diagram approach.
Denys Beauchemin, who's written database tools for the 3000, wonders if automating these architecture layout tasks for 17 database is really worth the learning curve -- especially on a one-time, leave-the-3000 project.
You’re spending an enormous amount of time trying to make tools work. If this was something that would be ongoing, I can see spending the time for that, but for a one off thing?
I would sit down with the schemas and some paper and simply draw the two-level diagrams with a pencil, showing the links between master and details. Then I would simply scan the papers into a PDF file and call it good.
Beauchemin's opinion shows where a sustaining project could benefit from architecture automation, while a migration project won't enjoy the same payoff.
In a final test, Yeo worked with Visio and other tools and has broken down the process to show the architecture of 3000 databases.
The only databases and tables that I could access are those set up in the SQL DBE definition. So if you haven’t gone through all that work in the first place then its a non starter. As far as I can see the DBE only contains information about the datasets that someone has chosen to add (or probably that is make available via a view). When adding the databases' datasets to the DBE, if only the default item mappings were used, then all you are going to find out is that an item is char or numeric -- but you would have no idea about "date" types or decimal places etc. So again, not much good if you're trying to provide a data structure description.
Anyway, taking a reasonably well formed database into Visio and reverse engineering, you do get the tables and items. It will show you what the indexes in the tables are but as far as I can see it doesn't show that a detail is linked to a particular master. Automasters are missing anyway as they are really only for IMAGE.
My conclusion: if you have done all the work to load the databases in the SQL/DBE and done all the data type mappings, then importing in Visio might be a reasonable start to documenting the databases, as all you would have to do is add the linkages between the sets.
If you don't have everything in the SQL/DBE then I would say we are back where we started.
Go into QUERY, open the database just do an "FO" it will tell you everything about all the items, all datasets, all indexes, paths etc. Do a select all, copy, go into Word and paste. Then if you want to be really helpful, go through the item defs and mark up if they are a date format, of if numeric how many implied decimals. Oh, and if you're using a char as a numeric, or you have a field overloaded with undescribed children, that is probably the most useful info.