RRRRRR OOOOO SSSSS 33333 22222 RR RR OOO OOO SS SS 33 33 22 22 RR RR OO OO SS 33 22 RR RR OO OO SS 33 22 RRRRRR OO OO SSSSS 333 22 RRRR OO OO SS 33 22 RR RR OO OO SS 33 22 RR RR OOO OOO SS SS 33 33 22 RR RR OOOOO SSSSS 33333 ** 2222222 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.2 April 22, 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 domain software and telecommunications work. ROS v3.2 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 44K 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 know 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.2 System Operation Manual page 4 FILES The following files are included in the ROS library: ROS.PAS Remote Operating System main program ROSDEF.INC Constant and variable definitions ROSKER.INC Kernel - not overlayed ROSOV0.INC Overlayed portion of kernel ROSINI.INC System initialization routines ROSFIL.INC File sub-system ROSMSG.INC Message sub-system ROSOPS.INC Operating routines ROSSYS.INC Sysop sub-system ROSUTL.INC Utility sub-system ROSXFR.INC File transfer routines ROSMSG.TXT Sample message file ROSSEC.TXT 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 ROSCHNG.DOC Changes made to ROS since version 3.0 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. 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.2 System Operation Manual page 5 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) Compile ROS 4) Edit the system message and section files 5) Run ROS to create other sytem files and login as 'SYSOP' These steps are amplified in the following sections. Install the machine dependent routines Select the file from ROSMAC.LBR which most closely matches your system and name that file ROSMAC.INC. This file provides ROS with the specific information necessary for the interface with your particular hardware. It is the only file requiring extensive modification (ROSDEF.INC will need some minor changes for things such as the times the sysop will be available for CHAT). The following routines should be included in ROSMAC.INC: NAME OPERATION system_init Initialize the system for operation under ROS PutStat Write to status line on local console GetTAD Return a 6 element byte array of the current system time in seconds, minutes, hours, day, month, and year. SetTAD Uses a 6 element byte array to set the current system time mdinit Initialize modem mdring Determine if the phone is ringing mdans Detect and set system to rate at which modem answered phone mdhangup Hangup modem mdcarck Check to see if carrier is present mdinprdy Check for ready to input from modem mdinp Input a byte from modem - no wait - assumed ready mdout Output a byte to modem - wait until ready mdbusy Take modem off-hook ROS v3.2 System Operation Manual page 6 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 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 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. procedure mdinit; This routine initializes the serial port and the modem. If a ring detector is available, this routine should not set the modem to answer (that will be done in the mdans routine), just get the serial port and the modem cleaned up after power up or other use. 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. ROS v3.2 System Operation Manual page 7 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 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. function mdcarck: boolean; This function is called frequently to determine that the user is still logged in. Most modems have a carrier detect line available. function mdinprdy: 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 mdinp: byte; This function returns the byte read from the input port. The system assumes that one is available (by looping on mdinprdy until one is). procedure mdout(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. 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 form here so that the modem will not answer. ROS v3.2 System Operation Manual page 8 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 used 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 log him off. 'RcvDrv' and 'RcvUsr' are the drive and user area assigned for uploads to the system. '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 120 will allow an unvalidated user to remain on the system for 14 days between calls and a validated user 120 days between calls before being deleted from the user file. Compile ROS Version 3.0 and later of ROS 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 ROS v3.2 System Operation Manual page 9 Edit the system message and section files The system message file should be edited for your particular system. A sample file called ROSMSG.TXT (in WordStar format) is included as a guideline. Note that Turbo cannot handle the high order bit that some word processors (such as WordStar) use for formatting, so the file will have to be processed before use. An easy way to do this is to copy the file used for editing to the system message file (SYSMSG.BB#) using PIP with the 'Z' option. The system attribute of the file may then be set to hide it from view. The commands for these operations are as follows: PIP SYSMSG.BB#=ROSMSG.TXT[Z] STAT SYSMSG.BB# $SYS Be sure to create SYSMSG.BB# BEFORE running ROS, or an I/O error will occur. 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 SYSTEM System command files A 1 255 PASCAL Pascal program development A 14 255 UPLOAD Private upload area 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.2 System Operation Manual page 10 The following three entries are expect 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. UPLOAD This is the file area into which uploads will be placed. The access level of this area may be set to any value, but for security is should be set high enough that most users cannot get to it. 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.2 System Operation Manual page 11 USING THE SYSTEM ROS expects to find all files in the drive/user area in which it first starts. The system files will automatically have the 'system' attribute set, i.e. they will not be visible with a normal directory command. The local console has several commands, entered by control codes, that may be requested at any time (except during file transfer). ^J (linefeed) Display menu of console commands This command will display the following line if the system is waiting for a call: ^C: Shutdown ROS, : Local use If the system is in use, entering this command will display the following line: ^B: Blank remote, ^D: Delayed shutdown, ^N: Twit, ^W: Who ^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. ^B '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. ^D '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 in to answer messages. ^N 'Twit' key. Immediately hang up on remote user. The previous command is preferred to gain system access, but sometimes this command is nice to have. ^W 'Who' is on the system. Displays the user name and address. ROS v3.2 System Operation Manual page 12 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 (this is done by raising the access level to 20). 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 Utilities The sysop utilities are 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 "?". 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. The Index rebuild command may be used to re-create a clobbered index file (this should never happen, but power fluctuations and faulty disks and drives can cause problems). The Purge command deletes all users that have not logged in within the time specified at compile time. The sysop utilities also allow you to Delete and Edit user records. BUGS As far as I know, the system does not have any residual 'bugs', but if you do find any, please leave a message on the Albuquerque RCP/M. If, as you use the system, you see the need for other changes please let me know. ROS v3.2 System Operation Manual page 13 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. ROS v3.2 System Operation Manual page 14