12/03/86 deckfile_manager, dfm Syntax as a command: dfm {-control_args} Function: This command invokes the Deck File Manager subsystem utility environment. Once invoked, the user is placed in a subsystem, which accepts deckfile_manager requests. See "List of Requests" below. These requests are designed to assist the user in creating and maintaining a tandd_deck_file and creating its associated deckfile.list. Arguments: none Control arguments: -abbrev, -ab specifies that abbreviation processing should be done by the deckfile_manager request processor. If the -profile argument is not given, the user's default profile segment (>udd>Project_id>Person_id>Person_id.profile) is used. -deckfile DECKFILE_PATH, -df DECKFILE_PATH specifies that the DECKFILE_PATH is the target deckfile to be used for all requests. -no_abbrev, -nab specifies that abbreviation processing is not to be done by the deckfile_manager request processor. (Default) -no_prompt does not prompt in the request loop. -no_start_up, -nsu does not execute the start_up exec_com. -profile PROFILE_PATH, -pf PROFILE_PATH specifies that abbreviation processing is to be done using the profile named PROFILE_PATH. If this control argument is given, the -abbrev argument need not be given. -prompt PROMPT_STRING sets the request loop prompt to PROMPT_STRING. (Default is "dfm:") -quit tells deckfile_manager to process the initial request line and then return without entering the request loop (even if the initial request line is aborted). -ready_off -rdf Disables printing ready messages after each request line. (Default) -ready_on Enables printing a ready message after each request line. -request string, -rq string executes the requests in string before entering the request loop. -request_loop, -rql enters the deckfile_manager request_loop. (Default) -start_up, -su executes a start_up.dfmec exec_com. See Notes on start_up below. (Default) Notes on the deckfile: As files are read from either the IFAD or 6670 Binary Deck tape, or the MCA Diskettes all modules that are applicable to Multics are written into the deckfile and all firmware modules into individual segments. Each module that is read is written to the deckfile unchanged. Each object deck occupies one record of the keyed sequential deckfile. The record search key is formed from information obtained from the deck name and revision. If the deckfile already exists in the specified directory, it is updated with the new modules read. If the record for which the record search key already exists, the file is rewritten with the contents of the new record, leaving records in the file that do not have a corresponding entry read unchanged. Catalog records are built for all files while the respective files are being read. These catalog records are merely a list of all of the search keys associated with each individual file. Each catalog record is written to the deckfile immediately following each file, and have record search keys in the form: cata..list - for a list catalog or cata.itr... - for an ITR catalog or cata.mdr.. - for an MDR catalog where: is the name of recording media, ie. mca for mca diskettes, fnp for 6670 Binary Deck Tape, or ifd for ifad. is the name taken from the ident pseudo-op card image is the name of the generic peripheral group and can be either tape, disk, print, or card is the revision of the mpc firmware in this file. For the urcmpc itr/firmware file, it is the revision of the common mpc firmware. Notes on deckfile_path: If the -deckfile argument is given, deckfile_manager will use the path given as the default target path for all request during this session. Notes on requests: Request lines use () for iteration, "" for quoting, and [] to invoke active requests (listed below under "List of Active Requests"). Any request line that begins with ".." is passed directly to the Multics command processor with the leading ".." stripped off. Consequently, any reference to an active function is evaluated by the Multics command processor. The "execute" (e) deckfile_manager request can also make use of active strings via the square brackets ([]). Notes on start_up: If the -no_start_up control argument is not given, deckfile_manager will search for and execute an exec_com file of deckfile_manager requests. It will look for a segment named "start_up.dfmec" in the home directory, project directory, and >site in that order. The start_up will be executed before executing the initial request line. LIST OF REQUESTS Listed below are the available requests that you can use once in the deckfile_manager subsystem. ? lists the available deckfile_manager requests. . identifies deckfile_manager with version number. abbrev {-control_args}, ab {-control_args} turns abbreviation processing on or off and changes profile segments. answer STR {-control_args} request_line supplies an answer to a question asked by a request. STR is the desired answer to the question and request_line is the deckfile_manager request line. delete_deck, dd deletes a deck in a tandd_deck_file do {request_line} {args}, do {-control_args} substitutes args into the request_line and passes the result to the deckfile_manager request processor. Control arguments can be -nogo to suppress execution or -long (-lg) to display expanded line before execution. exec_com PATH STRs, ec PATH STRs executes an exec_com segment containing deckfile_manager requests where PATH is the pathname of the exec_com segment (the ".dfmec" suffix is assumed) and STRs are arguments to be passed to the program. execute STRs, e STRs executes STRs as a Multics command line. As an active request, returns the result of evaluating strings as an Multics active string. help {STR} prints information about request names or topics. A list of available topics is produced by the list_help request. if EXPR -then LINE1 {-else LINE2} conditionally executes one of two request lines depending on the value of an active string. EXPR is the active string that must evaluate to either "true" or "false". LINE1 is the deckfile_manager request line to execute if EXPR evaluates to "true". LINE2 is the deckfile_manager request line to execute if EXPR evaluates to "false". list {KEY} {-control_args}, ls {KEY} {-control_args} creates a deckfile.list segment from the tandd_deckfile_segment. list_help {topics}, lh {topics} prints a list of available info segments whose names include a topic string. list_requests {-control_args}, lr {-control_args} prints information about deckfile_manager requests. list_diskette_types, ldt lists the valid diskette types allowed by the load_from_diskette request. load_from_diskettes, lfd catalog and load MCA diskettes into a tandd_deck_file load_from_tape catalog and load an IFAD or DN6670 Binary Deck Tape into a tandd_deck_file merge_deckfiles, md merge existing tandd_deck_files. patch_deck, pd add or remove $patch cards in a deck. quit {-control_arg}, q {-control_arg} exits deckfile_manager. ready Prints a ready message. ready_off Disables printing a ready message after each request. ready_on Enables printing a ready message after each request. subsystem_name prints the name of the subsystem ("deckfile_manager"). subsystem_version prints the current version of deckfile_manager. List of active requests: [do {request_string} {args}] returns expanded request string. [exec_com PATH STRs], [ec PATH STRs] executes an exec_com segment containing forum requests. [execute STRs], [e STRs] invokes Multics active function within forum request line. [if EXPR -then STR1 {-else STR2}] returns one of two character strings to the Forum request processor depending on the value of EXPR. EXPR is the active string that must evaluate to either "true" or "false". STR1 is returned if EXPR evaluates to "true". STR2 is returned if EXPR evaluates to "false". [subsystem_name] returns the name of the subsystem ("dfm"). [subsystem_version] returns the current version of deckfile_manager. ----------------------------------------------------------- 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