09/21/87 hierarchy_backup Known errors in the current release of hierarchy_backup. # Associated TR's Description 49 phx20752 backup_dump [verified] timing problem allowing backup_dump to abort when it is called via an alarm wakeup and a typed ahead call. 48 phx20313 backup_map_ [verified] bakup_map_$error_line is called with too many arguments. 46 phx20013 reload [investigating] >udd>TR>TR_tc>tc1>explanatory.trans.phx20013 reload does not trim directories that are not on tape, but on disk and have not been modified since the dump was taken. . As time and resources permit this problem will be evaluated and better defined at a future date. 43 phx20082 The hierarchy reloader is unable to reload absentee queues from ring 1 level. This problem will be investigated after MR12 is released. 42 phx17931 The hierarchy reloader may be setting acls incorrectly when reloading. once investigated, more information will be added here. 40 phx19804 The TR describes a symtom of the actual problem. The problem being that the hierarchy dumper creates all its work space as static variables and does not initialize any of them. The programs need to be changed to set all variables to a proper initial value. 39 phx15671 the hierarchy dumper programs contain declarations for system subroutines which are obsolete. These declarations need to be updated to match the parameter declarations of the current routines. 34 phx14430 Retriever/reloader spuriously sets ring brackets to 1 on containing dir of a reloaded directory. That is, if you reload >a>b>c, and >b does not exist, it is created with ring brackets of 1,1. 31 phx18476 backup_load does not clean up after itself. In particular, on tape errors, it is very good at not detaching its switches. 29 phx17583 The complete_dump command fumbles the dump suffix within the -control control arg. 25 phx15734 The hierarchy dumper requires "s" access to the directory containing the dump control file. This should be unneccessary. 22 phx15616 The retriever should do something to the quota on master directories it loads into when cross-retrieving non-mdirs into it. 21 phx15802 A record quota overflow occuring during the backup_dump preattach leads a loop through various routines. 19 phx15859 The reloader and dumper should use the user's name in the dprint header args, instead of making everyone's output labeled "the same". 18 phx15348 On rare occasions, the dump maps from the reloader (-noreload) will miss a couple segments that are on the tape and reloadable. 17 phx14714 Cross-retrieving under a new name attempts to add all the old names to the new object, deleting an old copy of it under the old name. That is, if the old name is FOO, and the new name FOO.NEW, it tries to add FOO to FOO.NEW, defeating the purpose of the cross-retrieve. 16 phx14707 you cannot turn off the map for incremental dumps. The assignment of "1"b to the mapsw in start_dump.pl1 is in the wrong place. 15 phx14544 The dumper and reloader conspire to screw up the top level dir of a retrieved hierarchy. If >udd>a is an upgraded directory, and it is dumped and then deleted, and then a retrieval is made for >udd>a>b, a's attributes will not be correctly set when it is created if it was the top level directory of the dump. In the upgraded case this causes quota inconsistencies and SOOS directories, and prevents the subdirectory from being reloaded. 13 phx13832 Crossretrievals of level 1 directories do not work. 12 phx13773 The dumper ignores the volume dumper switches. Also the DNZP switch. Possibly other things. The fix requires a rewrite of the dumper, with attendent compatability difficulties. 10 phx11581 reload -nomap -noreaload produces a map anyway. 7 phx13510 Complete_dump -nomap -other things still produces a map. ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved