In message <[log in to unmask]>, Leonard S. Berkowitz
<[log in to unmask]> writes
>Richard Barker wrote, "I don't want to have to enter them all in again in
>Adager."
>
>Well with creative use of your favorite editor, you could take either the
>input into your PDL or your output from QSHOW for the new dataset and
>generate input to an Adager job.
>

Yep - I can vouch for the awesome power of a generated Adager jobstream.
Or even 16 of them, to get 16 nearly-but-not-quite identical databases
all conformant to the single superset database structure that covered
each and every one of them.

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.

And it all worked.....

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.

One job for me (generating the target schema), and then 16 identical
updates (as far as the procedure went) instead of 16 different updates
:-(


As Alfredo seeks input re Adager:

(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.

(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.

Possibly, it's been assumed that all such jobstreams are built from an
interactive Adager session, and so 'must' be valid.

In my case, not so; so a job-validating mode that I could run while the
database was in use (just as a jobstream can be constructed under 'in
use' conditions that would prevent a real update run) would be very
useful.


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'.

(Well actually you can do this by pretending you're building a
jobstream, but you have to remember to throw it away afterwards)...


Finally, I'd like *all* my SQL definitions back intact and correct for
the revised database. I lose all my Splits (IIRC) if Adager has to
detach and re-attach.

The kind and knowledgeable folk at Adager pointed me at probably the
best third-party tool for managing these, but it can't (of course) track
the implications of my Adager changes for the SQL definitions, so I wind
up having to hand-adjust these as well....

--
Roy Brown        'Have nothing in your houses that you do not know to be
Kelmscott Ltd     useful, or believe to be beautiful'  William Morris

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