04/25/86 dump Syntax as a command: dump {macro_keyword} {-process_group segment_option {...segment_options}} {-control_args} Function: produces a diagnostic dump of system memory and tables after a hardware or software failure, for later analysis. The dump is produced by copying binary images of segments and directories into the DUMP partition of the disk described by the part dump config card. Arguments to the dump command specify which processes are to be examined and which segments from those processes are to be dumped. (See "Notes" for a general purpose command line.) This command is valid at all BCE command levels. Arguments: macro_keyword specifies one of the following default group of processes and segments to dump. -brief, -bf is equivalent to -run hc pp moddir. -long, -lg is equivalent to -all wrt. -standard, -std is equivalent to -run hc pp moddir -elig hc stk -inzr hc stk. process_group specifies a group of processes to be considered for dumping. The segments that get dumped for processes in this group are specified by segment options that follow the process group keyword. Allowed groups are: -all all processes -eligible, -elig all running and eligible processes (processes being considered for running) -initializer, -inzr the initializer process (first apte entry) -running, -run processes running on a processor (apte.state = running or stopped) segment_option specifies a class of segments to be dumped for the group of processes specified by the process group keyword. Segment classes are: directories, dir directory segments (aste.dirsw = "1"b) hardcore, hc the pds, kst, dseg and ring 0 stack for the process(es). If a process is running, this also dumps the prds for the processor in question. modifying_dirs, moddir directory segments (aste.dirsw = "1"b) which were being modified at the time of the crash (dir.modify ^= "0"b) per_process, pp the segments contained within the process directory of the process(es) (aste.per_process = "1"b) stacks, stk all stack segments in the process(es) not already dumped by the hc or pp keywords. writeable, wrt all segments to which the process(es) have write access. This keyword produces a very large dump. Writable ring zero segments (system data bases) other than directories are dumped regardless of what keywords are specified. Prefixing a segment option with a circumflex (^) reverts an earlier occurence of the given segment option. Thus, you can turn on a macro_keyword and turn off a specific segment option within it. Control arguments: -bce dumps BCE itself (the dumper). -crash specifies that BCE is to dump the saved Multics image. -drive, -dv drive_name places the dump into the dump partition of the specified drive instead of the drive listed on the PART DUMP card. -dump # changes the dump number to a desired value. By default, dumps are assigned numbers sequentially. -force, -fc places the dump into the DUMP partition without querying you first, even if this means that an existing dump which hasn't been copied will be overwritten. If this control argument is not used, the dump command asks you if the existing dump should really be overwritten before it overwrites it. -no_sstnt disables sst_names_ generation. If sst_names_ generation is enabled for the system ( by the astk parm in the config deck), this control argument has no effect. -sstnt causes the segment sst_names_ (the sst name table) to be filled in and included in the dump. The segment sst_names_ provides a name for each ASTE in the system. This information is of use to dump analysis programs. If sst_names_ generation is enabled for the system (by the astk parm in the config deck), this control argument has no effect. This is the default. Notes: For general purpose dump analysis, the command line dump -std which is equivalent to dump -run hc pp moddir -elig hc stk -inzr hc stk should give the user all of the useful processes and segments (to produce a smaller dump, remove the "moddir" keyword). For simplicity, and to remove the possibility of operator error, this command line should be placed into a BCE exec_com, either by itself or in a site supplied crash exec_com. The dump command examines the active process table entries (apte) within the specified image. For each entry, the criteria specified through the keywords are used to decide if any segments from this process are to be dumped. If any segments are to be dumped, the segment options are applied to each segment active within that process to decide whether or not they should be dumped. As each process is dumped, the dump command will produce an output line showing the apte number and the dbr value for the process. After scanning all apte entries, if the process in control when Multics crashed was not one of the processes dumped, it is dumped with a status line showing an apte number of zero. This process is dumped with the running and initializer segment options. A counter and a valid flag are kept within the DUMP partition. When a dump is placed into the partition, the valid flag is set. It is reset when the dump is copied out during Multics service (by the copy_dump exec command). If the dump in the partition has not been copied, the dump command will ask you if it should be overwritten. You can avoid this query by specifying the -force (-fc) control argument. The dump command provides a severity indicator, indicating the successful of its operation. This indicator may be obtained with the severity command/active function. The interpretation of the severity status is: 3 - the dump request was never called. 2 - the dump request was entered, but never completed. 1 - the dump was aborted because the DUMP partition contains an older dump. 0 - the dump was successfully generated. ----------------------------------------------------------- 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