MULTICS ADMINISTRATIVE BULLETIN MAB-032 Rev. 1 To: MAB Distribution From: Paul W. Benjamin Date: 04/26/83 Subject: The Experimental Library PURPOSE To define policy and procedure governing the experimental library. This document supercedes and replaces MAB-032, which was written in 1976 by Steve Webber. Much of the information in that document is outdated and the information that is not outdated has become suspect by association. As of this writing, the only rule governing EXL is that there are no rules. This document is being written in hopes of correcting that situation. NATURE OF THE LIBRARY The purpose of the library is twofold. It is for the exposure of new versions of existing software, changes that are destined for installation in standard libraries and are made available in hopes of finding errors prior to such installation. It is also for experimental software, i.e. new products or new features in existing products that are being "tried out" in some fashion. Such software is often subject to drastic change and even deletion. There has been discussion on the need for 2 separate libraries, >experimental and >exposure, the rationale being that users could include >exposure in their search rules, taking advantage of bugfixes, while avoiding the more volatile software in >exl. The main problem with that proposal is that experimental enhancements and bugfixes often coexist in the same body of software, perhaps the same bound segment or even the same module therein. Trying to maintain two distinct versions, one for bugfixes and one for experimentation would present a nightmare in configuration management. Further, there is not always a clear distinction between "new feature" and "bugfix". A modest enhancement in response to a TR System suggestion would fall somewhere in the middle. ATTRIBUTES With the dual nature of the library in mind, it is useful to call upon a portion of Mr. Webber's description, altered where appropriate, of the attributes of software in the library: 1. The programs will not be needed in any way to generate or run the standard system. 2. The programs will be documented by online info segs and, where available and appropriate, online MPM documentation. 3. The programs will not be formally supported. However, users will be encouraged to use those that are preliminary versions of software to be formally released at a later date. The TR System may be used to report bugs or make suggestions. 4. The programs might exist only in the transient state from one Multics release to another. They are not distributed to customer sites except by special agreement (e.g., Beta Test Site or RPQ agreements). STRUCTURE The library exists as a directory off the root, >experimental, with added names EXL, experimental_library, exl and x. The EXL library will be maintained on both System-M and the MIT-Multics. Those sites shall grant appropriate access to members of the Multics project to maintain the libraries. These individuals will, in turn, grant sma access for the sub-hierarchies to the appropriate developers. Each item in the EXL library has a primary site (the site at which it is first installed) and a secondary site. In describing a standardization of the structure of the library, it should be understood that there are existing sub-hierarchies within the library that do not conform. It is recommended that existing libraries be altered to conform to the standard structure, but this is not a requirement. It is required that any new directories conform to the standard. Under the directory >exl, there are 3 standard directories: >exl>include i incl >exl>info >exl>execution e executable x ex object o O and multiple software-specific directories. Note that this is an alteration of the structure as of this writing. There is much confusion vis-a-vis directories named object, executable and bound_components. The intent here is to conform to the directory structure used in >ldd>hard. The names object, O and o are added to executable for compatibility with the existing structure. The 3 standard directories should contain nothing but links into the appropriate location in the software-specific directories. The software-specific directories should have a primary name of the form product_dir, (examples: forum_dir, probe_dir, ted_dir). Added names are at the discretion of the responsible developer (3 character names terminating with the letter d such as pld for pl1_dir or emd for emacs_dir are quite common). The only restriction is that the name must not be the name of an executable entry, i.e. fdoc would not be an appropriate added name for >exl>fdoc_dir. These sub-hierarchies should have the following directories: >exl>product_dir>source (s, S) >exl>product_dir>execution (e, executable, x, ex) >exl>product_dir>object (o, O) >exl>product_dir>info >exl>product_dir>include (incl, i) The source directory should contain source archives. The execution directory should contain executable code. There should be links in >exl>e (with appropriate added names) that point to this code. A developer requiring such links should make arrangement with one of the site-specified individuals with access to do so. The object directory should contain object archives (the archives themselves containing object and bindfiles). The info and include directories should contain info segs and include files, respectively, with appropriate links in >exl>info and >exl>include. This is not to preclude the existence of other directories in sub-hierarchies, but it should be noted that space is limited in >exl and it should not be used a repository for whatever the developer happens to need stored. The directories should be structured so that users can alter their search rules or search paths to use them. Object directories, for example, should contain only executable code and exec_coms. Include files should not be archived, in order to allow the user to include the directory in translator search paths. INSTALLATIONS AND MCRS The installation of new versions of software that already exists in the EXL library is the responsibility of the developer. The only guideline is that some method (update_seg, for example) be used to avoid problems with users that already have the about-to-be-replaced version initiated. In general, executable code should have an ACLE of re * and source archives, object archives, include files and info segs should all have ACLEs of r *. All such segments should have ring brackets of 4,5,5, again, unless there is specific reason not to do so. To add a new directory to the library, the procedure differs with the nature of what is being installed. If a version of the software in question exists in a standard library, then no special procedures are required. One need only ask someone with the correct access to create a directory for them and then follow the rules of this MAB in setting up the directory. If, however, the software is new and does not exist in a productized form, it shall require an approved MCR prior to the creation of the directory. The subject of the MCR could either be to install the product in a system library or simply to create the EXL directory. To paraphrase, it would not require an MCR to create an alm_dir, but it would require an MCR to create a qbe_dir. In addition, a forum meeting (>udd>m>meetings>EXL_Library (exl)) shall be established. Developers will be encouraged to enter information relevant to new directories and new or changed or deleted software in this meeting. COPYRIGHTS All software in the EXL library should have appropriate copyrights. It is the responsibility of the developer to see that this is done. The add_pnotice command is the appropriate means of copyrighting software. The developer should be familiar with the content of MAB-052, Standards for Software Protection and Software Technical Identifiers. CARRYING SOFTWARE TO THE SECONDARY SITE The following information has been contributed by Charles Hornig: It is possible to have EXL software transferred to the secondary site automatically. To have this done, you should send a list of the directories you wish carried to the current EXL Carrymeister. The EXL Carrymeister is the CISL developer who is currently responsible for the Carry procedures. As of this writing that individual is Charles Hornig, but the resonsibility changes periodically. The list of directories should be divided into those which can be carried in place (like include and info directories) and those which must be installed specially (executable). You should also indicate which of System-M or MIT is the primary site for the software. The directories will be added to the list of those carried. The carries themselves are done on Sunday morning. Any segments in the directories listed which has had its contents modified since the last carry will be transferred to the secondary site via IMFT. Those which need special installation are transferred to a holding directory and installed in their proper places on Monday morning. Segments with an exclamation point ("!") in any of their names will not be carried. This can be used to protect site-specific segments, as well as old versions made by update_seg. Please use this convention to cut down on congestion on the IMFT link. The following are suggestions on how to keep the Carrymeister happy. Don't ask for all your directores to be carried. If you don't need source and object archives at the secondary site, don't have them carried. IMFT is pretty slow sometimes. Don't move names from one bound segment to another. The update_seg is used to install the special segments, and this can make it unhappy. This means that the EXL Carrymeister has to go in and fix it up by hand. Keep your directories clean. Don't make the EXL Carrymeister spend a lot of time carrying .list segments you left in the source directory.