RRRRRR OOOOO SSSSS 33333 33333 RR RR OOO OOO SS SS 33 33 33 33 RR RR OO OO SS 33 33 RR RR OO OO SS 33 33 RRRRRR OO OO SSSSS 333 333 RRRR OO OO SS 33 33 RR RR OO OO SS 33 33 RR RR OOO OOO SS SS 33 33 33 33 RR RR OOOOO SSSSS 33333 ** 33333 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.3 August 25, 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. ROS v3.3 System Operation Manual page 3 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, but messages left to a single user are 'private' and cannot be read by anyone but the sender and the receiver. 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. ROS is also known to operate under CP/M+ (CP/M-80 3.0) and TurboDOS. Modified versions are also in operation under MSDOS and CP/M-86. ROS v3.3 System Operation Manual page 4 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 routine in the next lower layer. It would be technically simple to cause most, if not all, of the MAIN code to be overlayed, but this would slow the system somewhat and would gain very little memory (see below). 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. ROS v3.3 System Operation Manual page 5 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 ROSUTL.INC Utility sub-system SYSMSG.TXT Sample message file SECTION.BB# Sample section file ROS2TO3.PAS ROS ver. 2.x to ver. 3.0 conversion utility ROS3132.PAS ROS ver. 3.1 to ver. 3.2 conversion utility ROSOPS.DOC System Operations Manual ROSUSR.DOC User's Guide ROS33.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 has been 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 ROS v3.3 System Operation Manual page 6 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. ROS v3.3 System Operation Manual page 7 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 not used by ROS directly, but by other routines in ROSMDM.INC 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. ROS v3.3 System Operation Manual page 8 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 procedure 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. ROS v3.3 System Operation Manual page 9 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 ROSMDM.INC 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 ROSMDM.INC 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. ROS v3.3 System Operation Manual page 10 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. Note that 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 'ATS0=1' for the Hayes. 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. ROS v3.3 System Operation Manual page 11 Define and install the system defaults The following are the system defined default values assigned new users. Upon validation, these values may be changed by the SYSOP on an individual basis. These values are set in ROSDEF.INC. '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'. 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-99 Normal user - full message and files access 100-254 Special users 255 Sysop 'def_time' is the time limit allowed the user until the system will automatically disconnect. '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. 'columns' and 'fence' are used by the directory routine 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. '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. 'DispLines' is the number of lines which ROS will display before pausing. '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 ++ ROS v3.3 System Operation Manual page 12 '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. 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 converted 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 to be moved to the system disk for use: 1) O - Options 2) C - COM file 3) Q - Quit 4) C - Compile 5) ROS 6) Q - Quit and return to operating system 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. ROS v3.3 System Operation Manual page 13 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 included as a guideline. With release 3.3, ROS correctly 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 0 20 MSDOS MS/PC DOS files C 1 20 BIGBORD Notes and programs for BigBoard I and II C 2 20 OSBORNE Osborne libraries A 0 255 SYSCOM System command files A 1 255 PASCAL Pascal program development A 14 20 NEWIN ** New uploads ** 0 255 SYSTEM System message area 1 10 POST Trading Post - Buy, Sell, Trade 2 20 Q-A Technical Questions and (hopefully) Answers 3 20 TURBO Turbo Pascal 4 20 BB BigBoard I, II 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 ROS v3.3 System Operation Manual page 14 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 255 for the access level. Run ROS to create other sytem 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 automatically. 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. NOTE: It is 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! ROS v3.3 System Operation Manual page 15 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 will 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 255). 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. ROS v3.3 System Operation Manual page 16 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. Useful on busy systems when the sysop has trouble getting access. ^T 'Twit' key. Immediately hang up on remote user. The previous command is preferred to gain system access, but sometimes this command is necessary. ROS v3.3 System Operation Manual page 17 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 system should be purged periodically. A good way to do this is to turn on the printer, print out the users, callers, and messages, then turn the printer off and 'krunch' the message files. This way, a hardcopy record is kept of all activity on the system. The caller file may be reset after printing. Note that the message file only marks messages as deleted and that it is up to the sysop to compress the files. 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 function prompt (this option is locked out to users below access level 255). 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. Sample Sysop Menu: Albuquerque RCP/M - Sysop System Menu ================== Functions =================== ==== Other Menus ===== udit trail toggle ewin file processing ile Transfer System hange message area

