Conference azur::mcc

Re .0:

>The delete/load strategy has gotten
>more expensive with V1.2 as the parse tables are updated after each.

Not if you use Ultrix :

	( echo delete class foobar ; echo load class foobar ) | mcc_dap

Will do an update, and rebuild the parse table only once.


Regards.

Pierre.

Re .0:

>The delete/load strategy has gotten
>more expensive with V1.2 as the parse tables are updated after each.

Not if you use VMS either:

  $ manage/tool/dictionary
  DAP> delete class foobar
  DAP> load class foobar
   :
   :
  DAP> exit

You can execute as many DAP LOAD, UPDATE or AUGMENT commands as you like in
one DAP session before typing EXIT to update the parse tables.

You can also put all of these commands in a text file and execute them w/ the 
"@" command:
   
  $ create dap_commands.com
  delete class foobar
  load class foobar
  ^Z

  $ manage/tool/dictionary
  DAP> @dap_commands.com
  DAP> exit

Hope this helps...

                                                                       - Jerry

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.