6/3/84 Enhancements to the Forum subsystem This info segment briefly describes the enhancements made to the Forum subsystem. 7/13/83 List of enhancements in version 2.0: (1) new meeting structure (2) access control and other file system operations (3) managing a meeting directory (4) perusing changed meetings (5) the transaction "seen" map (6) subroutine interface changes New meeting structure: Version 2 Forum meetings, those meetings created with the v2_forum_create command instead of the forum_create command, are implemented as directories with the suffix "forum" instead of as two segments with the suffixes "control" and "proceedings". This removes almost all of the limitations on the size and number of attendees of a meeting. A new command, convert_forum, has been provided to convert a version 1 meeting into a version 2 meeting. Version 2 forum will continue to support unconverted meetings, but those meetings will continue to be subject to size constraints, and will not be able to take advantage of some new features. Access control and other file system operations: Version 2 meetings are Multics "extended objects". This means that if your site has installed the extended object software, meetings may be manipulated with the standard file system commands such as copy, delete, list_acl, and set_acl. Access to meetings is controlled by extended ACL terms. Three modes are defined: read (r), write (w), and chairman (c). To make a meeting publicly readable and to make user Smith a chairman of the meeting, the command set_acl .forum r *.* rwc Smith.* may be used. Similarly, the list_acl command may be used to list the eligibility to a meeting, and the delete_acl command may be used to remove an access term. The switch_on/switch_off command may be used to set the safety switch on a meeting, or to change the value of any other switch accepted by forum, such as "notify". The copy and move commands may be used to move a meeting to another location in the storage system heirarchy, and the delete command may be used to delete a meeting. If your site has not installed the extended object software, you may continue to use the forum access commands (forum_add_participant, forum_make_public etc.) and the forum_delete command on version 2 meetings. The -chairman control argument has been added to allow the access commands to give 'c' access to a meeting. However, privileged access is required to move or copy a meeting. Managing a meeting directory: Two new commands have been provided to assist users in managing the list of meetings that they attend. The forum_add_meeting (fam) command, also available as the add_meeting (am) request, is used to add a meeting to the list of meetings attended. The forum_remove_meeting (frm) command, also available at the remove_meeting (rm) request, will remove a meeting from that list. Version 2 forum also provides a facility for announcing the existence of a meeting. The forum_create command will offer to do this, or the new announce_meeting (anm) request may be used. The announcement consists of a formatted transaction entered in a specified meeting, the default is [forum_dir]>Meeting_Directory, which can be understood by the add_meeting request. If the last transaction in the Meetings_Directory meeting is an announcement of a meeting that you would like to attend, the request add_meeting last will make you a participant of the announced meeting. Perusing changed meetings: Two new requests have been added to simplify the daily perusal of all changed meetings. The check_meetings (ckm) request scans the forum search list and remembers all of the meetings that have changed. The next_meeting (nm) request may then be used to attend each meeting in turn. The transaction "seen" map: In version 2 meetings, forum remembers whether a user has seen each transaction, not just the most recent transaction that has been read. Each transaction may be marked as either seen or unseen. A transaction is marked as seen by the print and write requests, and the seen switch may be explicitly manipulated with the switch_on and switch_off requests. Transactions are also marked as seen by their author when they are entered. Ten new transaction specifiers and requests have been added to utilize the seen switch. They are: seen, first_seen, last_seen, next_seen, previous_seen, unseen, first_unseen, last_unseen, next_unseen, and previous_unseen. Subroutine interface changes: New entries have been added to the forum_ subroutine in order to take advantage of the new features of version 2 meetings. Most important to forum application writers is the changes resulting from the transaction seen map. The forum_$set_last_seen_idx entrypoint may not be used with version 2 meetings. Instead, the forum_$set_seen_switch entry should be called to set or reset the seen switch for a particular transaction. The forum_$get_transaction_map and forum_$get_transaction_map_idx entries may be used to retrieve this information. If these new entrypoints are asked to operate on version 1 meetings, the error code forum_error_table_$old_format will be returned. Some incompatible changes in calling sequences were made, and the old entrypoints were renamed so that both meeting types may be supported by the forum_ gate. The set_v1_forum_acl, list_v1_forum_acl, and v1_expunge entries must be used in place of the set_forum_acl, list_forum_acl, and expunge entries on version 1 meetings. If the version of the meeting is unknown, the following code fragment is recommended: call forum_$list_forum_acl (....); if code ^= 0 then if code = forum_error_table_$old_format then call forum_$list_v1_forum_acl (...); 6/26/83 List of enhancements in version 1.10 (MR10.2): (1) changes to the qedx and ted requests (2) transaction deletion (3) transaction selection (4) formatted output (5) the exec_com request Changes to the qedx and ted requests: The qedx and ted requests, as well as the editor entered by terminating transaction input with \f, have been incompatibly changed to require the use of the write request to save editing changes. The quit request will no longer automatically save all editing changes. If the quit request is issued and the transaction has been modified since it was last written, the editor will now query for permission to exit. If permission is given, any changes made since the last write will be lost. The new quit-force (qf) request may be used to abort unwanted editing of the transaction without being queried. The read (r) and write (w) requests still accept pathnames and may be used to insert a segment into the transaction or make a copy in a segment for later use, respectively. However, when used with a pathname, these requests will no longer change the default pathname for buffer 0 (the transaction). Using either read or write without a pathname will always refer to forum's copy of the transaction. The request line 1,$dr will only restore the original transaction text to the buffer if the write request has not yet been used. If given after a write request, this request line will restore the transaction text as saved by the last write request in the buffer. Transaction deletion: Any participant may now delete a transaction that he has entered. A participant may also retrieve any deleted transactions that he authored provided that they were deleted by him, and not by the chairman. Transaction selection: Many improvements to transaction selection have been made. Transactions may now be selected by date-time. The -after, -after_time, -before, -before_time, -between, -between_time, and -date control arguments allow the selection of transactions entered after, before, or during a specific period of time. The -include_deleted, -only_deleted, and -only_non_deleted control arguments have been added to allow selection of deleted transactions. Only those deleted transactions that were entered by a participant may be selected by participants other than the chairman. A new transaction specifier, highest (last_seen), has been added. The definition of the restref transaction specifier has been changed to not include the current transaction. The -by_chain control argument has been added to sort selected transactions into transaction chains. Type "help trans_specs" from inside forum for a complete description of transaction specifiers. Formatted output: The write request has been upgraded to produce formatted output. The -format and -page_length control arguments were added. This produces page-oriented output consisting of a header line giving the date, meeting name, and page number; a footer line giving the subject of the first transaction on the page; and "fence" lines separating the header and footer from the transaction text. A single transaction will not be split across a page boundary unless it is longer than a page. The exec_com request: Forum is now able to execute a segment containing forum requests through the use of the exec_com (ec) request. A forum exec_com is just like a Multics exec_com file except that it contains forum request lines instead of Multics command lines. Also, these segments must have the ".fmec" suffix on their names. Forum will also look for a "start_up.fmec" segment in the user's homedir, project directory, and >site. The -no_start_up (-nsu) control argument was added to suppress this feature. ----------------------------------------------------------- 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