urge user file essage System elete user ead messages tilities System dit user ystem directory ndex rebuild oggle printer runch message file alidate user og file list Macro operations oodbye (logoff) ROS v3.3 System Operation Manual page 18 The following paragraphs describe each command (listed alphabetically): Audit trail toggle A standard ASCII text file can be created from the log and message 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. Change message area This command toggles the ability to 'move' messages from one message area to another. Once enabled, if the sysop reads a message, using the message sub-system, ROS will offer to assign the message to another area. The assigned area is the numeric value as defined in SECTION.BB# and must be entered, even if the message is to stay in the same area. Delete user The sysop is asked for a name to be deleted from the user file. ROS prompts to ensure that that is the action desired and if so, deletes the user and any messages addressed from or to that user. Edit 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. File Transfer System This command causes ROS to exit the sysop sub-system and enter the file transfer sub-system. ROS v3.3 System Operation Manual page 19 Goodbye (logoff) This command terminates the session. Index 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 information about the structure of data files when using the Turbo Toolbox, refer to the Turbo Toolbox Referance Manual (c) Borland International. Krunch message file As describe in the introduction, deleting a message only marks that message for delete. To physically remove the message from the disk, use this command. ROS will copy active messages from the current message file into a new message file and then delete the old file. Please ensure that sufficient disk space is available for this operation, otherwise the system will report an error that will cause ROS to terminate. Should this happen, ROS will automatically recover from the old files the next time it is started, but two files (SUMMARY.$$$ and MESSAGE.$$$) will be left on the disk. To ensure complete recovery, delete these two '.$$$' files, make sufficient disk space for further operations, and restart ROS. Log file list ROS maintains a time and date stamped list of most system operations. This command will display this list and then ask if the list should be erased and restarted. 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. Message System This command causes ROS to exit the sysop sub-system and enter the message sub-system. ROS v3.3 System Operation Manual page 20 Newin file processing ROS marks all uploads with the system attribute bit to prevent directory display, and stores a one line description of the file on disk. 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, and purge the NEWIN file in a manner similar to that used to krunch the message file. Until the file is krunched, the sysop may freely alter the status from any state to another. 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 description 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 should then be used to move the file to a more permanent file area and reset the system attribute bit. O 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 'TUUAXLYRPKYT' performs the following operations: Toggle the printer on Utility sub-system entry User file listing of All users X re-enter the sysop sub-system List the log file Y allow ROS to reset it Read the messages Purge the user file Krunch the message file Y allow ROS to do it Toggle the printer back off ROS v3.3 System Operation Manual page 21 This type of operation is typically 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. Four commands are available to control the macro operation: Display the contents of the macro buffer Reset the macro processor (turn it off) Start the macro processor (turn it on) Enter a new macro string Since ROS is still monitoring both the local and remote keyboards while processing a macro, the sysop has normal control to pause or terminate operations, BUT macro processing will continue until reset or 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. Purge user file 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. Read 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. System 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. Toggle printer The currently assigned LST device is alternately enabled and disabled. Utilities System This command causes ROS to exit the sysop sub-system and enter the utilities sub-system. ROS v3.3 System Operation Manual page 22 Validate 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. In addition to the specific commands in the sysop system, two other commands have enhanced capabilities for the sysop. 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 three parameters: "A" for a complete list of all users, "U" for a complete list of the unvalidated users only, or "Q" for a quick listing like that produced for normal users. ROS v3.3 System Operation Manual page 23 BUGS ROS 3.3 has one known bug: 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. ROS v3.3 System Operation Manual page 24 PREVIOUS VERSIONS OF ROS Notes to users of ROS 2.5: Included in the library is a file called ROS2TO3.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 ROS3132.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 message. 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: This release of ROS features improved sysop utilities as well as minor improvements in other areas such as file uploads and message entry/edit. Two added functions and one change have resulted in substantially easier operation for the sysop. They are as follows: Macro capability - a few keystrokes cause ROS to do the weekly cleanup sequence in an orderly and, most importantly, unattended fashion. Validate command - makes validation of new users, even from a remote site, much easier. High message - Previously, the high message was the highest message on the system the last time you logged in. With version 3.3, this value is the highest message that you have READ (even during this session). Now, as you validate a user and return to read the next message, this counter keeps track of where you were, skipping over messages you have read but not deleted. If you happen to log in but do not read any messages, ROS will not update this value so it will be available to you whenever you do. To most users, this change will be transparent. ROS v3.3 System Operation Manual page 25