Steve replied:

>>    :FILE DBSTEXT=myschema
>>    :RUN DBSCHEMA.PUB.SYS;PARM=1
>
> FWIW, I've NEVER used such a sequence. I
> "ALWAYS" create item, set, database, etc.
> definitions in DICTIONARY; when I have
> what I want, I use DICTDBC and then DBUTIL.

That's what we've done for 15+ years (and of
course Steve used to be here to do it with
us...  ;-)  )...

Using the DICTIONARY has several benefits.
One we have used to good effect for several
years of small to major changes in our
production database structure is this little
sequence;  which sort of covers for the one
(IMO) major remaining hole in Adager: It still
doesn't fully support making database changes
from a schema file (like Flexibase does (but
of course Flexibase is behind in support of
recent IMAGE enhancements) ); which means that
if you have a lot of complex changes to make
in production at once you have to be REAL
careful not to screw up if you do it manually.
This does a quick automated cross-check:

(1)  You have all pending production changes
in a master DICTIONARY.

(2)  Run DICTDBC as per Steve's above to create
a new schema file that reflects all changes.

(3)  Create and run ADAGER job that you think
implements all those changes in production
(after backing up your database, of course).

(4)  Run DICTDBD to load a schema definition
FROM the post-Adager-run production database
in TO a "blank" (except for the one boot-strap
record that has to be there) DICTIONARY.  Then
turn right around and run DICTDBC against that
no-longer-blank DICTIONARY.  You now have a
schema file from your master DICTIONARY and one
from the changed production database.  All you
have to do now is run a file compare against
the two schemas.  If they are the same, you
are in sync...  oops.:  ONE more little detail:
It turns out DICTDBD does not load all the info
that DICTDBC gets from a master DICTIONARY...
To get around that, I wrote a simple 40-line
Transact program to remove all the "not-common"
elements from a master DICTIONARY schema file.
If anybody wants that code and has a Transact
compiler, let me know and I'll send it to you.

SIDEBAR:  Not counting run time for the Adager
job, the above sequence can be completed in
about the time it took me to type this.  But
for cases where someone is making very frequent
changes to a database, it certainly would still
be handy to be able to drive all Adager changes
from a schema file generated from a production
master DICTIONARY..  Helloooo, Adager...   :-)

Ken Sletten

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *