> Often by bolting the jobstreams together from a 'kit of
> parts', not even
> generating the jobs against each individual database, but ensuring
> manually that the eventual outcome would be, AFAICT, the
> desired target structure.
> ....
> (ii) In the meantime, I'd like a way to pre-validate an Adager
> jobstream. As you can imagine, not all the ones above ran first
time.
> Although Adager was very good at stopping on errors before
> any work had
> been done, I was still 'validating' my jobstreams in implementation
> time.

So, on balance, how much time did this "timesaving shortcut" of
stitching together disparate manually-edited Adager jobs really save?
That's what I thought....;-)

> But I had to blot out thoughts of how I could have used Flexibase
for
> this in each territory, giving it just the existing database there
and
> the target schema for the common structure, and letting *it* work
out
> the required changes, and making them.

Which is why more than one of us continued to use FB for this kind of
work long after it was obsolete.

> (i) I'd like it to be able to take a schema, deduce the changes, and
> make them, a la Flexibase. This is, as Alfredo seems to
> agree, Adager's biggest black hole.

Wasn't there a schema-driven version of Adager at one time, at least
in beta-test form?

> It would also be useful to have a 'no update, no jobstream' mode.
It's
> frustrating to be unable to snoop round a database preparatory to
> updating it, and to be denied access to Adager's Help while
> planning how
> to update it, just because the database is in use, and Adager
> has no way to tell that you are 'just looking'.

Absolutely; every database-maintenance tool should provide a "just
testing" mode.

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