| RE: .2
Jerry,
Thanks. Though as I'm using MMS to build my system, yet-another-file to track
and manage isn't my first choice, I'd much rather have the MMS file contain
the specific DAP commands. But what the hey, we do it with linker options.
That leaves the question of semantics. Does DAP assume that MMS can decide
whether to issue a LOAD or an UPDATE?
|
| Richard:
Sorry I couldn't get to your other questions this AM -- I had some minor
workstation problems.
Anyways...
RE: .0
> If I compile MSL for a family of objects, starting from a global entity:
>
GE
/ \
C1 C2
/
C3
> when I issue an UPDATE to DAP and supply the .COM file from the compile,
> are *all* the entities updated?
Two points need to be made here:
o When you issue the UPDATE command you have to specify a CLASS or SUBCLASS.
Whatever CLASS or SUBCLASS you specify is first deleted from the main
dictionary file. This means that ALL child classes of the CLASS or
SUBCLASS specified will be deleted from the dictionary. Then DAP attempts
to LOAD all of the CLASSes and SUCBCLASSes that are included in the DAP
command file that was specified in the UPDATE command.
o There is NO checking done to ensure that the user specified the correct
entity class to be deleted! This is a known bug with the current DAP
utility. What DAP should do is to delete only the classes and subclasses
found in the DAP command file. Unfortunately this is not the case, so
the user must be careful to specify the correct entity class.
I view this as a sever limitiation in DAP!
> Another way to phrase the question, "are the entities affected by an UPDATE
> those listed in the .COM file or the one listed in the UPDATE command?"
The two points made above should answer this question.
> Can I build my MMS files to just use UPDATE now, instead of DELETE followed
> by LOAD? In V1.1 the former strategy wouldn't work because UPDATE failed
> if the class wasn't already defined. I'd like to be able to have the same
> command work whether we are doing the initial population of the dictionary
> or updating what is already there.
UPDATE still only works correctly if the entity CLASS/SUBCLASS specified
is currently in the dictionary. You must use LOAD if it has not already
been loaded. Merging these two commands together is on our wish list and
I apologize for the confusion caused by the existence of two commands.
Other notes:
If you want to save time updating the dictionary you can play some games with
you MSL source files. Break your entity hierarchy into a number of pieces.
and create separate MSL files for each piece. Don't hook them all together
with the MSL "INCLUDE" statement -- use the "PARENT" property to provide the
context. This will cause a number of DAP command files to be created (one per
"piece" of the hierarchy). Then, if you change the MSL specification for that
piece, you only have to UPDATE that part in the dictionary. For example,
given the hierarchy you specified above, you could split it up into 3 pieces:
GE, (C1 + C3) and C2.
If you do this, the first time you want to load your hierarchy into the
dictionary you would have to specify tree LOAD commands:
LOAD FROM GE ! Note this has to come first...
LOAD FROM (C1 + C3)
LOAD FROM C2
Thereafter, you have a little more freedom when it comes to UPDATing the
dictionary. If you change anything in (C1 + C3) you only need to execute
the following DAP command:
UPDATE C1 FROM (C1 + C3)
Likewise, if you change anything in C2, you only have to:
UPDATE C2 FROM C2
However, if you change anything in GE, then you have to execute the
following three DAP commands:
UPDATE GE FROM GE
LOAD FROM (C1 + C3)
LOAD FROM C2
This last set of three commands is necessary, because the first (UPDATE)
command will cause GE and all of its SUBCLASSes to be deleted.
Complicated enough for you? It is for me -- that's for sure!
I hope you understood the notation I used above -- feel free to ask
questions.
Hope this helps. We're working on making DAP more user friendly, but it's
going to take time.
- Jerry
|
| Jerry,
Thanks for the info, your notation was fine. I have already segmented our
MSL as you suggested. We have a devil of a time concocting a sequence of
DAP commands that can be initiated from MMS, and that will do the right thing
with a minimum of wasted pounding on the dictionary.
The V1.2 changes that invoke the PTB at the end of the dictionary updates
increase the challenge, as now I should make sure that all the updates from
all the different MSL segments are done during one DAP run, so we'll update
the parse tables only once. Before, I could use MMS to assure that the PTB was
updated after all the dictionary updates were done.
I've written a procedure that I'm testing now, that should get the job
done.
|