_______ _______ _______ ______ / / / / / / / /______/ /______/ /______/ /______ / / / / / / / /______/ /______/ ______/ Documentation for Version 5.00 October 09/90 The Public Bulletin Board System by Ian Cottrell 44 Lindhurst Crescent Ottawa, ON, Canada K2G 0T7 The Information Centre RCPM (613) 952-2289 (300/1200/2400) COPYRIGHT 1986-1990 by Ian Cottrell .fo i T A B L E O F C O N T E N T S I. Author's Note .......................................1 II. What is PBBS? .......................................3 1. Hardware Independence (BYE-BDOS) ................6 2. ZCPR Compatibility ..............................6 III. PBBS - The Modules ..................................7 1. PBBS.MAC - The Main Module ......................8 a) Welcome Message ..............................8 b) Hashed User File .............................8 c) User Level Welcome Messages ..................9 d) Bulletin .....................................9 e) Usage Statistics .............................9 f) Private System ...............................9 g) Menus .......................................10 h) PUBLIC and PRIVATE Personal Mail ............10 i) Message Threading............................11 j) Menu Functions ..............................12 READ Public Messages .....................12 PRIVATE Message Read .....................14 SEARCH for Messages.......................14 HEADER Scan of Message Base ..............14 ENTER a Message ..........................15 VIEW Messages Left by You ................15 FOLDER Change ............................15 "<" and ">"...............................16 LIST Users ...............................16 BULLETIN Display .........................16 CALLER List ..............................16 INFORMATION/NEWS Articles ................16 NEW Files (Recent Uploads to the System) .17 DESCRIPTION of New Files .................17 WRITE a Note to the Sysop ................17 USER Profile .............................18 GOODBYE ..................................18 JUMP to the File System ..................18 TOGGLE [more] prompt .....................19 EXPERT mode toggle .......................19 YAK with Sysop ...........................19 "?" ......................................19 DELETE ...................................19 k) Using a Two Menu System......................20 PBBS Menu ................................20 MAIL Menu ................................20 l) CP/M Access Restrictions ....................21 2. PBYE.MAC - The Signoff Module ..................22 a) Automatic File Maintenance ..................23 3. PMAINT.MAC - The Maintenance Module ............24 a) Quit ........................................24 b) Maintain Users File .........................24 Multiple Folder Maintenance ..............25 User Terminal Maintenance ................25 c) Maintain Message File .......................25.fo ii d) Maintenance Hard Copy On/Off ................26 e) Pack Message Base ...........................26 f) Rehash Users File ...........................27 g) Compress Callers File[, Zero System Usage] ..27 h) BYE Hardlog On/Off ..........................27 i) User Update/Purge ...........................28 j) [Display STATs &] Read Sysop Log ............28 4. PMSG.MAC - The Note and Message Upload Module ..29 a) PMSG and Remote Message Uploads .............29 b) PMSG and Local Message Uploads ..............30 c) PMSG as a Replacement for PNOTE .............30 5. PCHAT.MAC - The Chat Module ....................31 IV. PBBS Files List ....................................33 V. PBBS Installation ..................................35 1. Setting BYE5xx for use with PBBS ...............35 2. Installing your Clock Routine for Maintenance ..35 3. Installing and Initializing PBBS ...............36 4. Customizing PBBS to Your Needs .................39 a) PBBSEQU.HDR .................................39 b) PBBSDB.HDR ..................................49 c) TCAP ........................................54 d) Multiple Message Folders ....................54 e) Multiple Folders Code Sample ................56 f) Chat Configuration Table ....................57 g) Access Level Options ........................57 VI. Appendix A - Description of PBBS file structures ...59 1. MSGINDEX.PBS ...................................59 2. INDEX.PBS ......................................59 3. USERS.PBS ......................................60 4. MESSAGES.PBS ...................................61 5. CALLERS.PBS ....................................61 6. LASTCALR .......................................61 VII. Appendix B - User Profile for Multiple Folders .....63 VIII. Appendix C - Sample PBBS Menus .....................65 IX. Appendix D - PBBS Utilities ........................67 1. PUSER50.LBR.....................................67 2. PSTAT50.LBR.....................................67 X. Appendix E - Acknowledgements ......................69 XI. Appendix F - PBBSUBS.REL subroutines................71 1. BFCB:...........................................71 2. BFCB2:..........................................71 3. CAPS:...........................................71 4. CDATE:..........................................71 5. CLOSE:..........................................71 6. CLOSE2:.........................................71 7. CNVRT0:.........................................72 8. COPEN:..........................................72.fo iii 9. CPM:............................................72 10. CTIME:..........................................72 11. DATDIF:.........................................72 12. DIV16...........................................72 13. DOBS............................................72 14. ECHO............................................73 15. @ECHO...........................................73 16. ENDPBS..........................................73 17. FILLHL..........................................73 18. FULDAT..........................................73 19. GETCH...........................................73 20. GTCHCR..........................................73 21. INPUT...........................................74 22. IOPEN...........................................74 23. MATCH...........................................74 24. MIOPEN..........................................74 25. MLDL............................................74 26. MOV2DT..........................................74 27. MOVE............................................74 28. MOVNM...........................................74 29. MSGOPN..........................................75 30. OPEN............................................75 31. OPENA...........................................75 32. OPEN1...........................................75 33. OPEN1A..........................................75 34. OPEN2...........................................75 35. PCRLF...........................................75 36. PA2ASC..........................................75 37. PB2ASC..........................................76 38. PS2ASC..........................................76 39. PRINT...........................................76 40. @PRNT...........................................76 41. PRINTA..........................................76 42. PRINTL..........................................76 43. @PRNTL..........................................76 44. PRINTM..........................................76 45. PRINTN:.........................................77 46. PRINTP..........................................77 47. PRINTS..........................................77 48. PDATE...........................................77 49. PTIME...........................................77 50. PUT.............................................77 51. PUT2............................................77 52. GET.............................................77 53. GET2............................................77 54. PUT64...........................................78 55. PUT264..........................................78 56. GET64...........................................78 57. GET264..........................................78 58. PVER............................................78 59. SDLR............................................78 60. SPBDOS..........................................78 61. SPINP...........................................78 62. SPOPEN..........................................79 63. SUBHL...........................................79.fo iv 64. UOPEN...........................................79 65. Error Messages..................................79 .fo Documentation for PBBS v5.00 Page # of 79 I. Author's Note PBBS is in the public domain. I have Copyrighted this manual because it seemed like the proper thing to do. I am allowing this manual to be distributed under the following conditions: 1) It is only to be distributed with PBBS version software. 2) It may not be sold or distributed commercially without my express written permission. No other use may be made of this manual or any part or excerpt without the express, written consent of the author. These are the only restrictions I am placing on this manual or the PBBS system software. Historical note: PBBS originated with Simon Ewin's E-MX system and was developed into PBBS (up to version 4.00) by Russ Pencin. Legalities: CP/M is a registered trademark of Digital Research - Ian Cottrell September 30/90 This page intentionally left blank II. What is PBBS? PBBS is a remote bulletin board system and is one of the most full featured systems currently available for CP/M. Written in Z-80 assembler to optimize the speed and minimize the size of the executable modules required, PBBS is the single most popular BBS for Remote CP/M systems in North America. (Source: The International RCP/M List, September, 1990). The user file size is set at install time and does not change for the life of the system. This user file is indexed (using a simple hash algorithm based on the user's last name) which allows very rapid user look-up at sign-on and for message entry. On a system allowing 500 members, the user file occupies only 64k of disk space. Users may be assigned one of 16 possible user access levels, from 0 (deleted user, no longer active) to 15 (Sysop) and each access level has its own maximum drive and user for access to files, amount of time on the system, number of days of inactivity until a user is deleted, and file upload/download ratio. The messages file will grow dynamically as messages are entered. However, the messages are stored as compactly as possible, and the average system message file usually occupies between 300-600k of disk space (provided that the Sysop does his routine maintenance regularly). PBBS supports up to 9 message/subject folders. These folders are optional, and the subject names may be specified by the Sysop. Access to each folder is automated by PBBS, but can be totally controlled by the Sysop. All menus, bulletins, welcome, and news files are standard ASCII text files, created with any text editor. PBBS provides, among others, the following features: o Extensive 15 level user profile o Totally menu driven single character commands o Optional dual or single menu operation o Optional command input through 'hotkeys' (single key input) o Public and Private Message system o Up to 9 optional Message Subject Folders with 15 character names o Automatic new mail waiting lookup at log-in o Automatic reply to all mail o Optional automatic message threading o Individual highest message read counter o User lookup based on last name for message entry o Up to 26 INFORMATION/NEWS files o An overall WELCOME message o An individual WELCOME message for each user level o A BULLETIN message, optionally displayable at login o Enhanced built-in display of the KMD/ZMD log o Enhanced built-in display of the KMD/ZMD 'FOR' file o CHAT with BYE bell check and adjustable access times o List of previous log-ins showing name, location, date and time of log-in o FEEDBACK to Sysop in main message base o Optional Private system lock-out with .COM or .TXT file o Optional CP/M access restriction based on access level o Optional CP/M knowledge question based on access level o Optional statistics (percentage use and average call duration) o Automatic file run on entry to CP/M with optional individual CP/M entry file for each user level o BYE5xx BDOS interface o Automatic user/message file maintenance o Automatic support file creation PBBS implements the BYE BDOS interface, and as such, is almost totally hardware independent. If you can install BYE for your system, you can run PBBS with no need for special inserts or overlays. The only customization required is performed in two header files (PBBSEQU.HDR and PBBSDB.HDR) which are automatically included in each of the operating programs of PBBS at assembly time. The PBBS maintenance file uses the same real time clock insert as your BYE program to allow its use independent of BYE. Note: In order to run PBBS, the system MUST have a real time clock. PBBS is partially self-maintaining. The first time, after midnight each day, that the system is idle, PBBS automatically scans the user file and marks users that have been inactive for a period of time defined by their access level. If these users do not log-in again before the next 'rehash' of the user file, they will be deleted. PBBS next scans the message base and deletes all messages to or from these deleted users. These messages cannot be recovered by anyone but the Sysop (or Co-Sysop). PBBS notifies the Sysop of the number of users and messages removed during the update and lists the names of all deleted users in a message in the Sysop log (COMMENTS file). This function is done off-line, that is, it will only occur the first time that carrier is lost after midnight, and disables the modem during the time of update. Thus, the user is not burdened with waiting for the system to do its maintenance. After completion, PBBS returns to BYE5 to await the next call. The spaces in the user file created by this maintenance are then available for re-use by PBBS. The number of days since the last sign-on is used to determine whether to mark a user as 'inactive' (for possible future deletion). This number of days is determined from a table of attributes attached to each of 14 active user levels (level 0 is used to indicate a user record that is available to be utilized for a new user, level 1 to indicate a banned user). Banned users and any users with a 'days to deletion' value of 0 are not removed from the database during the update routine. The exact day values and other related security information for each access level are stored in a table that the Sysop sets up within the PBBSDB.HDR file. Level 15 is reserved for the Sysop, and Level 14 is reserved for any co-Sysops, while Levels 12 and 13 are reserved for future PBBS enhancements. The MESSAGES update deletes any old messages that were sent to or received from any user that was just removed. Public messages sent to 'ALL' must be deleted by the Sysop. The access level of a user is set to 2 initially, and the level is optionally auto-incremented on each successive call, up to a level pre-set by the Sysop. For access greater than the pre-set level, the Sysop must manually upgrade the user by using PBBSMNT (the PBBS maintenance utility). The auto-bump of the access level only occurs if the call is NOT on the same day as the previous call and if the DOBUMP flag is set in the PBBSEQU.HDR file. The BUMPHI value (also in PBBSEQU.HDR) is used to determine the highest level that users may automatically reach. PBBS provides up to 9 optional message sub-folders for segmenting messages by topic. If the sysop has selected Multiple folders, and the user has access to multiple folders, the "F"older Change option can be used to select the current working folder. Folder 0 is reserved for "GLOBAL" access, and provides access to all folders. Selecting a specific folder value other than 0 will limit all mail actions to just the folder selected. PBBS will optionally keep track of system usage statistics. These statistics include number of callers and the average call duration for today and the percentage use of the system for today and yesterday. There is also a record of the previous 31 days stats, which can be viewed using the PBBSMNT utility. PBBS provides several security related features. Users who attempt to log-in to the system, but are unable to provide their proper password, are noted in the Sysop log (the COMMENTS file). Each remote access by the Sysop is logged to the same file with date and time of access. Any automatic maintenance by PBBS is also logged to this file, as well as any "TWITs" (banned users) who try to log-in again. PBBSMNT provides the means of adding or deleting users and editing the user record of an existing user. It also provides the means to maintain the message base, allowing reading, deleting, "undeleting", setting public or private, editing the message header (TO:, FROM: and SUBJ:) and setting the folder number to which a message is assigned. As well, it provides routines to 'rehash' the user file (remove any users marked as 'inactive' and re-sort the names alphabetically), to 'pack' the message base (remove any deleted messages and compress the file), to renumber the messages (and update each user's 'high message' pointer to agree with the new numbers), to check the user file for users who will be declared 'inactive' during the next routine maintenance cycle (this routine will also warn the sysop of any users whose 'last on' date is invalid, a situation that can cause problems with the automatic maintenance), to compress the CALLERS file down to the last 20 callers (and zero the system usage statistics) and to view the 31-day usage statistics and the sysop log. All files are automatically backed-up prior to any potentially destructive operations. PBBSMNT stores the date and time of a user or message file access in the index file and informs the Sysop of the last update date and time on each subsequent access. PBBS (in conjunction with the ZMD host transfer program) allows users to upload messages into the message base using XMODEM (or YMODEM) protocol. Multiple messages (to multiple users, if desired) may be contained in a single upload file. Users are allowed to edit each message before it is appended to the message base. Note that M-80 and L-80 (copyright Microsoft, Inc) or Z80ASM and SLRNK (copyright SLR Systems) are required to assemble and link PBBS. 1. Hardware Independence (BYE-BDOS) PBBS is practically hardware independent since it gets all of its input from the BYE5xx extended BDOS calls. The exception to this is the maintenance program, which requires that a slightly modified version of the BYE5-RTC insert for the particular equipment be included during the assembling of the program. The maintenance module may be run without the necessity of first loading BYE5xx, but it is the only module which can be run this way. 2. ZCPR Compatibility PBBS runs best under ZCPR or its clones, but will function properly in a standard CP/M system. PBBS allows for the external command buffer of some ZCPR implementations and handles file invoking using the proper ZCPR convention. PBBS also will work properly with EZCPR if the SETCCP flag is set and the CCPLOC location is set in PBBSDB.HDR to the location returned by SYSTEM.COM. If you are running ZCMD, a switch is provided to handle ZCMD's default command handling. If your CCP is at an odd location and cannot be located properly from the normal BIOS offset, you should set the SETCCP flag and enter your CCP location at CCPLOC. If the TCAP option has been selected, PBBS will also inform ZCPR3 of the user's terminal capabilities. III. PBBS - The Modules PBBS comprises five main modules (each module is a .MAC file containing the source code in Z-80 assembly language). They are: PBBS.MAC - the main module of a PBBS system. It handles user signon and all message functions as well as allowing the user to view (among other things) previous callers, names of other system users, new uploads and their descriptions and to view and modify his own system profile (nulls, terminal width, terminal length, etc.). PBYE.MAC - the signoff module of a PBBS system. It is invoked when a user logs off (either from within PBBS or from CP/M) or when carrier is lost. It handles updating the previous user's record (time on, number of downloads, etc.) and prepares the system for the next user, before handing control over to BYE, to await the next call. PMAINT.MAC - the maintenance module of a PBBS system. This module allows the Sysop to maintain both the user file (USERS.PBS) and the message base (MESSAGES.PBS and MSGINDEX.PBS) and to perform all the maintenance necessary for the smooth and efficient operation of the system. PMSG.MAC - the note and message upload module. This is a multipurpose module which has three functions. It allows users to upload one or more messages as a file (using Robert Kramer's ZMD, version 150 or higher) and then puts them into the main PBBS message base. It also allows users to leave a message to the Sysop while in CP/M (replacing the old PNOTE.MAC) and it allows the Sysop to read a prepared file into the message base (like replies for those questions which seem to get asked over and over again). PCHAT.MAC - the chat module. This module allows the user to 'page' the sysop and, if he is available, to chat with him through their respective keyboards. Each module will be described in more detail below. 1. PBBS.MAC - The Main Module The PBBS program itself has many features and options. I will try to describe them in the order in which they occur as a user logs in to the system. a) Welcome Message This is an ASCII text file with your personal welcome message to users as they sign on. It is the first thing that each user will see as he attempts to log in to your system, so give some thought to what you say here. This file may be more than one page (screen) long; PBBS will stop each time the screen is full and display '[Enter to continue; C, K, or X to abort]' in the lower left corner of the screen (NOTE: throughout the rest of this manual, I will refer to this prompt as the '[more]' prompt). If the user enters a space, the system will display one more line and pause again. Striking any other key will cause the system to output another page of this file until it all has been shown. Note that the length of a page may be any value from 16 to 66 lines and is a variable saved as part of the user's profile. This is more fully explained in the subsection 'USER Profile' of the 'Menu Functions' section later in this manual. The display may be aborted at any time by entering a 'C', 'K' or 'X' (or 'c', '^C', 'k', '^K' 'x', or '^X') and paused by entering an 'S' (or 's' or '^S'). (NOTE: all of the above mentioned abort and pause characters will work within any of the PBBS modules. I will not repeat this list in future, just refer to an abort character or a pause character). Once the output has been paused, any key will start it again. Even if the display has been paused and restarted, PBBS will still 'page' the file every screen page. This welcome file is displayed only at sign-on, not when re-entering PBBS from CP/M. b) Hashed User File In order to speed up the user look-up and not have to re-sort the user file often, PBBS implements a simple hash routine to store and locate users. Once the user has entered his first and last names to PBBS's satisfaction (with no middle names, initials, etc), the routine takes the first character of the last name and uses this as an index into the user file. PBBS will re-use deleted user records (access level 0) only if it cannot find an empty record location in the file. If this begins to happen, the Sysop should rehash the user file (using the PBBSMNT program) to maximize the performance of the system. Rehashing replaces all level 0 user records with blank (available) records and sorts the user records alphabetically by last name. Prior to rehashing, if a level 0 user calls the system, he will be reinstated but at the minimum level of access. Because the hash routine must know in advance the actual size of the user file in order to calculate the index point, the user file size is fixed at install time, and never changes during the life of the system. The minimum number of users is 100, the maximum number is 999. Under normal conditions, it is recommend that the Sysop rehash the user file at least once a month. This process is covered in more detail in the section which discusses PBBS maintenance. c) User Level Welcome Messages Each time a user logs in, PBBS searches for one of a series of 12 welcome messages, one for each level from 2 to 13. This is an optional feature, controlled, as are all options, by an EQUate in the PBBSEQU.HDR file (see Section V, 'PBBS Installation'). These files are normally named WELCOM plus the number of the level for which each is intended, with the file extension PBS (e.g. WELCOM2.PBS for level 2 users, WELCOM3.PBS for level 3 users, etc). If a file for the appropriate level is not found, nothing happens and PBBS proceeds to the next phase of the login process. If, however, the file is found, it is displayed in the same manner described previously for the main welcome file. These files can be very useful for pointing out privileges or restrictions associated with each level. d) Bulletin The system may also display the BULLETIN.PBS file at login. (Another optional feature, controlled by PBBSEQU.HDR). This is an ASCII text file with new or special information of which users should be aware. This file may also be read from the PBBS menu system, using the "B" option. e) Usage Statistics Another optional feature, the display of system usage statistics, is also available at login. This feature will display the number of callers, the average call duration and the percentage of total useable time that has been used for the current day and the percentage of total useable time that has been used for the previous day. Another feature may be selected which creates and maintains a special table, showing the above statistics for the previous 31 days. This table may be viewed using the PBBSMNT utility. The sysop may choose to maintain the statistics without displaying them to users or to not keep statistics at all. Both options are controlled by EQUates within the PBBSEQU.HDR file. f) Private System Any text file may be used as the private file (called PRIVATE.PBS). It should describe the means of gaining access to your system if you have the PRVATE EQUate set to YES in the header file. You may run a .COM file instead, if the PRVCOM EQUate is YES, but DO NOT SET BOTH TO YES! g) Menus There are two options for menus within the PBBS system plus one special menu. The sysop may choose to use only one features menu, with all functions available from it or to use two menus, one for the mail functions (called the MAIL menu) and one for the 'other' functions (called the PBBS menu). The special menu is for the information/news files (displayed when a user selects the "I" option from the single menu or the PBBS menu). Each of these menus is a text file, created with any word processor or text editor and stored in the 'system' drive and user area, as defined in PBBSEQU.HDR. See Appendix D for examples of these menus. The default names of the files are: ONEMENU.PBS - Single MENU Text file with available options. or PBBSMENU.PBS - Main MENU Text file with available options. MAILMENU.PBS - Mail MENU Text file with available options. NEWS.PBS - News MENU Text file. Must NOT end with a carriage return and is edited each time you add or delete a NEWS file on your system. NOTE: although all menus may be edited to your satisfaction with any text editor, if you use WordStar (or any other editor which uses high-bit sets), be sure to remove these high bits (with WSDOCON, FILT7 or a similar program), since this can cause interesting effects on some terminals/systems. This warning applies to ANY text files used by the system. h) PUBLIC and PRIVATE Personal Mail When a user logs-in, his profile is checked to determine if he has mail waiting (PBBS always updates a counter in his user record whenever anyone sends him mail). If he has no mail waiting, either read or unread, he is sent directly to the main (single) menu, unless the sysop is using two menus, in which case he is taken to the PBBS menu. If, however, he does have some mail, he goes directly to the mail section of PBBS (the MAIL menu in a two menu system). In this case, the system displays the total number of messages addressed to the user (both public and private) and the number of these which are NEW messages since his last log-in. Any message with a number higher than that shown in the user's record as the highest message that he has read is considered a NEW message. If the user has no NEW messages, PBBS goes directly to the appropriate menu, but, if he has NEW messages, he is offered the option of reading NEW messages immediately. If he says no, the system proceeds as if he had no NEW mail. If he says yes, then the oldest (the lowest numbered) NEW message is displayed. Once he has read a message, he has the option of replying to this message. Should he choose to reply, the name of the original sender is automatically set into the receiver field for the reply. PBBS does a quick check to insure that the selected recipient is still active on the system, then shows the user the subject of the message to which he is replying and asks him if it is acceptable as the subject for the new message. If he replies in the affirmative, message entry continues as detailed in the 'ENTER a message' section following. However, if the old subject is unacceptable, PBBS prompts the user for a new subject. If, at this point he enters only a carriage return, message entry is aborted. If he enters a valid subject, once again message entry continues as detailed in the ENTER section following. After entering the reply, or if the user decides not to reply, PBBS will ask if he wants to delete the message just read, since it is addressed to him. If he says yes, PBBS marks the message for deletion (it can still be read by a Sysop until the message base is 'packed') and proceeds to the next NEW message, where the whole process is repeated. If there are no more NEW message, the user is informed of this fact and PBBS goes to the appropriate menu prompt (either the single or the MAIL menu). i) Message Threading The normal operation of a bulletin board message system is to step through the message base, starting with any given message, and progressing, one by one, in the order in which the messages were left, bypassing those that are not available for reading because they are either private messages or deleted. Although this system is reliable and gets the job done, it has one major failing: there is no method for reading a message and all of its replies without getting hopelessly lost in the message base. As the message base on a system grows, the task of reading messages related to a particular topic gets even more difficult. The user has no way to track the many replies to a message. The advent of 'quick scan' methods has helped, but the task is still a difficult one. Message threading is one possible answer to this problem. This is a system of tracking messages and their replies throughout the message base allowing the user to follow related topics along a message thread. The messages prior to and after the current message are called the forward and reverse links and are used as pointers through the thread. The header display of both PBBS and PMNT has been updated to display the link information. The example below shows a typical header display. ----------------------------------------------------------------- Mesg: 8 ( ) Date: 09 Oct 90 Fldr: General Time: 22:03:37 Subj: Welcome to PBBS Rply: 1 (3-9) From: Ian Cottrell To: All R)ead, N)ext, P)revious, T)hread, (>/<), D)elete, E)xit: ----------------------------------------------------------------- NOTE: The 'T)hread, (>/<)' part of the prompt is only shown in PBBS. Message threading is not used in PMNT. The only new feature here is the display of the link information beside the 'Rply:' label. The first number shown is the base message or first message in the thread. The next two numbers are the reverse link and forward link. The word 'None' will be displayed if the base message is not given (such as for messages generated before message threading was initiated), 'BOT' is shown for the reverse link if the current message is the beginning of the thread and 'EOT' is shown for the forward link if the current message is the end of the thread. Thus, a single isolated message, connected to no thread, would be shown as 'Rply: None (BOT-EOT)'. The prompts 'T)hread, ()' are explained in detail in the section 'READ Public Messages' following. The PMNT module has also been updated to enable the renumbering of the links during message maintenance. Since PMNT has a GOTO function, it was deemed unnecessary to add a message threading facility to this module. j) Menu Functions The following functions are available from the single menu if this option is selected in PBBSEQU.HDR. See below for differences if the two menu system is selected. READ Public Messages (Option [R]) - allows the user to read individual or continuous messages after entering the message number from which to begin the read (or 'new', to read all messages entered since the last time he read messages). If the user adds a "+" to the message number, the system will display the headers and the messages one after another without a pause. This is to allow a user to 'capture' messages as quickly as possible and minimize his connect time. During the "R" command with no "+", the system operates in one of two ways. If the SKPHDR EQUate in PBBSEQU.HDR is NO, the system prints the folder name, subject, sender, recipient, thread information and date and time of each message (the message header), then presents the user with at least the following options: '"R"ead, "N"ext, "S"can, "E"xit'. The user may skip to the next message, in which case, the next message header is presented. If, however, the SKPHDR EQUate in the header file is YES, the message header and the message are both displayed. If the user chooses to read a message or headers and messages are printed together, the message is printed on the screen. (The system stops printing the message after the screen is full [if the message is longer than one screen] and displays a '[more]' prompt. It then proceeds as detailed under the previous 'Welcome Message' section). At the end of each message, the user is offered at least the following options: '"N"ext, "S"can, "E"xit'. Next will skip to the next header (or header plus message). Scan will immediately go to the display detailed in 'Header Scan' below, starting with the next available message after the one that he was reading at the time that he elected to Scan. The scan command proceeds as discussed under 'Header Scan'. The exit option is self explanatory, returning the user to the menu prompt at which he started. If the current message number is not the starting number from which this 'read' began, the "P"revious option is included in the option line after the header is printed. This option allows the user to 'go backwards' and view the previous message. He may continue to go backwards until the starting number for this particular read session is reached, at which point the "P"revious option will not appear. If the message has any threads, either forward or backward, both the header prompt and the main message prompt will contain the following options: '"T"hread, "(>/<)"'. The "T"hread option will present a list of ALL messages in the current thread (using the same format as in the header scan option), the ">" command will go directly to the next message forward in the thread while the "<" command will go to the next message backward in the thread. After the "T"hread option has finished listing all messages in the thread, the user is presented with same options as before he entered the "T"hread command. The ">" and "<" options proceed as if the user had entered a "N"ext or "P"revious command, EXCEPT that when the user next enters a "N"ext or "P"revious command, he is taken to the message next or previous to the message from which he began reading this thread. Thus, it is possible for a user to explore up and/or down a thread and not 'lose his place' in the message base. If a user enters a ">" when he is at the head of a thread or a "<" when he is at the tail of a thread, he is shown the current message again. If the current message is NOT from the current user and he 'reads' it, then he is presented with a "R"eply option. If he selects "R"eply, then the system proceeds as in 'PRIVATE and PUBLIC Personal Mail' above. If the message is to or from this user, then the system will also offer the option to delete it, whether he replies to it or not, if the NODEL EQUate is NO. For more information on deleting messages, see the heading 'DELETE', below. Note that the READ function will display ALL public messages plus any private messages sent or received by this user. The user may use the "[P]" option to view only messages sent to him personally (both public and private). Also note that the read function is the only one which will update the user's 'high system message read' pointer. PRIVATE Message Read (Option [P]) - allows the user to read all messages (if any), both public and private, addressed to him. The display of messages is identical to that described in 'READ' above. The user will be given an opportunity to continue, respond to the sender or delete the message. If he chooses to reply, the system proceeds in a manner identical to that described under 'PUBLIC and PRIVATE Personal Mail' above. If there are no messages addressed to this user waiting when this option is selected, PBBS will say "No messages waiting". Note that this option counts all messages addressed to the user and updates this count in the user's record in USERS.PBS. Also note that threading does not operate in this mode. SEARCH for Messages (Option [S]) - allows the user to search all the messages in the message base and view only those messages that match a search string which he specifies. He will be asked if he wishes to do a search on the sender, the receiver or the subject field and then prompted for a string for which he wishes to search. The search string may contain multiple words (up to a maximum of 26 characters). Once the message base has been searched, PBBS will inform the user how many messages it found that match the search criteria and proceed to display the first message. From there, things proceed as for the normal 'read' functions. All public messages and any private messages to or from the user will be included in the search. HEADER Scan of Message Base (Option [H]) - allows the user to do a quick scan (one line per message) of the message base after he enters the message number from which to begin the scan. He may enter 'new' (or 'NEW' or just 'N' or 'n') to scan mail that he has not yet read. Only public messages and his private messages will be displayed. Messages that have already been read by the recipient are prefaced with an '(R)' and private messages with a '(P)'. Messages that are public but have not been read or that are addressed to 'ALL' are prefaced with empty brackets. ENTER a Message (Option [E]) - will, depending on the user's access level, allow him to enter public messages to ALL users or be required to leave only private messages to other users or the Sysop. Messages to individual users may be public or private at the sending user's option. The enter routine normally allows 3800 characters per message (adjustable from within PBBSEQU.HDR), and does an auto word wrap based on the user's selected terminal width. To end the input cycle the user must type 2 consecutive carriage returns; this will give him the exit menu allowing him to "P"rivate save, "S"ave, "L"ist, "E"dit, "C"ontinue, or "A"bort the message entry. PBBS will confirm a request from the user to Abort entry of the message. The editor is a string based editor rather than line based, allowing the user to change only the characters in error rather than retyping the entire line. If you have multiple folders set, when the user requests a "S"ave or a "P"rivate save, PBBS will display the folder names for the user, and ask him into which folder he would like to place the message. VIEW Messages Left by You (Option [V]) - allows the user to review and possibly delete any messages (public or private) that he has written to other users. FOLDER Change (Option [F]) - if NMFLDRS is greater than 1, several additional sections of logic will be incorporated into the PBBS program. The first of these changes is the addition of the "F"older Change option to the menu. If the Sysop has implemented multiple folders, and the user has access to multiple folders, the "F"older Change option can be used to select the current working folder. Folder 0 is reserved for "GLOBAL" access, and provides access to all folders. Selecting a specific folder value other than 0 will limit all mail actions to just the folder selected. When the user enters a message from the "GLOBAL" folder, he will be prompted to select the subject folder for the message from a list of folders to which he has access. If the user enters a message when NOT in the "GLOBAL" folder, the message will be posted to the currently selected folder. When the "F"older Change option is selected, the folder selection logic will display a list of accessible folders, and the user may select any folder from the list by simply entering the corresponding menu number. "<" and ">" (Options [<] & [>]) - the user may enter a "<" to go to the next LOWER folder number or a ">" to go to the next HIGHER folder. The "<" and ">" operators are circular in logic and will loop thru all the folders (except folder 0 (GLOBAL)) in either a positive (>) or negative (<) progression. The ONLY way to return to the GLOBAL folder after selecting one of the other folders is to enter an "F" to invoke the folder selection logic, and then to enter a "0" for the selected folder. "P"rivate mail reading and reading of messages sent by the user are by definition "GLOBAL" functions and will look at ALL folders to which the user has access and then return to the folder previously selected. LIST Users (Option [L]) - a caller may scan the user file for the names and locations (city and province/state) of other users. After entering the "L" option, he is asked for the first letter of the desired last name or a level number. Users may only scan by level number up to their own level (i.e. Level 5 users may see other level 5's but not 6's or higher). They will be shown the allowable levels as part of the prompt. If a valid letter or number is entered, the system will display the active users, the city of origin, and the last logged in date for the selected letter or number to normal users. To a sysop, it will also show the PBBS access level of each user. If a is entered in response to the prompt, the command aborts and the user is returned to the appropriate menu. BULLETIN Display (Option [B]) - will display the BULLETIN.PBS file on the screen (with '[more]' pauses and single line or full page advance, if the [more] toggle is currently ON). BULLETIN.PBS is an ASCII text file containing new or special information of which users need to be aware. CALLER List (Option [C]) - this function will display the last eighteen callers (twenty if you is using two menus) to the system in reverse order (most recent caller first). It displays the date, log-in time, log-off time, baud rate, caller's name and city of origin. INFORMATION/NEWS Articles (Option [I]) - will display the contents of the file NEWS and await input from the user. NEWS must contain an annotated list of available NEWS files (see Appendix D for a sample) and must NOT end with a carriage return. This menu file is edited each time you add or delete a NEWS file on your system. Any text file may be used as a NEWS file and you may have up to 26 of them. News file names must start with NEWS plus the ALPHA character of the file (i.e. NEWSA, NEWSB,...,NEWSZ). When the user enters a valid alpha character, PBBS will find the appropriate NEWS file and display it on the screen (with [more] pauses, if enabled and necessary). When the entire file has been displayed, the user is prompted for a carriage return; when this is entered, the NEWS menu is displayed again and the system again waits for an alpha character. If the user selects a news file that is not active, an error message is displayed. The error message is contained in the file NEWSERR. All of the files associated with this feature must be stored on the system drive and user area. NEW Files (Recent Uploads to the System) (Option [N) - will display information about new uploads to the system (from the log file created by whatever file transfer program is used by the system - XMODEM, KMD, ZMD or ?). When the user requests this list, PBBS will open the appropriate .LOG file and display it on the screen in reverse order (latest uploads first) (with '[more]' pauses if they are enabled). When the date of the users last log- in is reached, a message is displayed, saying "Your last LOG-IN was here!", so that the user is aware that he may have already seen the rest of the uploads list. When the display is paused at a '[more]' prompt, entering a space will cause 1 more line to be displayed while any other character will cause an entire new page (23 lines) to be displayed. The 'log' file must be on the system drive and user area of your system for PBBS to access it. DESCRIPTION of New Files (Option [D]) - will display descriptive information about new uploads to the system (from the FOR file created by whatever file transfer program is used by the system - XMODEM, KMD, ZMD or ?). If the [more] toggle is enabled, all the normal pause options apply. The FOR file must be on the system drive and user area of your system for PBBS to access it. If the sysop is using more than one FOR file (one for CP/M and one for MS-DOS or using Wayne Masters' FOR-8 system), there are EQUates in PBBSEQU.HDR to handle these situations. WRITE a Note to the Sysop (Option [W]) - will place a message in the main message base addressed to the name located at the label SYSOP: in the PBBSEQU.HDR file. The user's feedback is entered in the same way as described under 'Enter a Message' above and he has all the normal options after his message is entered. The Sysop will automatically be shown any messages waiting for him when he signs-on the system and can use the auto reply to respond to the user. USER Profile (Option [U]) - this routine displays the current user's on- line statistics and his current user profile. It allows him to change his number of nulls, password, phone #, default screen length and width, TCAP setting (if used) and the state of the 'hotkey' flag. It also displays (but does not allow him to change) the amount of time he has left on the system, the highest system message that he has read and the state of the [more] and expert toggles. GOODBYE (Option [G]) - this function allows the user to leave the system. Before he goes, he be will asked if he wants to delete the remaining messages in his message queue (if there are any and NODEL is set to NO). If his reply is affirmative, PBBS will delete all messages, private or public, addressed to him. Otherwise, the system proceeds with the log-off procedure. If the EXCMT EQUate in PBBSEQU.HDR is YES, the user will now be asked if he wishes to leave a an "exit comment" to the Sysop. If he says yes, the system will create a message addressed to the name located at the label SYSOP: (i.e. the Sysop) in the PBBSDB.HDR file. The user's comments are entered into a message titled "Exit Comment" in the message file. Message entry and editing are identical to the method previously described under 'ENTER'. If the user does not wish to leave a comment, or after he has finished his comment, PBBS proceeds with his log-off. For details of this process, see 'PBYE and User Log-off' later in this document. JUMP to the File System (Option [J]) - this function allows the user to leave PBBS and enter the CP/M operating system. (See below for information on CP/M access restrictions). If the header file has a valid filename at each of the following labels, then that file is run when CP/M is entered: If the user is a new user, the file at label NENTRY: is run. If the user has an access =>7 and SPON is YES, the file at label SPENTRY: is executed. If this is the second time that the user has entered CP/M (i.e. he logged in, went to CP/M, re- entered PBBS and is now returning to CP/M) and ALTON is YES, the file at label ALTFILE: is selected. Finally, if none of the above conditions apply, PBBS chains to the file at label ENTRY:. Alternately, if the EQUate ENTY is YES, PBBS will chain to a filed called ENTYxx, where xx is the user's current access level. This allows a different file to be run for each level of user on your system. Once again, these events only happen if the label in question points to a valid filename, as explained in PBBSEQU.HDR. TOGGLE [more] prompt (Option [T]) - this command determines whether PBBS will pause, while displaying messages and other text files, every time the screen is full and display the '[more]' prompt. Each time the user enters a 'T', the state of the '[more]' switch changes ('toggles') and the system displays a message telling whether the '[more]' toggle is enabled (on) or disabled (off). The value of the '[more] toggle' is stored in the user's record and when he logs in again will be at the same level as when he last logged off. The length of one screen is a variable entered by the user during his initial login and stored in his user record. Thus, users with portable computers that have screens with less than 24 lines will still experience proper 'paging' of all displays within PBBS. EXPERT mode toggle (Option [X]) - will determine whether a full menu (the text contained in ONEMENU.PBS or PBBSMENU.PBS and MAILMENU.PBS) will be displayed each time the system prompts the user for a command. If expert mode is OFF, a menu is displayed each time, while, if expert mode is ON, only the first letter of each valid command is displayed. This command is also a toggle and is separately maintained for each user. YAK with Sysop (Option [Y]) - allows the user to 'page' the Sysop so that they may 'talk' via their respective keyboards. The Sysop has the option of setting the times during the day that he is available for chat. If the user asks for a chat within the hours established, the system rings the bell (number of times to ring can be set in PBBSEQU.HDR). An 'ESC' will allow the Sysop to answer the chat call, or he may initiate a chat himself by typing an "@" character from any menu. To exit chat, enter three carriage returns. Chat is auto- wrapping at the first space after the 65th character in the line. Note that if the EQUate COYAK (in PBBSEQU.HDR) is YES and the user is a co-Sysop, a page will be issued, regardless of the time. "?" (Option [?]) - will cause the system to display the appropriate command menu ONCE, regardless of the state of the expert mode toggle. DELETE Delete is not one of the commands available from the menus, but is offered during the "[P]","[R]" or "[V]" commands. Delete only works if the message in question is addressed to or sent from the user. (The exception to this is the Sysop or Co-Sysop, who can delete any message on the system, public or private). When a delete request is entered, PBBS will prompt with: 'Are you sure (y/N)?'. If a y (or Y) is entered, PBBS proceeds to delete the message. If ANY other character is entered, the delete command is aborted and the message is NOT deleted. Once a message has been deleted, it can only be retrieved by the Sysop, using the message file maintenance feature of PBBSMNT. If the message file has been packed since the message was deleted, then that message is gone and cannot be restored. NOTE: Sysops may view all the messages on the system by entering a "!" from the menu prompt. If a "!" is entered, the user's access level is checked . If he is the Sysop or a Co-Sysop, the system requests a number at which to begin the display of messages. Once a valid number has been entered, PBBS begins to display every message (including ones which have been deleted), beginning with the entered number. The display is the same as that described in 'READ' above. After each message, the Sysop is prompted to '"N"ext, "R"eply, "D"elete, "S"can, "Q"uit'. If he decides to delete the message, then the comment 'Message Killed...' is displayed. k) Using a Two Menu System If the Sysop elects to use a two menu system (called the Mail Menu and the PBBS menu), the functions are broken up as follows: Under the PBBS Menu Under the Mail Menu Bulletin Display Read Public Messages Caller List Private Message Read List Users Search Message Subjects Information/News Articles Header Scan of Messages New Files Enter a Message Description of New Files View Message Left by You Write a Note to Sysop Folder Change User Profile Next & Previous Folder Goto the Mail Menu Goto the PBBS Menu Goodbye Goodbye Jump to the File System Jump to the File System Toggle [more] Prompt Toggle [more] Prompt eXpert Mode Toggle eXpert Mode Toggle Yak with Sysop Yak with Sysop Display Menu Once Display Menu Once The only commands not already described are the two commands to change from one menu to the other. PBBS Menu (Option [M]) - this command takes the user to the MAIL menu prompt. MAIL Menu (Option [M]) - this command takes the user to the PBBS menu prompt. l) CP/M Access Restrictions The Sysop may completely restrict new users from entering CP/M, since the level at which a user gains access to CP/M is set in PBBSDB.HDR. Or, the Sysop may require a CP/M knowledge test before allowing a user into CP/M. Again, the level below which the question is asked is defined in the PBBSDB.HDR file. The Sysop may also restrict the use of XMODEM/KMD by implementing the ACCESS byte in XMODEM/KMD and setting it in PBBSDB.HDR. This allows the user to only send files to the system, or only receive files from the system, or both. The fifth byte in the Access table (in PBBSDB.HDR) determines the ratio of downloads to uploads allowed for each level. 2. PBYE.MAC - The Signoff Module When a user enters the 'G' command from a PBBS menu or when he types 'BYE' from CP/M, PBYE.COM is run. PBYE is responsible for signing the user off of the system, updating all necessary files and then preparing things for BYE to await the next call. PBYE first checks the REENTR byte to see if a valid user was on the system (since PBYE is called by BYE5xx, it could be the Sysop returning from a local session in CP/M, without PBBS). If there was no user, PBYE jumps immediately to the 'display callers' section, if this option was selected. However, if a valid user was on the system, the PBYE re-loads his user record in memory and then checks for carrier. If there is no carrier, the user is already gone. If there is a carrier, PBYE will check to see if it is the Sysop. If it is the Sysop, PBYE will (if necessary, create and) update the COMMENTS file (on the system drive and user area) with the record of this log-in. This is the only place where the Sysop's log-ins are recorded. PBYE then jumps to the time calculation section. Note that if the Sysop is calling remotely and drops carrier before PBYE reaches this point, there will be no record of his log-in. If the caller is not the Sysop, PBYE will (optionally, controlled from PBBSEQU.HDR) ask the user if he wishes to leave a comment to the Sysop. At this point, PBYE starts a timer. If the user doesn't answer within 10 seconds, it moves to the next section. If the user replies yes, then PBYE proceeds in the same manner as PBBS when a user wants to leave a message. If the user is allowed to leave public messages, he is offered the choice of a public or a private message (always in Folder 1 of the message base), addressed to the name stored at the label SYSOP: within the PBBSDB.HDR file. Now PBYE takes the caller's log-in and log-out times and calculates his connect time. If the caller is not the Sysop, it updates the CALLERS file (on the 'system' drive and user area). This file can be "TYPED" by the Sysop from CP/M since, except for the first record (which contains the number of records in the file), the file is standard ASCII text. If the Sysop deletes this file, the system will create a new one on the next user log- out. There is a compress utility in PBBSMNT that will shorten the CALLERS file to the last 20 callers. Next, PBYE displays the caller's session statistics on the screen, even if the carrier has been lost, since the Sysop may want to see them locally. These statistics include the user's name, his log-in, log-off and connect times, the number of new uploads and the total number of uploads and, if the user is allowed to download, the number of new and the total number of downloads. PBYE will now reset the REENTR byte for the next caller and then instructs BYE5xx to hang up the phone and prevent the modem from answering. It then checks the current date against the date stored in INDEX.PBS as the last date that USERS.PBS was updated. If these two dates are different, then PBYE proceeds with its automatic file maintenance (see next section: Automatic File Maintenance). If the Sysop has requested the caller display (DSPCLR: in PBBSEQU.HDR is YES), the value of DSPNUM (in PBBSDB.HDR) is checked and this number of callers (from the CALLERS file) are now displayed on the local screen. PBYE finally returns to BYE5xx, which readies the modem to accept the next call and then waits for it. a) Automatic File Maintenance PBYE performs user and message file maintenance the first time that the system is idle after midnight each day. This maintenance is done off-line so as not to force the user to wait while PBYE gets its act together. This routine first checks the date of the last user file maintenance in the INDEX.PBS file. If the date is different from the current date and there is no carrier as indicated by BYE5xx, the routine starts scanning USERS.PBS for users that have exceeded the number of days to deletion determined by their access level. These users are then marked for possible future deletion and the routine scans the message file for any messages to or from the marked users and deletes those messages. Note that, if necessary, all message threads are updated to ensure continuous threads, no matter where within the thread that a message is deleted. PBYE then updates all indices and the user count. After completion, the routine chains to BYE5xx, allowing BYE5xx to re-initialize the modem and prepare for the next call. The after hours maintenance data is stored in the COMMENTS file for the Sysop to view. Data stored are: number of users marked for deletion, number of messages deleted, and the date and time that the maintenance was performed, plus a 2 column list of all the users deleted that day. Note that no users are actually deleted; deletion only occurs when USERS.PBS is rehashed, using the PBBSMNT routine for this purpose. Any marked user who logs-in before a rehash is done will be reinstated with the same password and other personal stats, but no messages, as a level 2 user. Similarly, no messages are actually deleted; they may be restored (by the Sysop using PBBSMNT) at any time until MESSAGES.PBS is packed. There is no way for a user to restore a deleted message. 3. PMAINT.MAC - The Maintenance Module The PMAINT program is designed to allow the Sysop to keep PBBS running at maximum efficiency. The REHASH users routine is also used in the conversion process from other user data bases to the PBBS format to insure proper look-up of user names. When the Sysop (or anyone else) tries to use the maintenance program, he is prompted for a password. This password is stored at PW: in the PBBSDB.HDR file and must be entered EXACTLY as it appears there. If the password is not entered correctly, the system will return to prompt. When PMAINT is invoke, it presents a menu of 10 options. Each is described in detail below. a) Quit This menu entry allows the sysop to exit from the PMAINT routine and return to CP/M. b) Maintain Users File The user file maintenance routines allow the Sysop to view the current settings for any user in the data base. The routine allows searching for a user by name. Since "deleted" users are still in the data base until a REHASH is performed, the Sysop may search and reinstate deleted users with this routine. The routine skips any records that are "free", that is, ones that have not been used since the last rehash. Caution should be exercised in changing the last name of a user (mis-spelled, etc), since the users are stored in their HASHED order, and radical changes to the name may keep PBBS from finding the user, until the user file is sorted and rehashed again. When the Sysop requests user maintenance, PMAINT will ask what level the Sysop wants to display. The only acceptable responses are 0-15, or a letter 'C'. The will default to all access levels while the 'C' will cancel user maintenance. The routine starts with the first active record for the chosen level and displays this record to the Sysop. The Sysop may then scan each individual record by entering the appropriate command from the menu or may search to an individual user by using the ">" command. If, when using the ">" command, the Sysop asks for a name that is not in the user file, PMAINT will ask if the Sysop wants to add the user. If the Sysop answers "Y", PMAINT will display a blank profile for the new user and allow the Sysop to add the required information. If the user is found, PMAINT will display the user profile unless the user access level is different from the one selected by the Sysop. In this situation, PMAINT will not ask to add the user, but will display the closest profile to the one selected. If the Sysop selects an access level that has no active users, PMAINT will search for users, then report 'No level xx users found'. All fields in the user profile can be modified. If, during a filtered scan of the user file, the Sysop changes a user's access level, PMAINT will not redisplay the changed user's profile, but rather, will move to the next active user for the level selected. At the completion of the maintenance the routine, PMAINT will store the current date and time in the INDEX to indicate the last time the file was maintained. Multiple Folder Maintenance If NMFLDRS is greater than 1, several additional sections of logic will be incorporated into the PMAINT program. The first change is the addition of a new menu item in the user file maintenance section. This new option (I) will display, and allow for changing a user's folder access. A table will be displayed for each of the folders you have implemented (2 thru 9) with a key value displayed below the folder number. The key values are defined as: Y The user has access to the folder N The user does not CURRENTLY have access to the folder B The Sysop has BLOCKED the user from having access to the folder. The Sysop may change the access value for any folder by selecting the "I" option. The "GRANT" option should be used to provide a user with access to a folder that has a minimum access level higher than that user's current access level. REMEMBER, as the user's access level increases, he will automatically be given access to folders based on the values that were placed in MAILTBL in PBBSDB.HDR. To restrict a user from having access to a folder, the Sysop should enter a "B" for the selected folder. Access to a BLOCKED folder is never changed to YES by PBBS. The "REMOVE" function can be used to reset access to a folder that was previously granted or blocked. User Terminal Maintenance There is no direct impact on PMAINT from the TCAP option, except that the user's selected terminal type is displayed and may be changed from the user file maintenance routine. You should, however, take care when changing a user's terminal type, as the value you enter will be used the next time the user logs-in to the system to load the ZCPR3 Environment Descriptor. c) Maintain Message File The message file routine allows the Sysop to view all messages one at a time. The Sysop may chose whether to display all of the messages in the system, or to display only the active messages. The routine starts with the last active message in the file (highest number) and normally proceeds backwards through the file. However, from any message but the first or last one, you may move to the next (higher number) or previous (lower number) message. There is also a 'goto' function, which prompts for a message number and goes immediately to that number (or a close as possible).The Sysop may "D"elete active messages or "U"ndelete deleted messages during this operation. If you have set NMFLDRS to a value greater than 1, as each message is displayed you will be given the option of "C"hanging the folder for that message. If this option is selected, a mini menu of the folders you have implemented will be displayed, and you will be asked to select the new folder value. Think about the new value you enter, for it is possible to set the folder value so that the intended user will not be able to see the message. There is a small header editor included with this function which allows the Sysop to change the sender's name, the receiver's name or the subject. Any name changes are checked against the user file for validity before the change is allowed. The Sysop may also toggle messages between private and public. This allows him to remove messages considered inappropriate from public view as well as make items of general interest available to all (be careful about the legal aspects of this feature!). When you are finished with this function, you will be asked if you want to renumber the messages. If you answer "Y" to this question, the messages will be renumbered sequentially from 1, and the user file will be scanned and all user's "HIGHEST MSG. READ" numbers will be reset to the appropriate new number. All thread link number will also be updated, so that no threads are destroyed by the renumbering process. The message base allows message numbers from 1 to 65,325, so renumbering is seldom necessary, but is recommended, since a new user who logs in and finds himself several thousand messages behind (even though there might be only a hundred active messages) may be overwhelmed and decide not to bother! d) Maintenance Hard Copy On/Off PMAINT provides two hard copy switch options. This routine allows the Sysop to set or display the current settings for the PMAINT hard copy switch. The hardlog switch for PMAINT will remain on only during the current PMAINT session and will print all activities done within the PMAINT program on the system LST: device (printer). (See also BYE Hardlog On/Off). e) Pack Message Base This routine will clean out deleted messages from the message base and condense the message base files. It will rename the MESSAGE.PBS, MSGINDEX.PBS, INDEX.PBS files to *.BAK (deleting any BAK files with the same names that are present), condense the messages file by writing only active messages to the new file and update the index file. One word of caution: because of certain problems with random files and CP/M, you must insure that there is sufficient room on the disk to build the new files. If, after performing the pack, you find that some message accesses cause a "READ UNWRITTEN RECORD" error, then you may not have allowed enough room for the new files. Just rename the *.BAK files, create some more room on the disk and do it again. f) Rehash Users File This routine is provided for two reasons. First, when converting an existing user base to the PBBS format, the file must be correctly HASHED to allow PBBS to find users. Secondly, after the system runs for a while, eventually all of the "free" records will be used up, and begin to slow down PBBS's user search routines. The search routines use these "free" records as flags to determine whether a given user is in the system. If, during the search for a user, a "free" record is encountered, this indicates that the user is definitely not in the data base. When this occurs during the "new user" log-in, this first free record is assigned to the new user. Rehashing the user file will remove all "deleted" users (i.e. access level 0 ) and replace these records with free records. It will also sort the active users alphabetically by last name to maximize the speed of the search routines. It is recommend that REHASH be performed at least once a month to insure maximum system efficiency. To insure that the system can be recovered in case of disaster, the original USERS.PBS file is renamed to USERS.BAK, and a new user file is created, then all appropriate records are copied to the new file. If there should be a problem you need only rename the original file back to USER.PBS, and try again. g) Compress Callers File[, Zero System Usage] This routine will rename the CALLERS file to CALLERS.BAK, then copy the 20 most recent callers to a new CALLERS file. This should be done periodically to prevent the CALLERS file from taking over your entire hard disk! If the EQUate MSTATS (in PBBSEQU.HDR) is YES, the routine will then ask you it you wish to reset the current day's usage to zero. If you say yes, it will clear all statistics counters for the current day. Whether you reply yes or no, you will next be asked if you wish zero the accumulated system stats. Again, if you say yes, it will set all the 31-day statistics counters to zero. Once this is done (or if you answered no to the question), the routine returns to the main PMAINT menu. h) BYE Hardlog On/Off The function allows you to set the state of the BYE5xx hardlog switch. This switch causes ALL user activity (including Sysop activity and ALL passwords) to be printed on the system printer. Once turned on, this switch remains in effect (and consumes rather large quantities of paper!) until you turn it off again. See the BYE5xx documentation for more details on this switch. i) User Update/Purge This function was added to allow the Sysop to perform a 'dry run' of the after hours purge of users. It is exactly the same as the routine in PBYE, except that it does not mark any users for deletion. The routine will scan the entire user base and display the name of each user who has exceeded the "Days to Deletion" value for his access level on the screen. It will also list any users whose 'last login date' is somehow corrupted. A corrupted date will prevent the PBYE midnight maintenance routine from working correctly, so any user records found with this problem should be correct manually, using the PMAINT user file maintenance routine. j) [Display STATs &] Read Sysop Log If the EQUate MSTATS (in PBBSEQU.HDR) is YES, this routine will display the 31-day system statistics. Each day is shown (1-31) and for each day the total time used (in hours and minutes), the total number of callers, the average call duration (in minutes) and the percent usage is displayed. A small arrow (=>) points to the current day. You are then asked if you wish to read the Sysop log (COMMENTS file). If you reply yes (or if MSTATS is NO), the contents of the COMMENTS file is displayed. This display is not paged in any way, since you usually only want to see the last few entries. Once this display is complete, you are asked if you wish to erase old comments. If you say yes, the COMMENTS file is deleted (a new one will be created by PBBS whenever it is needed). The routine then returns to the main menu. A negative reply to either of the previous questions will also return to the main menu. 4. PMSG.MAC - The Note and Message Upload Module PMSG has three basic modes of operation and contains a built in help function, available using the '?' or '/' option. The three modes are described in detail below. a) PMSG and Remote Message Uploads PMSG allows any caller to forward a preformatted text file to your system's message base (provided that his user level is sufficient to allow uploads to your system). You must, of course, use a file transfer program capable of supporting direct uploads to the message base, such as ZMD (version 1.49 or greater), by Robert Kramer. Remote callers can upload to the PBBS message base by using the ZMD RM command (the XMMSG EQUate in PBBSEQU.HDR must be set to YES). This will also help callers who experience difficulty with noisy lines since they can now create their message locally on their own system and forward it to your RCP/M with 16 bit CRC error checking. It also saves a lot of precious time for long distance callers who will no longer have to enter and edit messages while online. The command for remote use is: ZMD RM filename.ext The message file is uploaded into a private area, where PMSG finds and processes it. PMSG will read the (first) message and display its header (date, subject, sender and receiver). Then a list of valid folders will be displayed and the user prompted to select one. Once this is done, the normal 'end of message' options [P)rivate, S)ave, A)bort, C)ontinue, E)dit, H)eader, L)ist] are presented and the program proceeds as if a normal message was being entered into PBBS. Once the message has been saved, PMSG will look for another message within the same uploaded file. If another message is found, it will be processed as above. This procedure will continue until no more messages are found. Note that if A)bort is selected at any time, the user will be asked if he wishes to abort just this message or this one and all following messages. The message file format was designed to be simple. All that is required is the name of the receiver and the message subject. The message text can be formatted in any fashion you desire using your favourite word processor. The first colon (:) signals that the next non-space character is the first letter of the receiver's name. This name may be as long as 30 characters, lower/uppercase is not significant and must match the name of a active system user. If the name cannot be found in the user base, an error message will be seen and you will be asked if you want to abort this message. If you reply with 'N', you will be given another chance to enter a valid name. The second colon signals that the next non-space character is the start of the message subject. The message subject may be as long as 26 characters and lower/uppercase is significant. The message subject is terminated with a CR,LF The message body is signaled by the next character with an ASCII value higher than a ' '. In other words, PMSG will skip blank lines (CR,LF) until it reaches the actual message text. The length of the message is restricted to the size you allowed for messages in the PBBSEQU.HDR file. Terminating a message is as simple as hitting RETURN two or more times to insert two or more blank lines. An example: To: John BBSCaller Re: New BBS/CPM Feature John, this message was sent to you using PMSG with the ZMD RM function. Multiple messages are supported. Messages are separated by at least to two blank lines. This signals the current message end. Each message must have a valid receiver and subject and uses the same format as about. Once all records of the uploaded message text file have been read, the process is terminated. b) PMSG and Local Message Uploads Locally, Sysops can forward text files to callers, simply by entering their name and the message subject into the top of the text file. A standard message can be made to forward to those new users who always ask the same questions over and over. The command for local use is: PMSG {du:}filename.ext The format is identical to that used for remote uploads and PMSG operates the same as detailed above. PMSG is wheel sensitive and will not allow non-wheel users to append local files directly to your message base. When the wheel is set, the sender name can also be edited, allowing the Sysop full flexibility when he enters a message this way. c) PMSG as a Replacement for PNOTE When run without specifying a filename, PMSG acts as PNOTE and allows the user to leave a public or private message to the SYSOP. If the user uses the H)eader option, the message may be re-directed to any other active user on the system. 5. PCHAT.MAC - The Chat Module PCHAT is a simple little program that will page the Sysop and allow him and the user to 'chat' via their keyboards. It is called from the operating system (usually renamed to CHAT.COM) and operates identically to the 'YAK with Sysop' option of PBBS. This page intentionally left blank IV. PBBS Files List The files included in the PBBS-50.LBR file are: PBBS50.UPD ....... Update information. A description of all new features available with version 5.0. PBBSEQU.HDR ...... The installation file that will allow you to customize many of PBBS' features. PBBSDB.HDR ....... The installation file that will contain addresses and strings specific to your system. PBBS50.MAC ....... The main PBBS file. PMNT50.MAC ....... The maintenance routines for the PBBS system. PMAINT is installed at the same time as PBBS since both files contain identical data areas. The maintenance routines allow full control of each user's record in the user file as well as message reading and deletion. PBYE50.MAC ....... This is the PBBS EXIT file. This file will run when a user types BYE or quits from one of the PBBS menus. It updates the user's statistics then prints these statistics and a goodbye message. After updating the user's record, it returns to your 'real' BYE5xx. PMSG50.MAC ....... This is a program used to enter notes to the Sysop while in CP/M and also used (in conjunction with ZMD v1.50 or greater) to allow users to upload messages as files. It will automatically add notes to the PBBS message base without forcing the user to re- enter PBBS. PCHT50.MAC ....... This allows the Sysop to 'chat' with a user while in CP/M (without forcing the user to re-enter PBBS. BDOSHDR.MAC ...... The time and date interface to BYE5xx. PBBSUBS.REL ...... This file contains all the disk I/O random file routines, print routines, and various utility subroutines. Appendix G of this document is a list of the routines contained within PBBSUBS.REL, including the condition of all pertinent registers on entry and exit from each routine. These routines may be used for either writing your own PBBS routines or for adding routines to PBBS itself. This is version 5.0. The files included in the PBBSUP50.LBR file are: APBBS.SUB ........ A SUBMIT file that will assemble and link all source files and create a complete set of object files using M80/L80. ZPBBS.SUB ........ A SUBMIT file that will assemble and link all source files and create a complete set of object files using Z80ASM/SLRNK. PBBSMENU.PBS ..... A sample PBBS menu text file. MAILMENU.PBS ..... A sample MAIL menu text file. ONEMENU.PBS ...... A sample menu text file for a one menu system. BULLETIN.PBS ..... A sample bulletin text file. PRIVATE.PBS ...... A sample private system text file NEWS ............. The NEWS menu text file. NEWSA ............ A sample NEWS file. NEWSERR.PBS ...... The primary error text file. PBBS50.WS ........ The PBBS documentation file (this file!). PINSTALL.COM ..... Creates the following files: INDEX.PBS ........ The initial index file. MSGINDEX.PBS ..... The initial message index file. MESSAGES.PBS ..... The initial messages database. USERS.PBS ........ The initial user database. LASTCALR ......... The initial last caller file. V. PBBS Installation PBBS is a closed system. That is, it requires BYE5xx only to provide hardware interface and to properly load PBBS or PBYE at the proper times. The interface for BYE5xx has taken care of these problems and no special modifications are required other than setting the equates described below. Additions and enhancements to BYE5xx have resulted in a program that works extremely well with PBBS. 1. Setting BYE5xx for use with PBBS All PBBS systems should use BYE510 (or later). All of the fixes required to properly run PBBS in the BYE5xx environment have now been implemented within BYE510. The only action required to use BYE510 with PBBS is to set the following EQUATES, plus any others specific to your system, then assemble BYE510, and proceed with the PBBS installation. Note that this should apply to future upgrades of BYExxx (current version as of this date: BYE510). 1) Set BYE5xx for: COMFILE EQU YES COMDRV EQU 'A' (the drive/user where COMUSR EQU 0 PBBS.COM will reside) EXFILE EQU YES EXRET EQU NO BYHANG EQU NO EXDRV EQU 'A' EXUSR EQU 14 MSGFIL EQU NO NO25TH EQU YES NO25BF EQU 86 (Not 76 as stated in BYE510.ASM!) READLC EQU NO WELFILE EQU NO PBBS EQU YES CLOCK EQU YES (PBBS will not run without a clock!) TIMEON EQU YES RTOK EQU YES RTOKFG EQU 0XXXXh (this is the value of the REENTR byte in your PBBSEQU.HDR) These are the EQUATES that are specific to PBBS, the rest you must set to match your system and/or your preference. 2. Installing your Clock Routine for Maintenance This one is really easy! Just rename the BYE real time clock insert to BYERTC.INS and rename the label TIME: to TIMER:. That's it! This file will be included at assembly time into the PMAINT.MAC file, and give you proper times and dates for maintenance. 3. Installing and Initializing PBBS Now for the installation procedure. It will be outlined it as a series of steps for the sake of brevity and clarity. The procedure is quite straight forward and should not create any difficulties. There are 2 files included in the library which will aid in the installation of PBBS. APBBS.SUB is a submit file which will assemble and link the five PBBS modules using M80/L80. ZPBBS.SUB is a similar file, but for use with Z80ASM and SLRNK. 1: Edit PBBSEQU.HDR and PBBSDB.HDR as required/desired for your system. Set the switches according to the way you want the system to function (a detailed description of each switch is provided in the next section, Customizing PBBS to Your Needs). NOTE: Be very sure that the lengths of the strings required fit as indicated and that items are null padded to the right. You may want to edit some of the other .MAC files to suit your system, but this is not recommended until you have successfully installed the plain vanilla version. Also note that the files PBBSEQU.HDR and/or PBBSDB.HDR CANNOT be assembled; they are automatically included with each of the other PBBS files at assembly time. 2: Take the files that are indicated in the APBBS.SUB (or ZPBBS.SUB) file and place them all on the same disk and then run the submit file. If disk space prohibits this, you may use the 1PBBS.SUB file to assemble and link each of the files individually. NOTE: The files PBBSEQU.HDR, PBBSDB.HDR and BDOSHDR.MAC must be present to allow proper assembly of all files except PMAINT50.MAC. PMAINT50.MAC does not require BDOSHDR.MAC but does require the BYE5xx real time clock insert. (This insert must be renamed to BYERTC.INS and the label TIME: must be renamed to TIMER: for PMAINT50.MAC to assemble properly). Proper linkage of all files requires that PBBSUBS.REL be present. OR If you can't or don't want to use either of the SUBMIT files, each of the .MAC files from PBBS-50.LBR may be assembled then linked individually. The syntax required for M80/L80 is: M80 =filename/M L80 filename,PBBSUBS,filename/E/N and for Z80ASM/SLRNK is: Z80ASM filename/M SLRNK filename/A:100/V,PBBSUBS/V,filename/N/E where filename is the name of the PBBS file to be assembled or linked (without any extension) and the letters after the '/' are M80/L80 or Z80ASM/SLRNK switches. Be sure to use this exact syntax! Note that the order in which the various modules are assembled and linked makes no difference. 3: Place the *.PBS files, PBYE50.COM (renamed to PBYE.COM), PMAINT50.COM, and the PINSTAL.COM files in the user area specified in the PBBSEQU.HDR file as the 'system' area. Place PBBS50.COM (renamed to PBBS.COM) and BYE5xx.COM (renamed to BYE.COM) in user area 0 of your 'system' disk. 90% of the errors that may be encountered from here on occur because a file is not in the right area and PBBS can't find it. 4: Run PINSTAL.COM on the 'system' user area to create the system files. You will be asked to log yourself in during this operation, and you will automatically be set to Sysop access level. If you are converting an existing user file, this information will be replaced with your converted record. Please read Appendix C at this point for further information on converting existing BBS user files to PBBS format. 5: Run BYE.COM to initialize the re-enter byte and load PBBS. At this point note that the files that are used with the PBBS file are not necessarily in the current user area to which you are logged, (nor that a future user will be logged). PBBS will take care of finding any *.PBS files that are needed, but it is up to your CCP, NZCPR, ZCPRx, ZCMDxx, BYE5xx, etc. to find the PBBS.COM file on your system. Note that some systems may need to have the modem connected before you can run BYE. 6: After BYE5xx initializes, enter a ctrl-C, then "E" to execute PBBS. This is the only way to run PBBS since it gets all of its interface from BYE5xx. You will find that you are in the sign-on section of the PBBS. Putting you in the signon section is the function of the REENTR byte that BYE sets to 0 when it first runs or when a call is finished; if REENTR is non-zero, the sign-on section is skipped. Proceed with your normal sign-on. NOTE: If PBBS should be unable to find your name in its user file, exit out of BYE5xx and use PMAINT to locate your record in the file, and edit as necessary. 7: If you are running with two menus, select the "M" option to go to the MAIL menu. 8: At the prompt, select option "E" to post a message. 9: Enter some sort of welcome message or one that describes some system functions or some other system information. Terminate your message with two carriage returns. NOTE: It is important that there is always at least one message in the database when you use option 4 in PMAINT to pack the message files. If pack is used on an empty file, it will do strange things. 10: Save this message with the "S" option and, when asked, enter it into the "General" folder so that all users may read it. After saving the message, select option "G" to end the session. Because you are running locally, without carrier, PBYE will update the user file, and return you to BYE5xx, which will wait for the next call. NOTE: If you sign on as a normal user, PBYE will not ask you to leave a comment on exit because PBYE recognizes the fact that you are running the program locally. Also, if you exit the system by typing BYE from the CP/M prompt, BYE5xx will not allow PBYE to run, and therefore you will not get session statistics. Both of these situations are normal and are not a reason for concern. 11: Now the system is ready for users to begin calling. NOTE: This is the exact procedure you must use to "check" on the system in the future. BYE5xx will always clear the REENTR byte, so the next user should never find himself with your log-in and Sysop privileges. If you are converting from a non-PBBS system or updating from a version of PBBS older than version 4.5, please contact the author directly for information about or assistance with converting your existing user and message files to a format suitable for use with PBBS 5.0. 4. Customizing PBBS to Your Needs PBBSEQU.HDR and PBBSDB.HDR are the key to customizing PBBS. All options and functions which the Sysop may set are contained within these files. Following is a detailed description of each switch in the PBBSEQU.HDR file followed by a similar description for PBBSDB.HDR. a) PBBSEQU.HDR DO NOT change the GENSTR MACRO, the Public labels, the External symbols, the PBBS file structure equates, the constant equates or the BYE5 extended BDOS equates! The first option that you must select is the assembler definition. Three options are offered: M80 (Microsoft), SLR (SLR Systems) and ZAS (Alpha Systems). Set the one which corresponds to the assembler that you will be using to assemble PBBS to YES; set the others to NO. There is also an EQUate for using the LINK80 assembler (copyright Digital Research) instead of L80 or SLRNK. This may be set if you wish to use LINK80 to link the files, but you must also select the appropriate assembler. The next section which you must set are the credit and version equates. VERSION If the version switch is YES, the current version number is printed each time PBBS is run. CREDITS If the credits switch is YES, the author's information is printed after the version number. MSGTHD If this switch is YES, PBBS will maintain message thread information for the appropriate message and users will be allowed to read up and down the threads. If this switch is NO, then no threads are available. BULTIN If this switch is YES, PBBS will display the BULLETIN file to each user at log-in. DOBUMP If the DOBUMP switch is YES, the system will auto- matically bump the user's level up one level with each call on a new day, up to BUMPHI. Levels above BUMPHI must be set manually with PMAINT. BUMPHI The highest level to which you want PBBS to auto- increment the user level. DSKLOG If this switch is set, then PBBS knows that you are using the DISKLOG feature of BYE510 (or greater) and will turn the log off and on at the appropriate times. This disklog feature records all user activity while in CP/M and writes it to a disk file. DSPCLR If this switch is YES, PBYE will display the last (DSPNUM) callers before chaining to BYE5xx. Set DSPNUM in PBBSDB.HDR for the number you want to display. MSTATS If this switch is YES, PBBS will maintain a series of system statistics. These statistics include the number of calls, total time on-line (all callers), average call duration and the percent of time that the system was actually in use during the day. These statistics are maintained current for each day and at the end of each day are transferred to INDEX.PBS, where 31 days worth of statistics are maintained. DSTATS If this switch is YES, PBBS will display system statistics to a user at log-in. These statistics include number of calls and average call duration for the current day and the percent of time that the system was actually in use during the current and the previous day. Note that MSTATS must be set in order for this options to work. EXCMT If this switch is YES, the user is asked if he wishes to leave a comment (can be private or public, depending on other switches and the user's level) to the Sysop during the log-out process. KNOWON If the knowledge switch is YES, a question defined in PBBSDB.HDR is asked of each user before he is allowed to exit from PBBS to CP/M. This question should demonstrate an understanding on his part of the CP/M environment. This is automatically disabled by the restrict switch (RSTKON). KNOKLV The maximum access level for asking the CP/M knowledge question, can be any number from 2 to 15. This should help to keep the MS-DOS people from getting lost in the wonderful world of CP/M. NODEL Determines how often and when a user is asked to delete messages from his queue. If set to NO, the user is asked if he wants to delete a message to which he has just replied (and which was addressed to him) and is asked to delete his entire queue whenever he enters CP/M with the [J] command or whenever he logs off with the [G] command. If it is set to YES, he is only asked when he replies to a message that was addressed to him. USRDEL Determines whether users are allowed to delete messages at all. If set to YES, users may delete messages as detailed in NODEL above. If set to no, only Sysops may delete messages. ASKDEL If this EQUate is YES, all users (including Sysops) are asked to confirm that they want to delete a message before it is actually deleted. ONEMNU Set to YES to only use one menu (usually ONEMENU.PBS) or to NO to use two menus (usually PBBSMENU.PBS and MAILMENU.PBS) MAXU The maximum number of users can be based on an arbitrary decision or on the maximum size of the file you want on disk for the user database. (Each record is 128 bytes long so divide the maximum bytes wanted by 128 and that's the number to use here). Remember this value, since PINSTAL.COM will ask you for it to build the hashed user file. There is no simple way to change this number once the system is running, so be generous. The minimum number is 100, the maximum is 9999. OXGATE If you are converting an OXGATE BBS system to PBBS, you will need to set the OXGATE equate to TRUE. This will automatically include special code in PBBS to decode the OXGATE user's password and replace the password with the ASCII version after the user's first call to the system. POSTLV The minimum access level for leaving any messages; can be any number from 0 to 15. If set to 0, then ALLLV: is used to determine posting level. ALLLV The minimum access level for leaving public messages; can be any number from 2 to 15. RSTKON If the restrict switch is YES, new users are not allowed to access the CP/M environment at all. Once the Sysop validates the user and sets his level above RSTKLV (see below), he gains access. RSTKLV The minimum access level for accessing CP/M if restrict (RSTKON) is set. It can be any number from 2 to 15. This should help to keep non-validated users from destroying your system. SETPATH If set to YES, when the Sysop or a co-Sysop jumps to CP/M, PBBS will reset the path to the values at the label SYSPATH: (in PBBSDB.HDR). CCP replacement programs like ZCMD will also provide this feature, based on the value of the wheel byte. It is probably easier to implement there than from PBBS. SKPHDR If this switch is YES, PBBS will not halt after displaying a message header during message READS, but will display the entire message before waiting for user input. If NO, PBBS will show only the header of the message then ask the user if he want to read the message, skip directly to the next message or quit reading messages entirely. SPON If this COM switch is YES, a special .COM file is run when a user with an access level equal to or greater than 7 first enters CP/M. The name of this file is entered at the label SPENTRY: (in PBBSDB.HDR). ALTON If the alternate file switch is YES, a file is run on exiting PBBS when the sign-on portion was bypassed due to REENTR being non-zero (i.e. the second time that a user goes from PBBS to CP/M). The name of this file is entered at the label ALTFILE: (in PBBSDB.HDR). TOT If the total time on switch is YES, PBBS will keep track of the total time used each day, and update BYE5xx's TON: function. TRIES The number of times that a user can try to remember his name or get his password right. If this number is exceeded, the file that is defined as the ERROR file is run (almost always BYE). FOR8 This EQUate controls the type of FOR file used. If you are using Irv Hoff's regular FOR.COM with one file to hold the FOR descriptions, then set this to NO. If you are using Wayne Masters' modification to FOR (called FOR-8) which uses to files (one for new uploads and one for older uploads), then set this to YES. WELON If the welcome switch is YES, a file normally called WELCOME.PBS is displayed when PBBS is run provided that the REENTR byte is 0. This file should be stored on the 'system' drive and user area and named at the label WELCOM: in PBBSDB.HDR. WELCUM If this switch is YES, a different text file is displayed to each different user level. The file is typed after the user logs-in but before the system statistics are displayed. The files are called WELCOM2.PBS, WELCOM3.PBS, etc and are stored on the 'system' drive and user area. ENTY If this switch is YES, a different .COM file is run for each different user level when the user jumps to CP/M. The files are called ENTY2.COM, ENTY3.COM, etc and are stored on the 'system' drive and user area. If this switch is yes, all other .COM files switches (SPON and ALTON) should be NO. MSGLIN Sets the size of your message buffer. It is currently set to 60 * 64 byte records, around 3800 characters. You may increase or decrease this value to suit your needs. Remember that this is the message buffer only, the message index list will load after this buffer. MSGBUF The actual size of your message buffer (obtained by multiplying MSGLIN by 64). CCPLOC Is the base address for CCP. The needed info to chain to another .COM file is sent here as required if the switch SETCCP:: is set to 1. Otherwise the location of the CCP is calculated from the BIOS offset. MCLBUF Is the base address for the command line processor if you are running ZCPR with an external command buffer. The needed info to chain to another .COM file is sent here as required if the switch EXTCL:: is set to 1. Otherwise the default file buffer in CP/M is used. ZCPR3 Set this switch to YES is you are using ZCPR3.x TCAP Set this switch to YES if you are using ZCPR3 or ZRDOS and wish to take advantage of the Environmental Descriptor Terminal capabilities. For more details, see the separate heading, TCAP, below. Z3ENV or SYSENV The address of your ZCPR3 or ZRDOS Environment Descriptor. Only the appropriate one of these need be set. The other EQUates (ZTYP, ZPTH, etc) are derived from the setting of Z3ENV and should NOT be changed. The following addresses require SAFE memory and are maintained by PBBS itself. SAFE memory is memory that is not modified by a warm boot or any other program. In PBBSEQU.HDR, any of the following that are not being used by you should have as their addresses set to 0105h (LABEL JUNK::). The 8085 interrupt vectors, starting at 020H-02DH, have been chosen for these values since most Z-80 system do not use this area for anything. If these locations conflict with your system, you will need to determine other SAFE memory locations. The bytes and their names/functions are described as follows: REENTR The re-entry byte for PBBS that is checked to determine if user is already logged in and is re-entering PBBS. PATH Address of the PATH starting point in your system. PBBS installs the Sysop path when Sysop exits to CP/M if SETPATH: is set to YES. This EQUate is not used if ZCPR3 is YES. TRCMD Some remote systems (especially those using ZCPR3) support terminal specific strings to be sent to a user, giving him reverse video, clear screen, etc. A one byte code is kept in the user file to associate the user with a particular pre-defined terminal. This code is placed into this address at log-in for any program to use as it wishes. This is used to store the TCAP information if the TCAP equate is TRUE. USREC PBBS saves the user's record number in the user file into 2 bytes at this address. Error #1 in PBBS usually occurs because this 2 byte value has been altered. LOCK This address is filled with the user's access level in BINARY. If system .COM files have been secured using LOCK this byte will be checked by the locked .COM file for the value set in the .COM file at 'lock-time'. If LOCK is not being used this address is optional. Not used by PBBS internally, but you may want it. USRMAP This is a 2 byte address that will contain a bit-map of the user areas that a user can access (1,2,4,5 but not 3 etc.). Entry of the user area map (and the drive map as well) is achieved through the entry of a 16 bit binary number. A bit set to 1 means that the drive or user area matching in position is active while a 0 indicates inactive. Bit 15=user area 15 and bit 0=user area 0. - 0100000000000111 = access to user areas 0,1,2,14 DRVMAP This 2 byte address provides mapping of drives as with user areas (A:, B:, D:, E: but not C: etc.). The USRMAP and DRVMAP functions can be used in conjunction with a modified GOTO, SECTION, CD type of program thus bringing much improved flexibility to system security. One could also install the routines in BYE or their CCP. In the drive map, bit 15=P: and bit 0=A: - 0000000100000101 = access to drives A:, C:, I: NOTE: PBBS does not use USRMAP, or DRVMAP, they are set by PBBS for use by other programs. PBYE will only use the ASCACC byte value if ASCACC is set to a memory location other than JUNK::. DKSFLG This is the memory location used by BYE510 (or greater) to determine if the DISKLOG is currently on or off. This location must agree with the one set in BYE510. Not defined or used if DSKLOG is NO. BSPEED The baud rate indicator set by BYE when a call is received. Usually used by KMD, ZMD, RDIR and RDIRL to indicate transfer times, this address is used by PBYE to determine the bit rate written for each user in the CALLERS file.MXDRV Usually, a byte that already exists in BYE. Similar to MXUSR, this address is needed by PBBS to set the highest accessible drive. Set to JUNK for plain vanilla CP/M. Not used if ZCPR3 is YES. WHEEL Address of the wheel byte in your system. In PBBS, this value is set to non-zero when Sysop exits to CP/M and set to zero (by BYE5xx) when he logs-out. Set to JUNK if you are using plain vanilla CP/M. Not used if ZCPR3 is YES. MXUSR This is the byte in BYE that controls the highest accessible user area for a particular user. Set to JUNK if you are using plain vanilla CP/M. Not used if ZCPR3 is YES. LOGSTR Is the address at which the user's log-in time in 8 byte, null-terminated, ASCII format (hh:mm:ss) is stored. Used for elapsed time calculations. UPLOADS KMD or ZMD can update this location which is initialized by PBBS and used by PBYE to update the user's record (counts uploads to system). DNLOADS See above (UPLOADS) (counts downloads from system). ASCACC This address is filled with the ASCII equivalent of the user's access level. This is primarily to accommodate those converting to PBBS from RBBS who have many files that look for an ASCII value. If this memory location is set, PBYE will use the value at this location to reset the user's access level. This can be used for TWIT traps in the CP/M area. PRVATE If the private switch is YES, PBBS will prevent new users from entering the system. The next three switches only take effect when PRVATE: is YES. PLOGUSR If this switch is YES, new users are added to the user base prior to being logged off the system. The new user's level is set to 2, and all subsequent log-ins will immediately send him to the PRIVATE log-out routines. The Sysop must manually increase the user's level to allow him onto the system. PRVTXT If this switch is YES, PBBS will display a text file to the new user prior to logging him off the system without adding him to the user base. The name of this text file should be entered at the label PRVTFL:. PRVCOM If this switch is YES, PBBS will release control to a COM file, which is expected to exit through BYE5xx. This file name should be entered at the label PRVTCM:. MDOS If your system supports both uploads for more than one operating system and you put those uploads into different user areas, you may wish to have your users taken to the DU corresponding to the operating system in which they are interested. If so, set this equate to YES. When a new user logs-in, he will be shown a menu of available operating system (or areas of interest) and asked to select the one in which he is primarily interested. His initial drive/user (in USERS.PBS) will be set to the appropriate value (see below). When he exits PBBS (to CP/M), he will arrive in the upload area for his selected O/S. This can be a very powerful feature when coupled with ZMD's multiple upload area feature. NMDOS This EQUate defines the maximum number of areas that you support. Make sure that you enter the same number of names in PBBSDB.HDR as you set here! NMFLDRS The number of message folders used on your system. See the special section 'Multiple Message Folders' later in this document. The next 4 labels define the location of various system files: SYSUSR This is the user area where your PBYE.COM, PMAINT.COM, *.PBS, NEWS and BULLETIN files will reside. This user area is logged to when PBBS first runs. This allows the ZCPR default user area to work with 'secondary' files after PBBS is running. SYSDRV This is the drive that is used for the above system files user area. TCPDRV The drive on which to find your ZCPR3 or ZRDOS terminal definition file. Not used if TCAP is NO. TCPUSR The user area on which to find your terminal definition file. Not used if TCAP is NO. The next five bytes are the CHAT flags for both PBBS and PCHAT. See the special section 'Chat Configuration Table' later in this document. SYSOK If this EQUate is YES, then the Sysop may log in as 'SYSOP' rather than using his real first and last name. EDATE This defines the order in which date information is displayed bye the [N] (new files) command of PBBS. If EDATE is YES, dates are shown as dd/mm/yy, otherwise, they are shown as mm/dd/yy. This EQUate only affects the new files display and the entry of a new 'last logon' date in PMAINT's Maintain Users Files routine. All other dates are shown as 'dd mmm yy', where mmm is a 3 character name of the month.The next section allows the Sysop to define which of three host file transfer programs (ZMD, KMD or XMODEM) that he is using and to control whether a user can upload or download using that program (if the ACCESS check in the program is enabled). You will need to determine the offset to the location of the access byte in BYE (21 for BYE510) and determine at what level you wish to grant access to the functions. ZMD Set to YES if you are using ZMD for your file transfers or if you are using KMD with only one log file and one FOR file. KMD Set to YES if you are using KMD with two separate log and FOR files (one for CP/M and one for MS-DOS). XMD Set to YES if you are using XMODEM for file transfers. BYEACC Offset from boot to ACCESS byte in BYE XMACC YES causes PBBS to set access levels for ZMD/KMD to check. NO disables this function. XMLVL The level at which user gains access to the ZMD/KMD functions defined by XMOK. Not used if XMACC is NO. XMMSG Set to YES to allow users to upload messages to your message base using ZMD's RM function. PMSG.COM must be available in order to use this option. DELFIL Set to YES if you wish PMSG to delete the message file after its contents have been appended to the message base. ENTMSG Do not change this equate! Only used if XMMSG and ZMD are YES. XMNO Functions available to a user below the level set at XMLVL. These are: 0= no access 32= download only 64= upload only 96= both upload and download XMOK Functions available to user at or above the level set at XMLVL (see above for values). XMRATIO This value is set by PBBS based on the 5th byte of the access table. DO NOT set it here! NOTE: If you are using XMODEM and wish to implement upload/download ratios, you MAY have to modify some of the equates in XMODEM since this function was only available for MBBS prior to XMDM124. SET25 If this EQUate is YES, PBBS will display the current caller information on your 25th line. DEL25 If this EQUate is YES, the 25th line is cleared between callers. If NO, the last caller will remain displayed on the 25th line between calls. Be sure to set SP57: in PBBSDB.HDR. This completes the settings for PBBSEQU.HDR. b) PBBSDB.HDR JUNK: This label MUST be defined as a 2 byte SAFE location, since PBBS uses it for temporary storage CPLUS: If set to 1, PBBS will use a special chain routine required by CP/M+ (CP/M 3.x) systems to run the entry to CP/M files. EXTCL: If the external command line switch is ON (set to 1), a different chaining routine is used to run the .COM files selected and you must provide the base address of the external command line buffer at MCLBUF. SETCCP: If the SETCCP switch is ON (set to 1), PBBS will not try to calculate the location of your CCP, but will use the value you have entered at CCPLOC. Some systems have CCP's in strange locations, so this will accommodate them. You must provide the base address of the beginning of your CCP, obtained from SYSTEM.COM, PROBE.COM, TELL.COM or another similar program. ZCMD: If set to 1, PBBS will use a slightly different chaining method for the enter CP/M files. If you are using ZCMD25 or above you must set this to 1 for your system to work properly. TZONE: This four character string is the abbreviation for the time zone in which your RCP/M is located. Don't forget the trailing space and the terminating zero! The next twenty-six bytes are the access, user map and drive map tables for PBBS. See the special section 'Access Level Options ' later in this document. The next section is the multiple folders section of PBBSDB.HDR. See the special section 'Multiple Message Folders' later in this document. The next section is the multiple area section of PBBSDB.HDR. It contains the names and assigned drive/user areas for each of the multiple areas that you wish to use. If you only want one area, then set MDOS to NO and set DRV0: and USR0: to the default drive/user for your system. If you want two areas (CP/M and MS- DOS, say), set MDOS to YES and NMDOS to 2. Then set DRV0:, USR0:, DRV1: and USR1: to the appropriate values. You may edit DU1: to be a different name if you wish. DU1 thru DU15 The names of up to 15 different areas that you can define for your system. Make sure that each name is terminated with a zero and that you have defined enough names for the areas that you wish to use. DRV0 thru DRV15 The drive used for each of your defined areas. Make sure that each drive defined is valid for your system. USR0 thru USR15 The user area used for each of your defined areas. Make sure that each user area defined is not private on your system. ERRUSR: This is the user area where your BYE.COM file will reside. This user area is logged to when PBBS encounters an error or the user asks to quit. This allows PBBS to exit through the BYE.COM file and always update the user file. ERRDRV: This is the drive that is used for the above error file user area (A:=0, B:=1, etc.). NOTE: The file names marked with an asterisk (*) should be left as they are to insure compatibility with future utilities to be released for use with PBBS. LABEL DEFAULT COMMENTS BULLETIN: *BULLETIN.PBS File containing bulletins of interest to system users. CALLRS: *CALLERS List of previous callers to the system. COMMENTS: *COMMENTS Messages from PBBS to the Sysop. This file contains a record of Sysop log-ins, attempted log-ins by TWITS, log-in failures by existing users (or break-in attempts), the number of users and messages deleted each night and a list of those users. INDEX: *INDEX.PBS Contains main system counters and dates. LASTCAL: *LASTCALR File containing the name of the latest caller. MSGS: *MESSAGES.PBS Main message file. All messages (includ- ing comments to the Sysop) are stored here. MINDEX: *MSGINDEX.PBS Index to main message file. NEWS: *NEWS NEWS menu for PBBS (text) NEWSEXT: na Storage for name of selected NEWS file. Do not change. LABEL DEFAULT COMMENTS NEWSERR: *NEWSERR.PBS Name of file to print if user selects a NEWS file which cannot be found (text). ONEMENU: *ONEMENU.PBS Single menu for PBBS (text). Not used if ONEMNU is NO. MAILMENU: *MAILMENU.PBS MAIL menu for PBBS (text). Not used if ONEMNU is YES. PBBSMENU: *PBBSMENU.PBS PBBS (main) menu for PBBS (text). Not used if ONEMNU is YES. PRVTFIL: *PRIVATE.PBS The name of the text file to be shown to new users who try to log-in to a private system. Only used if PRVATE and PRVTXT are both YES. TCPNAM: Z3TCAP.TCP The name of your terminal definition file. Only used if TCAP is YES. USERS: *USERS.PBS System user file. This file contains names, passwords and all other inform- ation for each user. WELCOM: *WELCOME.PBS Text file shown to every user, before he is asked to log-in. WHATSFOR: FOR Uploads description file. Created by ZMD, KMD or XMODEM. Edit this name to suit your file transfer program. WHATSFF8: FOROLD Second uploads description file. Not use is FOR8 is NO. XMODEM: ZMD.LOG ZMD, KMD or XMODEM log file. Edit to suit. NOTE: The names of the .COM files listed in PBBSDB.HDR CAN be changed as long as you insure that the length is correct and that they are NULL terminated. The following are the names of external .COM files that are chained to when a [J] (jump) to CP/M is done from PBBS: ENTRY: This is the name of the .COM file to run on normal entry to CP/M. NENTRY: This is the name of a .COM file to run when it is the first time a user has logged in. Only used if ENTY is NO. SPENTRY: This is the name of the special .COM file to run if the user access level is >= 7. Only used if SPON is YES and ENTY is NO. ALTFILE: Name of the .COM file that runs when exiting PBBS after previously re-entering it (i.e. REENTR = 1 on entry to PBBS). Only used if ALTON is YES. PRVTCM: This is the name of the .COM file to which the system will chain if you are running a private system and a new user tries to log-in. This file should exit through BYE5xx. Only used if PRVATE and PRVCOM are both YES. ERRFILE: This is the name of a .COM file (should be BYE) to run in the event of a random disk error or if a user fails to log-in in the specified number of tries or if the caller requests an end to the session. The following are the system string settings. SYSOP: Name substituted for SYSOP in messages from users to the Sysop. This name MUST be in all UPPER CASE and exactly as you entered it in the user base! SYSPATH: Path values that PBBS sets at PATH: upon exiting to CP/M if the user has an access level of COSYS (14) or PSYSP (15) and SETPATH is set to YES. PW: PASSWORD for the PMAINT program. May be upper and/or lower case. (Up to 10 characters, including nulls). LOCSTR: The name of your system, displayed upon exit from the system. Don't forget the comma. CRLFSTR: String used when a carriage return, line feed is needed. Do not change! PADSTR: PAD STRING - used to keep screen pretty. Do not change! ALLMSG: Name inserted in messages to all users - usually 'ALL'. NRDQUS: Knowledge question asked before access to CP/M is granted if KNOWON is YES. NRDANS: Answer to the above question. May be up to 10 characters. NRDPSP: Message printed if user can't answer the question. RSTMSG: Message printed if access to CP/M is restricted to validated users. Only used if RSTKON is YES. CHKTBL: Table of invalid phone numbers checked by PBBS. These three digit numbers are check first as area codes, then as exchanges. This table may be expanded or contracted if desired, but do not delete the TABEND EQUate at the end of the table. TWITMSG: TWIT MESSAGE - the system lets twits log-in and make a fool of themselves, then promptly logs them out after displaying this message. ALLWRN: WARNING OF "ALL" STATUS - users below level set at ALLLV will receive this string whenever they 'Enter' a message, indicating that they can only leave private messages. MSGWRN: WARNING OF "POST" STATUS - users below level set at POSTLV will receive this string whenever they attempt to enter a message, indicating that they cannot leave messages, except to the Sysop. The next two labels are the CHAT messages for both PBBS and PCHAT. See the special section 'Chat Configuration Table' later in this document. XMRTIO: This is the storage location for the upload/download ratios. This is set by PBBS from the user's access table and should NOT be set during configuration. DSPNUM: This is the number of callers to be displayed on the screen between callers. Only used if DSPCLR is YES. IN25: The string sent to your terminal to select the 25th line. Only used if SET25 is YES. OUT25: The string sent to your terminal to de-select the 25th line. Only used if SET25 is YES. SP57: The string sent to your terminal to clear the 25th line. Only used if DEL25 is YES. This completes the discussion of the the settings for PBBSDB.HDR. c) TCAP The TCAP option for PBBS will optionally include code within PBBS to provide support for the ZCPR3 Environment Descriptor Terminal Capabilities. The TCAP equate should be set to FALSE if you are not running with a ZCPR3 or ZRDOS based system. If you are running with one of these systems and want to provide for the setting of the terminal capabilities section of your Environment Descriptor, set the TCAP equate true and insert the name of your terminal definition file at the label TCPNAM: (Z3TCAP.TCP for Z3 default). The drive and user area where this file may be found should be entered at the labels TCPDRV: and TCPUSR:, respectively. You MUST also provide the beginning address of your ZCPR3 Environment Descriptor at the label SYSENV. If you implement the TCAP option, PBBS will display a multiple page menu of terminal types (based on the size of your Z3TCAP.TCP file) to a new user when he first calls the system, and request that he select the appropriate terminal definition from the menu(s) provided. On this and ALL following calls, PBBS will automatically load your Z3 Environment Descriptor Terminal Capabilities with the user's terminal definition. In addition, if TCAP is TRUE, the option to confirm/change the user's Terminal selection will be included as an option on the User Statistics display from the PBBS main menu. Although PBBS does not currently make use of the Z3 Terminal definition, many of your Z3 utilities do, and this is an easy way of customizing the system to support direct cursor movement and highlighting on the user's terminal. d) Multiple Message Folders A major enhancement with the release of PBBS V3.0 was the ability of the system to support multiple mail folders. This ability provides you with the option of running PBBS with a single message base containing just one subject area, or running PBBS with up to 9 subject areas. The inclusion of multiple folders is accomplished by setting the value of the NMFLDRS EQUate to a value other than 1. The size of the PBBS object file will increase slightly if you are running with 2 or more folders. The folder names, number of folders (up to a maximum of 9), and user folder access can easily be controlled by optional settings within the PBBSEQU.HDR and PBBSDB.HDR files, and with optional code assembled into PMAINT. If you decide to run PBBS with multiple folders, you will need to modify the PBBSEQU.HDR and PBBSDB.HDR files in 3 key areas, these areas and the modifications required are defined as follows: 1. Selection of the number of folders to be implemented. Set the value of the NMFLDRS EQUate to a value from 2 to 9. If you select a value less than 1 or greater than 9, your assembler will generate an error message. 2. Enter the names of your folders as text strings (in quotes) at the labels FNAME2 thru FNAME9. The names you enter MUST not be GREATER than 15 characters in length. The GENSTR macro will add an ending null and pad any names that are less than 15 characters in length with nulls. DO NOT CHANGE the string at FNAMES. It is also suggested that you DO NOT change the name at FNAME1. 3. Enter the LOWEST user access level that a user can be to gain access to a given folder for folders 2 thru 9 at the label MAILTBL. As part of the autobump process, PBBS will check the user's access level against the MAILTBL and grant the user access to all folders with an access level equal to or lower than his current level, EXCEPT if the Sysop has blocked the user from having access to a folder(s) by use of the PMAINT folder access function. The Sysop can also GRANT a user access to any folder HIGHER than the user's current access level with the same PMAINT function. PBBS will automatically set the proper flags for access to folders on the first log-in to the system, thus the Sysop does not need to manually set the access bits, except to BLOCK or GRANT access to special users. The following code, extracted from PBBSEQU.HDR and PBBSDB.HDR, shows an example of a version of PBBS with 8 mail folders. Folders 1 thru 3 are open to all users (access level in MAILTBL of 2), folder 4 is restricted to users with an access level of 4 or higher, folder 5 is restricted to users with an access level of 9 or higher, access to folder 6 is reserved for users with an access level of 8 or higher, folder 7 is reserved for users with an access level of 7 or higher and folder 8 for users with an access level of 2 or higher. The final folder is restricted to anyone other than the Sysop (level PSYSP or 15). This folder is, of course, not used. If a user does NOT have access to a given folder, the Folder select menu of the PBBS MAIL sub-menu will not even display the folder name, so a user won't even know it exists. The Folder selection menu is changed dynamically each time PBBS is loaded, so as the user's access level changes, new folder options will appear. Also, if an additional, new folder is added, all users who have a high enough level to gain access to it will be granted that access the next time they log-in. .po 4 e) Multiple Folders Code Sample ;----------------------------------------------------------------------- ; If PBBS is to handle multiple message bases (up to 9), you MUST assign ; a number to NMFLDRS. If you want a standard PBBS (single message base) ; NMFLDRS MUST be set to 1. If you want multiple message bases, then set ; NMFLDRS for any value from 2 thru 9. You must update the folder names ; at label FNAMES and set the values in MAILTBL (both in PBBSDB.HDR). ;----------------------------------------------------------------------- NMFLDRS EQU 8 ; Number of folders active (max = 9) ;-------------------------------------------------------------------- ; If you have implemented the multiple folder option, then you MUST ; provide the external names of your MESSAGE folders below. Each name ; MUST be 15 bytes in length OR LESS. The GENSTR MACRO will pad each ; name with the proper nulls. The code at FNAMCHK will generate an ; assembly error message if the folders are not the correct length. ;-------------------------------------------------------------------- IF (NMFLDRS GT 1) FNAMES: DB '0. Global (all folders)',0 ; Folder 0 name ; NOTE! DO NOT CHANGE THE ABOVE LINE OF CODE!!! FNAME1: GENSTR 'General ' ; Folder 1 name ; NOTE! IT IS RECOMMENDED THAT YOU NOT CHANGE THE NAME ABOVE ; IF YOU ARE RUNNING WITH ONLY 1 MAIL FOLDER!!! ; NOTE: The GENSTR MACRO will create the required string for this ; table. If you change the names, the string after the GENSTR ; MACRO command must be at least 1 but less than 16 characters. FNAME2: GENSTR 'PCPI/CardZ180' ; Folder 2 name FNAME3: GENSTR 'Want Ads' ; Folder 3 name FNAME4: GENSTR 'PBBS' ; Folder 4 name FNAME5: GENSTR 'PBBS Beta' ; Folder 5 name FNAME6: GENSTR 'Special' ; Folder 6 name FNAME7: GENSTR 'Sysops' ; Folder 7 name FNAME8: GENSTR 'Technical' ; Folder 8 name FNAME9: GENSTR 'NOT USED' ; Folder 9 name ; NOTE: Do not change the number of entries in the following table. ; Even if you are not running with multiple mail folders, change ; ONLY the individual DB values. If you change the table length ; or basic definition, the mail functions will probably NOT work! MAILTBL:DB 02 ; Lowest user value to use mail folder 2 DB 02 ; Lowest user value to use mail folder 3 DB 04 ; Lowest user value to use mail folder 4 DB 09 ; Lowest user value to use mail folder 5 DB 08 ; Lowest user value to use mail folder 6 DB 07 ; Lowest user value to use mail folder 7 DB 02 ; Lowest user value to use mail folder 8 DB PSYSP ; Lowest user value to use mail folder 9 ENDIF ; (MFLDRS GT 1).uj on f) Chat Configuration Table These EQUates, all found in PBBSEQU.HDR, should be pretty self explanatory. If you want to use only the BYE bell flag to trigger CHAT set CHTBYE to 1, CHAT0 to 0 and CHAT1 to 24. CHTBYE If this EQUate is YES, PBBS will check the BYE5xx bell flag to see if CHATting is allowed at this time. COYAK If this EQUate is YES, PBBS will allow a co-Sysop to page the Sysop at any time, regardless of the settings of CHAT0 and CHAT1. ALERT Number of times to ring the bell before assuming that the Sysop has gone to bed. CHAT0 CHAT allowed only after this hour. CHAT1 CHAT allowed only before this hour. Note that both times must be in military (24 hr) time (i.e. 0=12 midnight, 17=5:00 pm, etc.). The last one is a DB, found in PBBSDB.HDR. NOCHAT: Message sent to user if the CHAT request is outside allowed hours. g) Access Level Options The access table has 5 bytes for each access level. The first byte is the maximum drive accessible by a user (A:=1, B:=2, etc.), the next is the maximum user area+1, next the number of minutes allowed on-line (0 = unlimited), next the number of days that the record is allowed to age before being deleted from the database during the automatic update (if 0 then no auto-delete takes place). The last byte is the XMODEM upload/download ratio value. If you are using ZMD, KMD or XMODEM to restrict users from downloading, this value may be set to the ratio at which the user loses download access. A zero in this location defeats the ratio checking code. An example might look like this: DB 3,11,45,30,10 where 3 means that the user has access up to drive C:, 11 means that he has access up to user area 10, 45 means that he is allowed 45 minutes per day on the system, 30 means that he must call again within 30 days to avoid being automatically deleted from the system and 10 means that for every 10 files that he downloads, he must upload at least 1 file. An extension to the access table is the individual user and drive maps. Each level from 2 to 14 has its own individual user area map and its own drive map. In these maps, a 1 indicates that the user has access to that user area or drive and a 0 indicates that the user does not have access to that area or drive. While PBBS does not use these maps directly, it will maintain the correct two maps in each user record (in USERS.PBS) and will load those maps into the memory defined by USRMAP and DRVMAP each time the user logs in, where other programs may use them. ACC2 thru ACC15 Access table of each level. Contains maximum drive, maximum user, time allowed on system, days till deletion and upload/download ratio for each level. USMP2 thru USMP14 User area map for each valid level except the Sysop (who is always assumed to have no restrictions). DRMP2 thru DRMP14 Drive map for each valid level except Sysop (who is assumed to have no restrictions). VI. Appendix A - Description of PBBS file structures The file structure for each of the files is as follows: 1. MSGINDEX.PBS ..... Total=128 bytes/record .....30 bytes - name of message receiver (0 padded) ..... 2 bytes - message number ..... 3 bytes - date message left (binary mdy) ..... 1 byte - number of records (=lines) in message (64 bytes/record) ..... 2 bytes - starting record number in MESSAGES.PBS ..... 2 bytes - record number in MSGINDEX.PBS .....26 bytes - message subject (0 padded) .....30 bytes - name of message sender (0 padded) ..... 1 byte - public/private flag ..... 1 byte - folder number ..... 1 byte - msg status (read=1, unread=0, deleted=-1) ..... 1 byte - unused at this time ..... 3 bytes - time message left (binary hms) ..... 1 byte - message retention length .....16 bytes - message threading pointers ..... 8 bytes - unused at this time 2. INDEX.PBS ..... Total=128 bytes/record ..... 3 bytes - binary date (mdy) ..... 2 bytes - next record number for message if space not free ..... 2 bytes - number of next message ..... 2 bytes - number of records in MDGINDEX.PBS ..... 2 bytes - number of callers to the system ..... 2 bytes - number of system users ..... 3 bytes - not used ..... 1 byte - hard-copy on =1 , off =0 ..... 3 bytes - last date user file maintained ..... 3 bytes - last time user file maintained ..... 3 bytes - last date messages file maintained ..... 3 bytes - last time messages file maintained ..... 2 bytes - daily system usage (minutes) ..... 1 byte - daily call count ..... 1 byte - current day's percentage ..... 1 byte - previous day's percentage ..... 1 byte - current day (binary) .....65 bytes - unused at this time 3. USERS.PBS ..... Total=128 bytes/record ..... 1 byte - free record flag ( 0=free) .....30 bytes - firstname lastname (0 padded) .....20 bytes - city/state/province (0 padded) .....10 bytes - password (0 padded) .....12 bytes - phone number (###-###-####) ..... 2 bytes - number of times on ..... 3 bytes - date last on (binary mdy) ..... 1 byte - access level ..... 1 byte - mail waiting flag (1=mail, 0=no mail) ..... 1 byte - initial drive/user ..... 1 byte - number of nulls user needs ..... 1 byte - last on baudrate (read from BSPEED) ..... 2 bytes - number of uploads ..... 2 bytes - number of downloads ..... 2 bytes - user area map ..... 2 bytes - drive map ..... 1 byte - terminal code ..... 1 byte - total time on line ..... 2 bytes - highest msg. # read ..... 2 bytes - multiple folder access information ..... 1 byte - screen width ..... 1 byte - bit flags (see below) .....29 bytes - unused at this time NOTES: 1) See Appendix B for specific information concerning multiple message bytes. 2) The bit flags are defined as follows: Bit Purpose 0 Registration - 0 = not filled out 1 "[more]" toggle - 0 = on 2 Expert mode - 0 = off 3 New User - 0 = yes 4 Hotkey - 0 = use hotkeys 5 Undefined 6 Undefined 7 Undefined NOTE: Bit 0 (registration) and Bit 3 (new user) are not yet implemented, but those bits are reserved for future PBBS enhancements. 4. MESSAGES.PBS ..... Total=64 bytes/record .....64 bytes - one line of message (0 padded) 5. CALLERS.PBS ..... Total=64 bytes/record ..... 5 bytes - date (dd/mm) ..... 1 byte - space ..... 5 bytes - log-in time (hh:mm) ..... 1 byte - dash (-) ..... 5 bytes - log-out time (hh:mm) ..... 1 byte - space ..... 1 byte - '@' ..... 1 byte - space ..... 4 bytes - speed ..... 1 byte - space .....18 bytes - name (space filled) ..... 1 byte - space .....20 bytes - city and state/province (space filled) 6. LASTCALR ..... x bytes for first name ..... 1 byte for a comma (,) ..... x bytes for last name ..... 1 byte for carriage return ..... 1 byte for linefeed ..... 1 byte for ^Z (end-of-file marker) This page intentionally left blank VII. Appendix B - User Profile for Multiple Folders The inclusion of the Multiple Folders option has required a change to the field definitions of the USERS.PBS and MSGINDEX.PBS records. The changes are: USERS.PBS - A two byte field (UFACC) has been defined in the user record. These two bytes work together and contain a bit map that contains the user's mail folder access level. The first byte of UFACC is used to signal to PBBS that the Sysop has BLOCKED the user from having access to a folder. If the corresponding bit in this field is a 1, the user does NOT have access to the folder, and in fact will NEVER have access unless the Sysop uses PBBSMNT to remove this restriction. The second byte of UFACC provides a flag for folder access. If the corresponding bit in the first byte is a zero, then the presence of a 1 in this bit indicates that the user has access to the folder. At each log-in, PBBS checks the user's access level against the values defined in the MAILTBL for each folder and if the blocked bit is NOT set, will set the access bit to a 1 if the user's access level is greater than or equal to the MAILTBL minimum access level. It is possible to grant a user access to a folder that would normally require a higher access level than he has obtained by using PBBSMNT to GRANT access to a folder. The BITS for both bytes in the UFACC field are defined as follows: Bit 0 folder-2 Bit 1 folder-3 Bit 2 folder-4 Bit 3 folder-5 Bit 4 folder-6 Bit 5 folder-7 Bit 6 folder-8 Bit 7 folder-9 An example of one possible value is: UFACC (first byte) 00100000 UFACC (second byte) 00010011 In the example, the user has been blocked from having access to folder 7, has been granted access to folder 6, and has been given access to folders 2 and 3 by the PBBS auto-bump process. A new field, MFNUM, has been defined in the MSGINDEX record. This field requires 1 byte, and is used to hold the folder number for the message. Valid values for this field are 1 thru 9. Sysops converting from PBBS versions prior to v3.0 should contact the author for information on how to provide compatibility with PBBS v5.0 and later releases. This page intentionally left blank VIII. Appendix C - Sample PBBS Menus The following are samples of the two (or three) menus used by PBBS (as used by the Information Centre RCP/M in Ottawa, Canada). These are suggestions only, but remember that if your menus are similar to these, then experienced PBBS users will feel right at home, even the first time that they log-in. First is the menu used if only one menu is used (ONEMNU is YES). -------------------------====={ }=====------------------------- MENU Yourveryown RCP/M (PBBS) [R] Read Public Messages [P] Private Message Read [S] Search for Messages [H] Header Scan of Message Base [E] Enter a Message [V] View Messages Left by You [F] Folder Change [>] Select Next & [<] Previous Folder [L] List Users [B] Bulletin Display [C] Caller List (Previous 18) [I] Information/News Articles [N] New Files (Recent Uploads) [D] Description of New Files [W] Write a Note to Sysop [U] User Profile (Settings) [G] Goodbye (logoff) [J] Jump to the File System [T] Toggle [more] Prompt [X] eXpert Mode Toggle (Menu On/Off) [Y] Yak with Sysop [?] Display Menu Once NOTE: All folders are Read/Scanned from GLOBAL folder > and < only work from folders other than GLOBAL This is the first (non-mail) menu used if two menus are desired (ONEMNU is NO). -------------------------====={ }=====------------------------- PBBS MENU Yourveryown RCP/M (PBBS) [B] Bulletin Display [C] Caller List (Previous 18) [L] List Users [I] Information/News Articles [N] New Files (Recent Uploads) [D] Description of New Files [W] Write a Note to Sysop [U] User Profile (Settings) *[M] Go to Mail Menu [G] Goodbye (logoff) [J] Jump to the File System [T] Toggle [more] Prompt [X] eXpert Mode Toggle (Menu On/Off) [Y] Yak with Sysop [?] Display Menu Once * This invokes the Mail Section for messages. .po 8 This is the second (mail) menu used if two menus are desired (ONEMNU is NO). -------------------------====={ }=====------------------------- MAIL MENU Yourveryown RCP/M (PBBS) [R] Read Public Messages [P] Private Message Read [S] Search Message Subjects [H] Header Scan of Message Base [E] Enter a Message [V] View Messages Left by You [F] Folder Change [>] Select Next (Higher) Mail Folder [<] Select Previous (Lower) Mail Folder [G] Goodbye (logoff) [J] Jump to the File System [T] Toggle [more] Prompt [X] eXpert Mode Toggle (Menu On/Off) [M] Go to PBBS Menu [?] Display Menu Once NOTE: All folders are Read/Scanned from GLOBAL folder > and < only work from folders other than GLOBAL This is the menu used when a user invokes the [I] command to read the Information/News files. -------------------------====={ }=====------------------------- NEWS FILE MENU Yourveryown RCP/M (PBBS) The following NEWS files are active: [A] Policies of this Board [B] Validation Information [C] New User Information [D] PBBS Access Levels [E] CP/M Commands [F] Using .LBR Files [G] New Software [H] The 10 Commandments [I] PBBS Summary [J] PBBS Details [K] Sysop Gripes Which NEWS file (A - K) or IX. Appendix D - PBBS Utilities There are two utilities available for use by PBBS Sysops supported along with the main PBBS package. Unfortunately, at the time of this release, they have not been updated to support PBBS 5.0. These utilities will be updated as soon as possible and be release. Please watch for PUSER50.LBR and PSTAT50.LBR. Following is a brief description of the two utilities. Both will have their own documentation files when they are released. 1. PUSER50.LBR PUSER is a PBBS utility designed to print the entire user list on the screen or the printer. It is a dual purpose utility, designed to operate in one of two different modes. The first mode is as a stand alone utility for the remote user that will display the name, city and province/state and last log- in date of each user in the user base. In the second mode, the program checks the wheel byte defined in PBBSHDR. If set, the user will be asked where he wishes output to be routed. He may either send it to the display of the printer. When sending to the display, the output will be the same as above, but will include each user's telephone number. When sending to the printer, the output shows all the information contained in the user record except terminal ID code and message folder access. The generated report is identical to the printout of early versions of PBBSULST.BAS. PUSER is written entirely in assembler, making it smaller than the compiled version of PBBSULST.BAS and faster than the interpreted version. All source code is provided. PUSER was written by Terry Pinto of Access Programming RAS. 2. PSTAT50.LBR PSTAT is a PBBS utility designed to display the various settings within PBBS. These are the settings you chose when assembling a bulletin board system. Many times during the assembly of your BBS and the various support utilities used on a remote system, you will have had to refer to many, many pages of printouts to get the address of a particular byte in low memory or to get the name of the file you decided that you'd use as an exit alias. This prolongs the installation of your system. PSTAT will make it possible to examine all of those user defined settings. This program will operate in one of two modes. You may specify a selected option on the command line or elect to run in the menu mode. In both modes, there is a complete help screen available. SYNTAX: PSTAT -or- PSTAT /o Options: A - Access Tables B - Drive/User Bitmaps D - DU: Selections E - Entry/Welcome Files F - Mail Folders I - INDEX.PBS Information L - Low Memory Addresses M - Message Statistics O - Operating System and PBBS P - PBBS Internal Settings R - Restrictions S - System Files V - Version Number & System Information Z - Z-System ? / - Help X - Exit (Menu Mode ONLY) When called with one of the above options, PSTAT will display the needed information and exit to the operating system. If no options are supplied on the command line, PSTAT will run in the menu mode of operation. While running under menu control, the selected information is displayed giving the user a 'Press to Continue ...' prompt and when done control is returned to the menu processor. PSTAT requires that BYE be operational and, with certain options selected, PBBS be running. Some information, such as that in low memory, does not make any sense unless PBBS has set these bytes. In these cases, a check is made of the REENTR byte to see if PBBS has been loaded. If this byte is not set, the user will be given an error message and when loaded in the menu mode, operation is returned to the menu processor. If in the option mode, control is given back to the user by exiting to the system. PUSER was written by Terry Pinto of Access Programming RAS. X. Appendix E - Acknowledgements I would like to thank all of the contributors to the further development of PBBS. I would especially like to thank the following individuals (in alphabetical order): David Bowerman For the terminal line selection and support code. For the new DEFYES and DEFNO subroutines. For the new CALTIM routine. For several enhancements to the PBBSUBS.REL file. For many minor fixes too numerous to mention here. Ben Grey For numerous enhancements and fixes to the PMSG program. For many minor fixes too numerous to mention here. Terry Pinto For the basic threading code used in PBBS For constant attention to the ZCPR sections of PBBS. For many minor fixes too numerous to mention here. The following individuals have contributed immensely to the further development of PBBS by being official beta test sites. Each sysop listed had to put his system through a series of grueling tests and had to cope with constant updates (and with my mistakes, foul-ups and general bumbling!). To each and every one, a sincere thank you. * David Bowerman Vancouver, BC. David Chapman Victoria, BC. * Ben Grey Portland, OR. Dennis Lunsford Bellevue, WA. * Terry Pinto Beaverton, OR. Walt Stumper St. Louis, MO. Rick Swenton Bristol, CT. George Worley Houston, TX. * major Source code contributors. To the countless users (both on my own system and on the beta systems) whose suggestions and criticisms (always good natured and often with humour) have helped to whip PBBS into shape (and to keep me feeling suitably humble!). Particularly to the local users of the Information Centre who have not only had to contend with constant beta versions, but with some rather horrendous alpha versions as well. To all of these, a thank you, because you weren't volunteers, but draftees! And to my wife, Nadine, who put up with my late nights, sometimes bad humour and my inflated phone bill! And who, once again, helped me immeasurably with the style and overall look of this document, a very special thank you. - Ian Cottrell October 09/90 XI. Appendix F - PBBSUBS.REL subroutines PBBSUBS V5.00 These are the subroutines used by the PBBS system of programs. No sources will be released for these routines, questions should be directed to The Information Centre RCP/M at (613) 952-2289 (data line) or (613) 829-1650 (voice). The following is a listing of all routines contained within the PBBSUBS.REL file. Each listing contains a description of the routine, its input and output conditions and any special conditions or alternate entry points. The list is arranged in alphabetical order. ----------------------------------------------------------------- 1. BFCB: Build an FCB (at the default CP/M FCB [05CH]) from a string pointed to by HL. No arguments are returned. Call BFCB1:, with DE pointing to the FCB location, to use your own FCB. ----------------------------------------------------------------- 2. BFCB2: Build an FCB (at FCB2:) from string pointed to by HL. FCB2 is equated internally. ----------------------------------------------------------------- 3. CAPS: Capitalize character in A, if possible. Capitalized letter returned in A. ----------------------------------------------------------------- 4. CDATE: Convert date at label DATE:: from ASCII (MM/DD/YY) to binary at BDATE: (MDY). No arguments returned. ----------------------------------------------------------------- 5. CLOSE: Close file in current FCB. Destroys DE and C. ----------------------------------------------------------------- 6. CLOSE2: Close file in current FCB2. Destroys DE and C. ----------------------------------------------------------------- 7. CNVRT0: Convert up to 5 ASCII digits (0-9) to binary number in HL. By storing a value from 1-5 at CNVRT0+1 before calling CNVRT0:, you can convert that number of characters. A call to CTIME: or CDATE: will set this value to 2. On entry, IX points to digit string to convert. ----------------------------------------------------------------- 8. COPEN: Special open file whose name pointed to by HL register. Creates file if it is not found. Uses FCB:. ----------------------------------------------------------------- 9. CPM: Enter CP/M via file pointed to by DE. NOTE: make sure you have enough TPA!! If EXTCL is 1, then uses external command buffer supplied as MCLBUF or if EXTCL is 0, then uses CCP calculated from BIOS base page address. If SETCCP is 1, uses offset from CCPLOC. If ZCMD is set, a special operation is performed to accommodate ZCMD's way of handling the default command buffer. If CPMPLUS is set, a special CP/M+ routine handles the chaining to the exit file. ----------------------------------------------------------------- 10. CTIME: Convert time at label TIME: from ASCII (HH:MM:SS) to binary at BTIME: (HMS). ----------------------------------------------------------------- 11. DATDIF: Calculates the difference between two dates (compensates for leap years). IX = earlier date (in binary - three bytes) IY = later date (in binary - three bytes) Difference in days returned in HL. ----------------------------------------------------------------- 12. DIV16 Divides 2 16-bit integers. HL = HL/DE; DE = remainder. Enter at DIV16A: to divide by 10 (decimal). ----------------------------------------------------------------- 13. DOBS Erase an unwanted character by printing a backspace, a space and then another backspace. ----------------------------------------------------------------- 14. ECHO Echo character in A to console. ----------------------------------------------------------------- 15. @ECHO Echo character in A to console and optionally to LST: device (if SYSLOG is on). ----------------------------------------------------------------- 16. ENDPBS Any routines that use a link to PBBSUBS and want to use buffer space at the end of the program MUST call this routine at the start of the program to determine the end address of the program. This routine returns (in the HL register pair) the address of the first free byte above the program. ----------------------------------------------------------------- 17. FILLHL Fill HL register pair with the contents of (DE). L = byte from (DE), H = byte from (DE + 1). ----------------------------------------------------------------- 18. FULDAT Print a 3 digit binary date as 'dd mmm yy' where dd is the day, yy is the year and mmm is a 3 character abbreviation for the month (Jan, Feb, etc.). On entry, IX points to the binary date. ----------------------------------------------------------------- 19. GETCH Returns a character from the console in the A register. If no character is there, wait for one (forever, if necessary!). This routine uses the BDOS direct console I/O routines to avoid echoing the character. Preserves the IX and IY registers. ----------------------------------------------------------------- 20. GTCHCR Same at the above routine (GETCH:) except that it waits for a carriage return before returning to caller. This routine is used for those users who do not use 'hotkeys'. ----------------------------------------------------------------- 21. INPUT Get input string from user; maximum length in B. If C=20H, then force upper case, C=0 no upper. If D=0 then no word wrap, D=1 then wrap on space after 50th character. If A=0 then echo input characters, A=1 no echo. On exit, A = length entered, HL = start of buffer. ----------------------------------------------------------------- 22. IOPEN Open the index file (usually INDEX.PBS). Set the record number to 0. Destroys HL. ----------------------------------------------------------------- 23. MATCH String match, HL=string1, DE=string2, B=length to search on. On exit, strings are equal if A=0. ----------------------------------------------------------------- 24. MIOPEN Open the message index file (usually MSGINDEX.PBS). Set the record number to 0. Destroys HL. ----------------------------------------------------------------- 25. MLDL Multiply HL times DE, product returned in HL, where HL = multiplicand, DE = multiplier. ----------------------------------------------------------------- 26. MOV2DT Move a filename from (DE) to (HL) up to (but not including) the dot separating the filename and the extent. Also terminate on a space or a zero. On input DE = source, HL = destination. ----------------------------------------------------------------- 27. MOVE Move C bytes from HL to DE. ----------------------------------------------------------------- 28. MOVNM Move B bytes from HL to DE, setting the first character of each word to upper case, all others to lower case. A dash (-) is considered a word separator. Used mainly for moving names (stored in USERS.PBS in all upper case) in mixed case. ----------------------------------------------------------------- 29. MSGOPN Open the messages file (usually MESSAGES.PBS). Set the record number to 0. Destroys HL. ----------------------------------------------------------------- 30. OPEN Open a file whose name is pointed to by the HL register. File name ends up in FCB:. ----------------------------------------------------------------- 31. OPENA Open a file whose name is pointed to by the HL register with no error checking (error checks should be done by the calling program upon return from this subroutine). File name ends up in FCB:. ----------------------------------------------------------------- 32. OPEN1 Open a file whose name is pointed to by the HL register. File name ends up in FCB2:. ----------------------------------------------------------------- 33. OPEN1A Open a file whose name is pointed to by the HL register with no error checking (error checks should be done by the calling program upon return from this subroutine). File name ends up in FCB2:. ----------------------------------------------------------------- 34. OPEN2 Open second file file in second FCB (erases old file first, if any). Uses FCB2:. ----------------------------------------------------------------- 35. PCRLF Print a carriage return and a linefeed. Call PCRLF1 to print a carriage return and 2 linefeeds. ----------------------------------------------------------------- 36. PA2ASC Prints binary number (<256 decimal) in A as a decimal number (includes leading zero if number is <10). ----------------------------------------------------------------- 37. PB2ASC Prints binary number in HL as decimal number with no leading zeros but does print a zero if the HL register pair contains 0. ----------------------------------------------------------------- 38. PS2ASC Prints binary number (<256 decimal) in A as a decimal number within a 3 character field (the number is right justified and the field is space filled). ----------------------------------------------------------------- 39. PRINT Print inline message (null terminated). ----------------------------------------------------------------- 40. @PRNT Print inline message (null terminated) with optional echo to LST: device (if SYSLOG is on). ----------------------------------------------------------------- 41. PRINTA Skips to first space, then prints til a zero or a space is found. The first character is printed in upper case. Used for printing a user's last name. Name pointed to by HL. ----------------------------------------------------------------- 42. PRINTL Print message pointed to by HL (null or length passed in B to end). On input, HL = message, B = max length to print. ----------------------------------------------------------------- 43. @PRNTL Print message pointed to by HL (null or length passed in B to end) with optional echo to LST: device (if SYSLOG is on). ----------------------------------------------------------------- 44. PRINTM Print message pointed to by HL (up to the first null). No counter is used by this routine. ----------------------------------------------------------------- 45. PRINTN: HL = name to print, B = max length to print. Print a user name, pointed to by HL, in upper and lower case (up to first null or characters printed equals length passed in B). Capitalize the first character of each name, including the first character after a dash (-). ----------------------------------------------------------------- 46. PRINTP Print a filename (pointed to by HL). Space fill the name to 8 characters. ----------------------------------------------------------------- 47. PRINTS Print message pointed to by HL until first space found, a null is encountered or characters printed equals length passed in B. First character is capitalized. ----------------------------------------------------------------- 48. PDATE 49. PTIME Routines to print binary date or time with the appropriate "/" or ":" separators. On entry, IX points to the 3 binary bytes. For PDATE:, if A=0 then the US date format (MM/DD/YY) is used while if A=1, the international date format (DD/MM/YY) is used. ----------------------------------------------------------------- 50. PUT Write record # in HL to file at FCB (128 bytes). 51. PUT2 As above but FCB2. 52. GET Read as PUT writes above. 53. GET2 Read as PUT2 above writes. On entry HL = record number. These routines read/write random records to the disk as commented and are used to process all PBBS files which have 128 byte records. Error handling is internal. No return to caller on error. Destroys A, HL. ----------------------------------------------------------------- 54. PUT64 Write record # in HL to file at FCB (64 bytes). 55. PUT264 As above but FCB2. 56. GET64 Read as PUT writes above. 57. GET264 Read as PUT2 above writes. On entry HL = record number. These routines read/write random records to the disk as commented and are used to process all PBBS files which have 64 byte records. Error handling is internal. No return to caller on error. Destroys A, HL. ----------------------------------------------------------------- 58. PVER Print the name, date, status (alpha, beta, etc.), date and version/revision number for a PBBS module. At the start of key PBBS files, there is a name (at label VNAME:) followed by a status name, a date (label VERDAT:) and a version and revision number (VER: and VERR: respectively) for that file. VNAME: is not null terminated and is followed directly by the status name, which is null terminated. VER: and VERR: need not follow directly, but usually do so, for convenience. A call to PVER: will print all of these in a standard format shown below: PBBS Release v 5.0 (Released 03 Oct 90) ----------------------------------------------------------------- 59. SDLR Shift DE,HL right one bit (DE,HL/2). ----------------------------------------------------------------- 60. SPBDOS Pushes the IX and IY registers, issues a BDOS call, pops the IX and IY registers and returns to the calling routine. ----------------------------------------------------------------- 61. SPINP Get a special input string (password) from user; maximum length in B. If C=20H, then force uppercase, C=0 then no upper. If D=0, then no word wrap, D=1 then wrap on space after the 50th character. If A=0, echo an asterisk (*) for each character entered, else no echo. On exit, A = length entered, HL = start of buffer.----------------------------------------------------------------- 62. SPOPEN Special open of random access file. Creates file and sets record number to 0 if no file exists. File name pointed to by HL. ----------------------------------------------------------------- 63. SUBHL Subtract HL from DE, where HL = subtrahend, DE = subtractor (carry flag ignored). On exit, HL = result. ----------------------------------------------------------------- 64. UOPEN Opens user file (usually USERS.PBS). Points to record number 0. Destroys HL. ----------------------------------------------------------------- 65. Error Messages Error routine from random operations routine will display the following error messages: ++ read unwritten error ++ BDOS Function 33, Error Code 01 ++ can't close extent error ++ BDOS Function 33, Error Code 03 ++ read unwritten extent error ++ BDOS Function 33, Error Code 04 ++ can't create new extent error ++ BDOS Function 34, Error Code 05 ++ attempted read beyond end-of-disk error ++ BDOS Function 33 or 34, Error Code 06 Each message gives a brief description of the error, the BDOS function that was being used at the time of the error, the error code returned by CP/M and then the filename in use at the time. Users should refer to the DRI CP/M manuals or other CP/M books for details of each error, referenced by the given BDOS function number.