SCCS SCCS, the Source Code Control System, provides a unified and consistent technique for managing source code (ASCII text) and the corrections, enhancements, and modifications thereto. The fun- damental unit upon which SCCS operates is the MODULE which may be of any size although good coding practice suggests that MODULEs should be unifunctional and hence, compact. In our development system, a MODULE is a file and a file resides in a directory, the User File Directory or UFD. As a MODULE evolves, corrections and/or additions (changes) to the source code of the original MODULE accumulate as a function of time. Those changes to a MODULE that arise at any one point in time (a single editing session) are collectively referred to as a CORRECTION SET or DELTA. A COR- RECTION SET is a file of differences. A CORRECTION SET when applied to the original MODULE(file) takes the original source code to the current(most recent) version of the source code. A collection of these CORRECTION SETs therefore represents the evolutionary history of the MODULE with which they(the CORRECTION SETs) are associated. It also follows that if one preserves the original MODULE(file) and all of the CORRECTION SETs(files) that apply to it, it is possible to regenerate the source code for a MODULE at any level of correction/modification. SCCS in our development system is implemented as an interactive indirect command file. SCCS may be invoked at a terminal by typing: @[3,1]SCCS in response to the MCR prompt. SCCS will then identify its presence and ask whether the user desires long dialog. If long dialog is sel- ected the questions asked will be somewhat verbose and where approp- riate, preceded by explanatory text. SCCS may be executed in any of four(4) operating modes: 1)EDIT MODE -generates CORRECTION SETs with initialed and dated audit trails and then applies the COR- RECTION SET to generate the most recent ver- sion of the MODULE. 2)RESTORE MODE -regenerates the source code for a MODULE at any level of correction/modification using the original MODULE and the appropriate COR- RECTION SETs as input. 3)FREEZE MODE -enables the user to apply some or all of the CORRECTION SETs for a MODULE in a permanent manner such that a "new" original MODULE is generated by applying one or more of the COR- RECTION SETs. Those CORRECTION SETs which were applied are then deleted and any remaining COR- RECTION SETs are resequenced. 4)DCN MODE -enables the user to declare that one or more of the CORRECTION SETs for a MODULE are to be col- lectively referred to as a DCN (Design Change Notice) for documentation purposes. Neither the original MODULE nor any of its CORRECTION SETs are disturbed. The DCN file for a MODULE is thus a collection of CORRECTION SETs for a given MODULE. The audit trail for this DCN file incor- porates the DCN document number for identification purposes. DCN files, unlike CORRECTION SETs, cross module boundaries. Thus, in all but the trivial case of a DCN associated with a single MODULE, the DCN file will contain corrections to a series of MODULEs and the DCN file for a single MODULE will be an integral part thereof and have no distinct existence. SCCS produces a document on the line printer which details the module(s) and cor- rection set(s) incorporated in the DCN. SCCS has a great deal of built in flexibility. The user may escape from SCCS EDIT mode by typing CTRL/Z or in response to any question. This stops the SCCS process in its tracks and no modifications will be made. When SCCS prompts for MODE (above), the user may respond with the single first letter of the desired MODE, or the three letter mnemonic for the desired MODE (EDI, RST, FRZ), or the full name of the desired MODE (EDIT, RESTORE, FREEZE, or DCN). The month of the year may be input either as the full name of the month or the three letter standard abbreviation. When SCCS prompts for MODULE name, enter only the filename of the MODULE, not the device, or UIC string, or the filetype. When responding to the audit trail question in EDIT mode, keep in mind that the question refers to the appearance of the audit trail in the updated MODULE. The audit trail is always present in the CORRECTION SET. The user should never request an audit trail in FORTRAN source code or any source code which does not identify a comment as beginning with ";" or in ASCII text whose readability would be adversely affected by the appearance of the audit trail. SCCS utilizes either of the two DEC RSX editors, EDI or EDT, at the user option. CORRECTION SETs as files are identified by the file extension .COR. They will always be contiguous in version number: 1,2.... They have the pro- tection code [R,R,R,R]. The original version of a MODULE always has a version number of 1 and the protection code [R,R,R,R]. The latest version of a MODULE always has a version number of 2 with standard protection since it can be regenerated at will. No other version numbers are tolerated. RESTOREd versions of a module are identified by the extension .RST. DCN files are identified by the extension .DCN. SCCS uses several file extensions for its internal manipulations. These extensions are to be con- sidered reserved. They are: .COR .MOD .CHG .TMP .SAV .RST .HDR .FIX .DCN The user should never create or manipulate any files in his directory with these extensions if SCCS controls any files in that directory. Doing so will lead to unpredictable results. RULES AND REGULATIONS (DO'S AND DON'TS) a) The user must create or copy the original version of a module in(to) his directory before invoking SCCS. This MODULE (file) must have a version number of 1. b) The user should never edit a MODULE independently of SCCS if that MODULE is controlled by SCCS. c) The user should never edit a CORRECTION SET either independently or under the control of SCCS. APG 1/24/79 a.k.a. 79-04-04