RRRRRR OOOOO SSSSS RR RR OOO OOO SS SS RR RR OO OO SS RR RR OO OO SS RRRRRR OO OO SSSSS RRRR OO OO SS RR RR OO OO SS RR RR OOO OOO SS SS RR RR OOOOO SSSSS S Y S T E M O P E R A T I O N M A N U A L System Operation Manual for Remote Operating System (ROS) Version 3.4 October 19, 1985 Albuquerque RCP/M (505)299-5974 Steve Fox - Sysop ROS.PAS and the associated support files (including this documentation file) are Copyright (c) 1985 by Steven Fox. Non-commercial, public distribution and use of this system is permitted. All commercial rights are reserved. Distribution of ROS should include this documentation. HISTORY AND ACKNOWLEDGEMENTS The original SJBBS, written in Xitan Basic by Howard Moulton, was adapted to MBasic by Bruce R. Ratoff. Modifications to this system were made by Bruce Ratoff, James Underwood, Ron Fowler, Brett Berg, and many, many others. James Whorton and Eddie H. Curlin converted the RBBS to Turbo Pascal (copyright Borland International) in 1984 and called the system TPBBS. ROS version 1.0 (originally released as TBBS23 but changed to ROS to avoid confusion with TPBBS with which it shares no code or structure) was written using ideas gathered from these systems and from others operating on a wide variety of computers. Version 2.0 of ROS was revised to include indexed file support using B+ trees provided by Turbo Toolbox (copyright Borland International). Version 3.0 eliminated the need for support from programs such as BYE, XMODEM, and SD by incorporating these functions internally. This system would not have been possible were it not for the work of these individuals dedicated to making the concept of public access telecommunications work. PURPOSE OF THE SYSTEM ROS was designed as a traditional bulletin board system with private messaging capability. Messages left to all users are 'public' and readable by anyone on the system. Messages left to a single user are 'private' and cannot be read by anyone but the sender and the receiver unless explicitly marked as 'public' by the sender. The sysop can, of course, read all messages at any time. ROS can be configured as an 'open' system in which new users are allowed full access, or it can be set up such that they must be 'validated' by the sysop. If the system is set up 'closed', unvalidated users cannot enter messages to anyone but the sysop. A password, selected by the user when first logging into the system, is required for all future accesses. MINIMUM SYSTEM ROS is designed to operate on a Z-80 computer with 48K of TPA (transient program area) operating under CP/M 2.2. No external support routines such as BYE are required nor is ZCPR necessary since ROS maintains its own access protection. Turbo Pascal ver. 2.0 or later and Borland's Turbo Toolbox are required to compile the system. A real time clock is strongly recommended, but not absolutely necessary. In addition to CP/M 2.2, ROS is also known to operate under CP/M+ (CP/M-80 3.0) and TurboDOS. Modified versions are also in opera- tion under MSDOS, CP/M-86, and CCP/M. STRUCTURE The following shows the design structure of the ROS resident and overlayed code: MAIN OVERLAY .001 OVERLAY .000 RESIDENT CODE Within each overlay, no procedure or function can call another (restriction of Turbo Pascal), but each layer can call any rou- tine in the next lower layer. It would be technically simple to cause most of the MAIN code to be overlayed, but this would slow the system somewhat and would recover very little memory. The size of each overlay then is dictated by the hierarchical design rather than convenience, since what is in an overlay is a result of function. No additional memory would be gained by changing the size of the overlay files, in fact, what would change is the speed of processing - some operations would speed up, others would slow down. ROS.COM consists of the following components which make up the resident portion of ROS: Run time package / Resident data / / Toolbox / / / Device drivers (machine dependent) / / / / Resident kernel / / / / / Overlay space (.000 and .001) / / / / / / Main / / / / / / / |-------|-------|---|-|--|--|-| (Each line segment represents about 1k) Of these sections, the run time package, the resident data, and the device drivers MUST be present in memory. The toolbox and the resident kernel could be overlayed, but doing so would SIGNIFICANTLY slow down the system operation. Only part of the MAIN could be overlayed. The rest must remain in memory. FILES The following files are included in the ROS library: ROS.PAS Remote Operating System main program ROSDEF.INC Constant and variable definitions ROSFIL.INC File sub-system ROSINI.INC System initialization routines ROSKIO.INC Kernel I/O routines ROSKMS.INC Kernel miscellaneous routines ROSKOV.INC Overlayed portion of kernel ROSMAIN.INC Resident "main-line" code ROSMSG.INC Message sub-system ROSRCV.INC File receive routines ROSSND.INC File send routines ROSSYM.INC Sysop sub-system - miscellaneous routines ROSSYU.INC Sysop sub-system - user file routines ROSSYP.INC Sysop sub-system - purge file routines ROSSYX.INC Sysop sub-system - extended utilities ROSUTL.INC Utility sub-system SYSMSG.TXT Sample message file SECTION.BB# Sample section file ROS2-30.PAS ROS ver. 2.x to ver. 3.0 conversion utility ROS31-32.PAS ROS ver. 3.1 to ver. 3.2 conversion utility ROS33-34.PAS ROS ver. 3.3 to ver. 3.4 conversion utility ROSOPS.DOC System Operations Manual (this document) ROSUSR.DOC User's Guide ROS34.NOT Release specific notes ROSMAC.LBR contains the machine dependent routines for several machines. These routines are also written in Turbo Pascal and should be readily modified to suit virtually any machine. To ease the installation process, the system dependent code is split into three files: ROS.MCH Machine (computer) dependent code ROS.MDM Modem drivers ROS.CLK Clock drivers In addition, the following Turbo Toolbox files will be needed to compile the system (these are available from Borland): ACCESS.BOX ADDKEY.BOX DELKEY.BOX GETKEY.BOX SYSTEM INSTALLATION The following steps should be taken to install ROS for your system: 1) Modify and install the machine dependent routines 2) Define and install the system defaults 3) Edit Toolbox Files (optional step) 4) Compile ROS 5) Edit the system message and section files 6) Run ROS to create other sytem files and login as 'SYSOP' These steps are amplified in the following sections. Modify and install the machine dependent routines Select the files from ROSMAC.LBR which most closely match your system. These files provide ROS with the specific information necessary for the interface with your particular hardware. They are the only files requiring extensive modification (ROSDEF.INC and ROSINI.INC will need some minor changes). The following routines should be included in the named files: NAME OPERATION ROS.MCH system_init Initialization to be done once when ROS first starts system_de_init De-initialization to be done once when ROS terminates putstat Display 'st' on status line ch_init Initialize the remote channel ch_on Turn on remote channel (usually by enabling DTR) ch_off Turn on remote channel (usually by disabling DTR) ch_carck Check to see if carrier is present ch_inprdy Check for ready to input from port ch_inp Input a byte from port - no wait - assumed ready ch_out Output a byte to port - wait until ready ch_set Set the bps rate of the channel (not the modem) ROS.MDM mdresult Get result code from modem (optional - see below) mdsend Send a command string to the modem (optional) mdhangup Hangup modem mdbusy Take modem off hook to present a busy signal mdring Determine if the phone is ringing mdans Detect and set system to rate at which modem answered mdinit Ensure the modem is hung up, initialized, and ready to wait for a ring. NOTE: mdresult and mdsend are only used by other routines in ROS.MDM and may not be required in all systems. ROS.CLK GetTAD Return a 6 element byte array of the current system time in seconds, minutes, hours, day, month, and year. SetTAD Set the system time using a 6 element byte array which contains seconds, minutes, hours, day, month, and year. The following is a more detailed description of each routine: procedure system_init; This procedure is called only once during the initial start-up of ROS. It may be used to set any necessary system parameters (or none at all). Examples of useful things to be done here: Set VT-180 scrolling region to enable a status-line Send one-time commands to modem Set function keys procedure system_de_init; This procedure is called once just before ROS is terminated. The procedure may be used to reset any parameters desired. For example, commands performed during the previous routine (system_init) may be 'un-done' here. procedure putstat(st: StrStd); This procedure is used to write 'st' to the status line of the local console. If such a line is not readily available, the top or bottom line of the console may be used instead. This proce- dure may freely use any of the screen commands of Turbo Pascal such as LowVideo, HighVideo, ClrEOL, etc. procedure ch_init; This routine should initialize the serial port of the computer (use mdinit to initialize the modem itself). procedure ch_on This procedure turns on the remote channel for use by ROS. Usually this is done by enabling DTR, but you may also need to do such things as enabling the transmitter of the UART. procedure ch_off This procedure turns off the remote channel. Usually this will simply consist of lowering DTR. function ch_carck: boolean; This function is called frequently to determine that the user is still logged in. Usually this is done by requesting the data carrier detect (DCD) status of the UART, but other methods are possible. function ch_inprdy: boolean; This function returns TRUE when a byte is available to be read and a FALSE when none is available. Only the test is performed, the system does not stop to read the byte. function ch_inp: byte; This function returns the byte read from the input port. The system assumes that one is available. All eight bits should be returned to the system. procedure ch_out(b: byte); The system will wait in this routine until the modem is ready to accept data. Notice that the value sent is a BYTE, not a CHARACTER. All eight bits should be sent to the port. procedure ch_set(rate: integer); Set the bps rate of the channel to the value determined by rate. Rate is an ordinary integer such as 300, 1200, etc. function mdresult: Str3; This function returns the result code from the modem. ROS does not directly access this function, but other routines in ROS.MDM may. procedure mdsend(st: StrStd); This procedure sends a command string to the modem. As in mdresult, ROS does not use this routine, but other routines in ROS.MDM may. procedure mdhangup; This prodecure hangs up the modem immediately. This can be accomplished by dropping DTR on some modems or by sending a command such as 'ATH' on the Hayes. procedure mdbusy; This routine is called when local use is requested and when delayed shutdown is used. Its purpose is to take the modem off- hook so remote users will be presented a busy signal. If the modem cannot perform this operation, call mdhangup from here so that the modem will not answer. function mdring: boolean; This routine monitors the modem port to see if a call has been received. This can be done by looking at the ring indicator (if available), looking for an answer signal from a smart modem, or by simply looking for a carrier detect. This function returns a TRUE or FALSE to indicate the call status. procedure mdans; One a call has been received, this routine is called to answer the phone. This can be done by raising DTR on some modems, or by sending a command to a smart modem such as 'ATA'. procedure mdinit; Get the modem ready to talk to ROS. For "intelligent" modems, this is usually done by sending some sort of initialization string. For "dumb" modems, no action may be necessary. procedure GetTAD(var t: tad_array); This procedure returns six values in the tad_array which are the binary representation of seconds, hours, minutes, day, month, and year (in that order). If your machine does not have a real time clock, these values should be set to zero or you can set the date once a day with the sysop utilities. procedure SetTAD(var t: tad_array); Complementary procedure to GetTAD which is used to set the time and date. Define and install the system defaults The following are the system defined default values. These values, set in ROSDEF.INC, may be changed by the SYSOP on an individual basis. 'def_acc' is the default access level assigned to new users to determine what the user can and cannot do on the system. The recommended value is '10'. See the SECURITY section for more information. 'def_time' is the time limit allowed the user until the system will automatically disconnect. 'def_chars' and 'def_lines' are the number of characters-per-line and lines-per-page used by the system until reset by the user. 'val_acc' and 'val_time' will be used by ROS to set the access level and access time allowed for a specific user when the sysop utility 'validate' is used (see description of sysop utilities). 'ChatStart' and 'ChatEnd' are the hours during which the SYSOP may be available for direct communication. 'fence' is used by the directory routine to separate columns during display. 'unv_days' and 'val_days' are the number of days allowed to elapse between calls before the user is purged from the system. For example, 14 and 180 will allow unvalidated users to remain on the system for 14 days between calls and validated users 180 days between calls before being deleted from the user file. 'unr_days' and 'rea_days' are the number of days allowed to elapse before un-read and read messages, respectively, are auto- matically deleted. Public messages are never marked as read and thus will be available until explicitly deleted or until they "expire" as determined by 'unr_days.' 'Max_Tries' defines the number of times ROS will allow a user to attempt password entry. If this number is exceeded, the system will disconnect with a message. 'lps' is the number of I/O loops ROS makes per second. This value is used to time I/O operations such as the length of time to wait for a character during Xmodem transfers and to disconnect callers that have not had any activity in five minutes. This value should be fine tuned for your particular system by logging into the system remotely and timing the amount of time that passes until ROS disconnects with the following message: ++ Input timed out ++ 'BufBlocks' and 'BufSize' may be increased as desired providing there is sufficient memory. Since most CP/M 2.0 and later systems provide disk file buffering, 1 and 128 are usually sufficient. The relationship between the two values should be maintained as 1:128, e.g. if 'BufBlocks' is increased to 4, 'BufSize' should be set to 512. Since this buffer space is statically allocated at compile time, the use of large buffers is discouraged. 'macro' is the default macro that will be used unless altered during execution of the sysop utilities. This initial value of this variable is defined in ROSINI.INC. Edit Toolbox Files (optional step) ROS makes extensive use of overlays to increase the amount of memory available for dynamic allocation. The two Turbo Toolbox files ADDKEY.BOX and DELKEY.BOX can be safely and simply conver- ted into overlays which will increase the amount of usable memory by approximately 2k. Since each file consists of exactly one procedure, insert the word 'overlay' before the word 'procedure' at the beginning of each file (be sure there is a space after 'overlay') and save the edited file. While this step is optional, it is strongly recommended. Neither of the two affected procedures is called frequently, so the disk overhead is minimal and the memory increase is significant. Compile ROS ROS version 3.0 and later do not require any special handling to account for Turbo Pascal's static (compile time) allocation of stack space. The following steps (in Turbo Pascal) create a compiled version of ROS ready for use. These commands will create three files: ROS.COM, ROS.000, and ROS.001 which are the resident portion of ROS and the two overlay files: 1) O - Options 2) C - COM file 3) Q - Quit 4) C - Compile 5) ROS 6) Q - Quit and return to operating system Edit the system message and section files The system message file should be edited for your particular system. A sample file of SYSMSG.TXT in WordStar format is in- cluded as a guideline. ROS can processes SYSMSG.TXT files which have been created by text editors - such as WordStar - which use the high bit. When ROS is started, it attempts to open SYSMSG.BB# which is a random access file. If ROS finds this file it will be used, but if not, ROS will create it from SYSMSG.TXT. When the file SYSMSG.TXT is updated, delete SYSMSG.BB# so ROS will automatically update the random access file as well. The section control file, SECTION.BB#, is used to control access to specific file and message areas. A sample of the section file is shown below, followed by the format: A 15 10 LOGIN Login area A 9 20 ROS ROS file area B 0 20 TPASCAL Turbo Pascal programs and utilities B 1 20 GAMES Adventure, chess, Othello, etc. B 2 20 UTILITY File and system utilities C 1 20 BIGBORD Notes and programs for BigBoard I and II C 2 20 OSBORNE Osborne libraries A 0 250 SYSCOM System command files A 1 250 PASCAL Pascal program development A 14 20 NEWIN ** New uploads ** 0 250 SYSTEM System message area 1 10 POST Trading Post - Buy, Sell, Trade 2 10 Q-A Technical Questions and (hopefully) Answers 3 10 TURBO Turbo Pascal 4 10 BB BigBoard I, II Format: 1 2 3 4 5 6 7 1234567890123456789012345678901234567890123456789012345678901234567890 1 Disk (blank here indicates this is a message section) 2 Blank 3-4 User area or message area 5 Blank 6-8 Access level required 9 Blank 10-18 Section name 19 Blank 20-70 Section description The following four entries are expected by ROS and should be present in the section file: LOGIN This is the file area every user 'sees' initially. The access level of this area should be set to zero. POST This is the message area every user 'sees' initially. The access level of this area should be set to zero. NEWIN This is the file area into which uploads will be placed. The access level of this area is defined by the sysop. SYSTEM Message area 0 is special since ALL messages (including those that have been erased) will be visible. IT IS IMPORTANT that the access level of this area be set high enough that normal users do not have access. To avoid potential problems, use 250 for the access level. NOTE: The SECTION.BB# must NOT have extra lines after the last line of information. To do so invites BDOS erros. In addition, ROS will not process high-order bits in the text of this file, so an editor must be used which does not use these bits. The editor built into Turbo Pascal is ideal for this operation. Run ROS to create other system files and login as 'SYSOP' The system is now ready to be initialized. If ROS cannot find the files needed to run the system, it will create them automati- cally. ROS will announce itself and wait for one of two actions: 1) A signal from the modem indicating a remote user, or 2) a command from the console indicating a local user. Enter a carriage return. After the "FIRST name:" prompt appears, enter the name "SYSOP." Not finding such a user, the system will prompt for a password - enter one of your choice. You are now logged into the system. It is VERY IMPORTANT that you log in as sysop before putting the system up for others to use. There are folks out there that will try to log in as sysop. If you have not set your password, they will set it for you and will consequently have full sysop level access. USING THE SYSTEM ROS expects to find all files in the file area in which it first starts. It is in this area that the user files, the log file, etc. will be maintained. Since ROS provides the sysop with full control over who has access to this area through access level, two methods protect the ROS system files from users: 1. do not include this area in the SECTION.BB# file, or 2. set the access level of this area sufficiently high (such as 250 or higher). In a similar manner, other private areas of the disk system can be protected from users. In the previous extract from the SECTION.BB# file, SYSCOM, which resides on Drive A, User 0, can only be accessed by the sysop. Other users will not even know the area exists. While the system is idling, i.e. waiting for a call, the CRT screen will be cleared and the cursor randomly repositioned every few seconds to eliminate any possibility of phosphor burn. When a user successfully logs in, their name and address will be displayed on the status line. The local console has several commands, entered by control codes, that may be requested while the system is idling and while a user is logged in. Idling commands: ^J (linefeed) Display menu of console commands This command will display the following information on the status line: ^C: Shutdown ROS, : Local use ^C When waiting for a call, entering this command will terminate ROS operation and return control to the operating system. ^M (RETURN) Request local use of ROS. In use commands: ^J (linefeed) Display menu of console commands Entering this command will display the following information on the status line: ^W: CHAT, ^E: Remote copy on/off, ^R: Remote offline - delayed, ^T: Twit ^W Sysop initiated CHAT. The current user is issued a message and the system enters the chat mode. This command bypasses the time of day checks and may be entered at any time (chat hours are restricted to users). ^E 'Blank' remote I/O. Toggle output to remote system. Useful to help a lost user find a file or message. May also be used to validate a remote user since the access level is temporarily set to SYSOP level and then reset when remote I/O is reinstated. ^R 'Delayed' shutdown. When the current user logs out, the modem is made busy and the system rings the bell to indicate that it is available. The funtion is useful on busy systems when the sysop has trouble getting access. Until the operation actually takes place, this key may be used to alternately turn the function on and off. ^T 'Twit' key. Immediately hang up on remote user. The previous command is preferred to gain system access, but sometimes this command is necessary. MAINTENANCE The sysop should use ROS regularly to get messages from new users desiring validation, (if that is the default) then use the sysop utilities to validate them. A check should be made at this time that the messages on the system are appropriate to the philosophy of the system. BEWARE of users leaving messages about credit card numbers, access codes, or other such information. The message file only marks messages as deleted. Consequently, this file should be compressed periodically. A good way to do this is to turn on the printer, print out the log and message files, then turn the printer off and purge the files. This way, a hardcopy record is kept of all activity on the system. This was a conscious design decision which allows the sysop to maintain a history of ALL messages entered on the system. The events surrounding MOGUR demonstrate the need. Sysop Commands The sysop command system is accessed by typing "X" at any func- tion prompt (this option is locked out to users below access level 250). The sysop menu may be displayed by entering "?" (see sample menu below). The user, log, and message files may be displayed on the CRT or printed to the LST device based on the condition of the print toggle. After the sample menu, each command is described in more detail. Sysop System Menu ================== Functions =================== ==== Other Menus ===== udit trail toggle Macro operations ile Transfer System elete user

