mbuild problems when splitting source archive into 2 smaller archives

[Gary Dixon]

bound_info_rtns_.s.archive is 253 pages long. Planned changes to its info_seg_.pl1 component prevent that larger source from being added to the archive:

mbuild:  arch

---------- library_fetch bound_info_rtns_.s.archive -lb sss.source

   archive u bound_info_rtns_.s.archive info_seg_.pl1

archive: Archive segment overflow while copying who.pl1 in >udd>m>gd>w>hcom>bound_info_rtns_.s.archive
Archive not updated.

Attempting to split that source archive into two smaller archives is done by deleting the version of bound_info_rtns_ built from a single source and object archive, and adding a new bound_info_rtns_
built from two smaller source archives and their associated object archives.

mbuild:  p

 Build_script:             bir.mb;

 Bound_obj:                bound_info_rtns_                  IN: sss  DELETE;

 Bound_obj:                bound_info_rtns_                  IN: sss  ADD;
     bindfile:             bound_info_rtns_.bind              ADD;
   source_arch:            bound_info_rtns_.1.s.archive       ADD;
     source:               check_info_segs.pl1                ADD                compiler: pl1 -ot;
     source:               help.pl1                           ADD                compiler: pl1 -ot;
     source:               help_.pl1                          ADD                compiler: pl1 -ot;
     source:               help_listen_util_.pl1              ADD                compiler: pl1 -ot;
     source:               help_request_tables_.alm           ADD                compiler: alm;
     source:               help_requests_.pl1                 ADD                compiler: pl1 -ot;
     source:               help_responses_.pl1                ADD                compiler: pl1 -ot;
     source:               help_util_.pl1                     ADD                compiler: pl1 -ot;
     source:               info_seg_.pl1                      ADD                compiler: pl1 -ot;
     source:               info_seg_allocate_.pl1             ADD                compiler: pl1 -ot;
     source:               info_seg_error_.pl1                ADD                compiler: pl1 -ot;
     source:               info_seg_parse_.pl1                ADD                compiler: pl1 -ot;
   source_arch:            bound_info_rtns_.2.s.archive       ADD;
     source:               info_seg_specifications_.cds       ADD                compiler: cds;
     source:               info_seg_util_.pl1                 ADD                compiler: pl1 -ot;
     source:               info_seg_verify_.pl1               ADD                compiler: pl1 -ot;
     source:               info_seg_verify_iFile_.pl1         ADD                compiler: pl1 -ot;
     source:               list_help.pl1                      ADD                compiler: pl1 -ot;
     source:               list_ref_names.pl1                 ADD                compiler: pl1 -ot;
     source:               print_motd.pl1                     ADD                compiler: pl1 -ot;
     source:               resource_usage.pl1                 ADD                compiler: pl1 -ot;
     source:               ring0_get_.pl1                     ADD                compiler: pl1 -ot;
     source:               system_info_.pl1                   ADD                compiler: pl1 -ot;
     source:               user_info_.pl1                     ADD                compiler: pl1 -ot;
     source:               verify_info.pl1                    ADD                compiler: pl1 -ot;
     source:               where.pl1                          ADD                compiler: pl1 -ot;
     source:               who.pl1                            ADD                compiler: pl1 -ot;

However, after mbuild recompiles all the sources (in order to create the associated object archives), it thinks the archive_prep request is complete. The archive_prep (or arch) request returns without doing anything.

mbuild:  az

---------- clean -all

  Derived-content segments eligible for clean:
     Unbound_obj:     check_info_segs
     Unbound_obj:     help
     Unbound_obj:     help_
     Unbound_obj:     help_listen_util_
     Unbound_obj:     help_request_tables_
     Unbound_obj:     help_requests_
     Unbound_obj:     help_responses_
     Unbound_obj:     help_util_
     Unbound_obj:     info_seg_
     Unbound_obj:     info_seg_allocate_
     Unbound_obj:     info_seg_error_
     Unbound_obj:     info_seg_parse_
     Unbound_obj:     info_seg_specifications_
     Unbound_obj:     info_seg_util_
     Unbound_obj:     info_seg_verify_
     Unbound_obj:     info_seg_verify_iFile_
     Unbound_obj:     list_help
     Unbound_obj:     list_ref_names
     Unbound_obj:     print_motd
     Unbound_obj:     resource_usage
     Unbound_obj:     ring0_get_
     Unbound_obj:     system_info_
     Unbound_obj:     user_info_
     Unbound_obj:     verify_info
     Unbound_obj:     where
     Unbound_obj:     who

mbuild (clean): Delete the segments above?   no

---------- progress


   COMPLETED   REQUESTS for Builds
   ---------   ----------------------------
      yes      set -desc   or    read -desc
      yes      scan      and/or  read
      yes      analyze
      yes      compile
      yes      archive_prep
               install_ec

mbuild:  arch

mbuild:  

That is the first of several bugs encountered by mbuild when trying to handle this scenario. All of these bugs should be corrected.

[Gary Dixon]

This appears to be a problem in how Bound_obj items are handled by mbuild_data_. When the same bound object is named in both a DELETE and ADD operation, only one BOUNDOBJ structure is created (rather than one for the DELETE operation and another for the ADD operation).

This problem is being investigated in mbuild_data_$get_BOUNDOBJ subroutine which is responsible for creating new BOUNDOBJ structures when needed.

[Gary Dixon]

MCR10102 has been registered to correct this defect.

[Eric Swenson]

​https://s3.amazonaws.com/eswenson-multics/public/mcrs/MCR10102_mbuild_v1.2.pdf