"mzafar" <member32079 (AT) dbforums (DOT) com> wrote

I'm not 100% sure this is true in Unidata but as far as I know, in general,
MV databases do not require full "schema" development. The structure of
data within individual database files, and the related assocation to othe
database files can be fully developed and contained within the basic
programs themselves. Usually, you will find most databases will have a DICT
file but many systems that I've worked on, these were not fully maintained.
Plus, if SystemBuilder was used on the system, these DICT files were so
poluted (my choice of words) that they became totally unusable for
documentation purposes. You can try LIST DICT MYDATA and see what you get.
Ultimately, I think you'll have to read the programs to be sure.

Not an easy task, to be sure, but if you ever consider hiring someone to
document your system, I'm available. <smile>

"mzafar" <member32079 (AT) dbforums (DOT) com> wrote


For each file (table) in the database their is a DICT file that has
definitions that show what you can expect in each field. EG field 3 might be
10 characters wide (for display purporses) and contain dates that are
displayed wit 4 digits for the year and is multi-valued. Field 4 might be a
30 characters wide (again for display purposes, there is no actual
constraint on the number of characters that may be placed in a field), is
left justified and single-valued. And so on...

Listing the DICT will also show you the NAMES of the fields, which will
provide information for you if they have been intelligently named.

If your file/table is called CUSTOMERS then LIST DICT CUSTOMERS should show
you the contents of the DICT.

I think the REAL anser to this question is that there isn't a standard
tool available in UD to do this for you. Whilst you may be able to
"imply" the relationships between files from whatever you have in the
dictionary, I have seen a number of systems recently (conversions to
Visage :-) where there really was no dictionary to speak of.

Your mileage will vary depending on who wrote the system, and also how
long ago ! and certainly you will not find anything graphical.

Many would argue that one of the great "strengths" (?) of the mv data
model is that it lacks the formal rigor of SQL, allowing people to
easily make changes on the fly. Of course this "flexibility"
invariably comes back to haunt the author (or those that follow !!).

This problem (which I see as a VERY REAL problem) can be avoided with
appropriate internal standards, but..., well, unless you have a
design/development/maintenance team of 1, things are still likely to
slip through.

If your software was designed with a tool that made use of
dictionaries, then you are probably in good shape .... if not, then
your task will be "interesting" as you try to map your system.

I can also see that next you will probably want to get a handle on
which programs actually update which files (just to make sure they
maintain referential integrity) .... there are a number of people that
sell utilities (Dave Weaver ?) that can help with this, and also
mapping things like which subroutines are called from where etc, etc,
etc (not quote roles, but ....)

Bon Chance !



Ross Ferris
Stamina Software
Visage - an Evolution in Software Development



"Bob Dubery" <megapode (AT) hotmail (DOT) com> wrote