urge files essage System dit user ead messages tilities System ndex rebuild ystem directory og file list oggle printer ewin file processing alidate user tended commands oodbye (logoff) udit trail toggle A standard ASCII text file can be created from the log and mes- sage files by turning on an audit trail and using the 'L' and 'R' sysop commands. The file created consists of the system date as file name with a numeric extension starting with zero. For example, the first time the audit trail is enabled on the 15th of August 1985, the name would be 08-15-85.000. If the audit trail were turned off and on later in the same day, the file name would be 08-15-85.001. elete user The sysop is asked for a name to be deleted from the user file. ROS prompts to ensure that this is the action desired and if so, deletes the user and any messages addressed from or to that user. dit user The record of the selected user is displayed and the cursor is positioned at the password field. If only a carriage return is entered, the field data will be left unchanged. Because the user name is used as the key to this record, the sysop will not be given the opportunity to change either the first or last name fields. The time of last access is also unchangeable. In all other cases which require the user name, ROS expects an exact match between the characters entered and the name in the file. In this command, ROS is somewhat more forgiving and will find the record which is equal to OR GREATER THAN the entered name. For example, if you cannot remember how John Smith spells his last name, enter 'John Smith' and ROS will find the record even if John spells his last name 'Smithe.' The drawback to this of course, is that it is possible to get the wrong user record if two names are very similar, so be very careful that you have the expected record before editing. ndex rebuild If you suspect that either the user file or its index may be damaged, this command may be used to rebuild the index file and recover from certain types of damage to the user data file. File damage should never occur during normal operation, but power fluctuations and faulty disks and drives can cause problems. During execution of this command, the record number, a linked list element, and the user names are displayed. For more infor- mation about the structure of data files when using the Turbo Toolbox, refer to the Turbo Toolbox Referance Manual (c) Borland International. og file list ROS maintains a time and date stamped list of most system opera- tions. This command will display this list. From the information contained in this file, the sysop can determine what kind of activity the system is being used for, what users seem to be having problems, what users are abusing their privileges, etc. If the audit trail is turned on, the log information will be written to this file. ewin file processing ROS marks all uploads with the system attribute bit to prevent directory display, and stores a one line description of the file. This command allows the sysop to release the file and description for access by normal users, hide the file and description from normal users, delete the description (not the file itself), edit the description. Until the file is purged (see Purge), all entries may be freely edited by the sysop. For example, when a user uploads a file ROS will mark the file as hidden until the sysop has a chance to review the contents of that file. If appropriate, the sysop can release the file for users. At that time, not only will the file be available in the NEWIN section for downloading, but the description entered at upload time can be seen by other users using the Newin command in the files sub-system. In addition to the file name and descrip- tion ROS displays the name of the individual that performed the upload and the time and date the operation was completed. When the file has 'aged' in the NEWIN section sufficiently, the delete command will delete the description and mark the file as hidden once again. Conventional CP/M utilities or extended sysop commands (described later) may then be used to move the file to a more permanent file area and reset the system attribute bit. Macro Operations In addition to being able to read characters from either the keyboard or the remote channel, ROS can read from an internal character string called a macro. This string can be used to execute any sequence of operations as defined by the sysop. For example, the sequence 'TYUUA/XLRPAYT' performs the following operations: Toggle the printer on T Yes, really do it Y Utility sub-system entry U User file listing of ... U No starting name specified / Re-enter the sysop sub-system X List the log file L Read the messages R Purge ... P Yes, really do it Y Toggle the printer back off T This type of operation is typical of that performed during the regular maintenance of the ROS files and can take some time to complete. The ability to perform these operations unattended can be very convenient. Three commands are available to control the macro operation: Display the contents of the macro buffer Edit the macro string (editing commands are desribed in the User's Guide) Start the macro ROS is still monitoring both the local and remote keyboards while processing a macro so the sysop can pause (^S) or cancel (^C) a command, but macro processing will continue until complete. Since a carriage return is used to terminate the entry of a new macro string, a slash (/) may be entered into the macro. When encountered, ROS will convert this character into a carriage return.

urge files This command purges and compresses selected files of deleted entries. It processes four different files, each selectable by a single command, or all four files together. All commands are verified before continuing. Sufficient disk space must be available for these operations or ROS will report an error and terminate. Should this happen, ROS will automatically recover from the old files the next time it is started, but extraneous files may be left on the disk. Purge All - This command purges all four files, i.e. it automatically performs a purge of the log, newin, user, and messages files. Purge Log - This command removes all entries from the log file. Purge Newin - This command removes all entries marked "deleted" in the newin file. Purge Messages - As described in the introduction, deleting a message only marks that message for delete. To physically remove the message from the disk, the message files must be purged. Purge Users - This command deletes all users that have not logged in within the times specified at compile time. When a user is deleted with this command, ROS will also delete any messages sent to or from the user. ead messages All messages currently on file are displayed in numerical order. If the audit trail is on, these messages are also written to that file. ystem directory A directory of all files in sections with access levels of 20 or less is built in the LOGIN section. This directory can be used by remote users to speed file download operations. oggle printer The currently assigned LST device is alternately enabled and disabled. To prevent possible toggling while remote, this com- mand is verified before continuing. alidate user This command allows the sysop to increase the access level and time allowance for the sender of the last read message to values defined at compile time. It is generally much more convenient than editing the user and can be performed from a remote site as well as at the local console. When this command is executed, ROS will display the name of the author of the last read message. If you need to validate another user, respond 'N' to the query and enter the full name of the individual to validate. etended commands This command is only available to the primary sysop, i.e. the individual with an access level of 255. Two sub-commands are available: Copy - This command is used to copy a file from the currently logged file area to another specified file area. When the copy is completed successfully, the system will ask if the source file should be deleted. Delete - This command is used to delete any file from the currently logged file area. Verification is requested before the action takes place. Other commands available to the Sysop ile Transfer System This command causes ROS to exit the sysop sub-system and enter the file transfer sub-system. essage System This command causes ROS to exit the sysop sub-system and enter the message sub-system. tility System This command causes ROS to exit the sysop sub-system and enter the utility sub-system. oodbye (logoff) This command terminates the session. In addition to the specific commands in the sysop system, three other commands have enhanced capabilities for the sysop: In the message system, after reading a message, the sysop will be given the option of altering the message area or status of the message. The options are as follow: Delete - mark message as deleted Individual (private) - mark message as private Move - move message to another message area (the system will issue another prompt for the new area) Public - mark message as publically viewable Read - mark message as having been read In the utility system, after displaying the time and date, ROS will allow the sysop to set these values. When the user list is requested, ROS will allow the sysop to enter one of four parameters: "A" for a list of all users, "E" for a list of users whose access level or time limit is above the norm, "U" for a list of the unvalidated users only, or "Q" for a quick listing like that produced for normal users. SECURITY The security of a computer system is of paramount importance when that system is readily available through the telephone system. To make ROS robust enough to withstand both incorrect entries and malicious attacks against the system, a simple but effective method is used: an access level, ranging from 0 to 255, is assigned to each user with system privileges based upon this number. In general, the higher the number, the greater the privileges the user has. The levels of access are defined as follows: 0-9 Twit - will be logged off immediately 10-19 Unvalidated user - limited message and files access 20-249 Normal user - full message and files access 250-254 Alternate sysops 255 Sysop The concept of alternate sysops, new with version 3.4, allows the sysop to get help in running the system without completely open- ing it up. While all sysops have access to the sysop sub-system, access level 255 is required to use the extended commands. The validate and delete commands will only operate on users of a lower access level. The edit command will operate on users of the same or lower access level. This access level structure allows the primary sysop to affect all user records in the system, including his own, but alternate sysops can neither affect nor view the record of the primary sysop. In addition, since the validate and delete commands only operate on users of a lower access level, the hazard of valida- ting or deleting oneself has been reduced. CAUTION: Since the primary sysop can edit any user record, please exercise care not to lower your own access level! The only known recovery from this action (if there are no other sysops at the 255 level) would be to use a file zap utility such as PATCH.COM. BUGS When used with certain text editors, SYSMSG.TXT will not contain a terminating End-Of-File marker (^Z) if the number of characters in the file is EXACTLY a multiple of 128. Should this happen, ROS will not properly terminate the creation of SYSMSG.BB# and a disk full error will eventually occur. As a work-around, add or delete one or more characters from SYSMSG.TXT, delete SYSMSG.BB#, and restart ROS. This extreme situation obviously does not occur often. If you find any other errors, please leave a message on the Albuquerque RCP/M (505)299-5974. PREVIOUS VERSIONS OF ROS Notes to users of ROS 2.5: Included in the library is a file called ROS2-30.PAS. If you are already running ROS 2.5, this file must be used to update the user file so that it will reflect the changes made in version 3.0. This program operates directly on the USERDAT.BB# file, so if you intend to return to ROS 2.5 for any reason, save the user file first. Notes to users of ROS 3.0 and 3.1: Included in the library is a file called ROS31-32.PAS. This file must be used to update the message summary file to the new format which includes a byte to indicate the message area of the mes- sage. This program operates directly on the SUMMARY.BB# file, so if you intend to return to ROS 3.0 or 3.1 for any reason, save the message summary file first. Notes to users of ROS 3.2 and 3.3: Included in the library is a file called ROS33-34.PAS. This file must be used to update several of the files to new formats. To run the program, enter the Turbo Pascal compiler and type "R" for the run command. The compiler will ask for a file name. Enter "ROS33-34". After the program is compiled, it will convert the old data files into the new formats. The new files will have a ".BB#" file extension and the original files will have a ".BAK" extension. Once satisified that the new files operate correctly, the original files may be deleted. ROS33-34 should only be run once. An attempt to run the program against the new format files will result in error messages, but no other action will be taken.