OOOOOOOOOOOOOO OOOOOOOOOOOOOO OOOOOO OOOOOO OOOOOOOOOOOOOO OOOOOOOOOOOOOO OOOOOOOOOOOOOO OOOOOO OOOOOO OOOOOOOOOOOOOO OO OO OO OO OO OO OO OO OO OO OO OOOOOO OO OO OOOOOO OO OO OO OO OO OO OOOOOOOOOO OO OOOOOO OO OO OOOOOO OO OO OO OO OO OO OO OO OO OO OO OO OO OO OO OO OO OO OO OO OO OO OO OO OOOOOOOOOO OO OO OO OO OO OOOOOOOOOO OO OOOOOO OO OO OOOOOOOOOO OO OOOOOO OO OO OO OO OOOOOO OO OO OO OO OOOOOO OO OOOOOOOOOO OO OO OO OO OO OO OO OO OO OOOOOOOOOOOOOO OOOOOO OOOOOOOOOOOOOO OO OO OOOOOOOOOOOOOO OOOOOO OOOOOOOOOOOOOO OO OO OO OO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OO oMMM OO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO Opus Computer-Based Conversation System Version 1.70 Copyright 1986, 1987, 1989, 1990, 1991, Wynn Wagner III All Rights Reserved This version written by Doug Boone with William Beebe, Ulf Nilsson, Trev Roydhouse and John Valentyn SYSOP OPERATIONS MANUAL 14 July 1991 Documentation by Trev Roydhouse Dedicated to Tom Jennings and Ward Christensen Copyright 1991, Wynn Wagner III All Rights Reserved Page 2 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL TABLE OF CONTENTS 1.0 INTRODUCTION TO OPUS ..................................... 8 1.1 GUARANTEE ........................................... 9 1.2 USING OPUS .......................................... 9 1.3 CREDIT AND GRATITUDE ................................ 9 1.4 DOCUMENTATION, CREDITS .............................. 11 1.5 CORRECTIONS, SUGGESTIONS ............................ 12 1.6 MISCELLANEOUS ....................................... 12 2.0 OPUS V1.70 OVERVIEW ...................................... 13 2.1 WHAT IS NEW IN OPUS V1.70 ........................... 13 2.1.1 SYSTEM FILES ................................ 14 2.1.2 USER AND EVENT FILES ........................ 14 2.1.3 USER KEYBOARD MACROS ........................ 14 2.1.4 MENUS ....................................... 14 2.1.5 VERSION 7 NODELIST SUPPORT .................. 17 2.1.6 SYSTEM SECTION .............................. 17 2.1.7 LANGUAGE SECTION ............................ 18 2.1.8 EQUIPMENT SECTION ........................... 18 2.1.9 MATRIX AND ECHOMAIL SECTION ................. 18 2.1.10 SESSION SECTION ............................. 19 2.1.11 FILES DATABASE .............................. 21 2.1.12 MESSAGE AREAS ............................... 23 2.1.13 OPUS EMBEDDED COMMANDS ...................... 24 2.1.14 COMMAND LINE OPTIONS ........................ 25 2.1.15 NIELS KEYS EXTENSION ........................ 25 2.1.16 EXTERNAL PROGRAMS ........................... 25 2.1.17 ERRORLEVEL EXITS ............................ 25 2.1.18 TRULY MISCELLANEOUS ......................... 26 2.2 REQUIRED HARDWARE ................................... 26 2.3 REQUIRED SOFTWARE ................................... 27 2.4 MESSAGES ............................................ 27 2.4.1 LOCAL MESSAGES .............................. 27 2.4.2 MATRIX/NETWORK MESSAGES ..................... 27 2.4.3 ECHOMAIL MESSAGES ........................... 28 2.5 EXTENDED MESSAGE AREA ATTRIBUTES .................... 28 2.6 FILE TRANSFERS ...................................... 29 2.6.1 UPLOADS ..................................... 29 2.6.2 DOWNLOADS ................................... 29 2.6.3 MATRIX ...................................... 29 2.6.4 REQUESTS .................................... 30 2.7 EXTENDED FILE TRANSFER PROTOCOLS .................... 30 2.8 OEC FILE CAPABILITY ................................. 30 2.9 ECHOMAIL ENHANCEMENTS ............................... 31 2.10 MATRIX/NETWORK MAIL INTERFACE ....................... 31 2.11 OPUS OPERATING PHILOSOPHY ........................... 31 3.0 SETTING UP OPUS V1.70 .................................... 32 3.1 THE CONTROL FILE .................................... 32 3.1.1 CONTROL FILE MAINTENANCE .................... 33 3.1.2 THE PARAMETER FILE .......................... 33 3.1.3 FILE AND MESSAGE AREA SYSTEM FILES .......... 33 TABLE OF CONTENTS Page 3 3.1.4 MENU FILE(S) ................................ 34 3.1.5 ALL FILES ................................... 34 3.1.6 MACRO SUBSTITUTIONS ......................... 35 3.2 THE MENU SYSTEM ..................................... 36 3.2.1 CUSTOMISING MENU PROMPTS .................... 36 3.2.2 CONTROLLING ACCESS TO MENU COMMANDS ......... 36 3.2.3 DISPLAYING OEC FILES ........................ 37 3.2.4 RUNNING EXTERNAL PROGRAMS ................... 37 3.2.5 GLOBAL MENU COMMANDS ........................ 38 3.2.6 AUTOMATIC ZMODEM UPLOAD ..................... 38 3.2.7 SUPERSEDED MENU COMMANDS .................... 39 3.2.8 ALTERNATIVE MENUS ........................... 39 3.2.9 ASCII MENUS ................................. 40 3.2.10 OEC MENU PROMPTS ............................ 41 3.2.11 MENU SAFETY FEATURE ......................... 41 3.3 BOMBING RUNS ........................................ 41 3.4 IMPLEMENTING OEC FILES .............................. 42 3.4.1 QUOTATION OF THE MOMENT ..................... 43 3.4.2 PASSIVE QUESTIONNAIRES ...................... 44 3.4.3 ACTIVE QUESTIONNAIRES ....................... 45 3.4.4 SENDING A MESSAGE TO THE NEXT CALLER ........ 47 3.4.5 OEC FILE STACKING ........................... 48 3.4.6 COMMAND BUFFER STUFFING ..................... 49 3.4.7 REGULATING PEAK TIME CALLER ACCESS .......... 50 3.5 EXTERNAL PROGRAMS ................................... 51 3.6 MESSAGE AREAS ....................................... 52 3.6.1 CHECKLIST FOR NEW MESSAGE AREAS ............. 52 3.6.2 SAMPLE MESSAGE AREA DEFINITION .............. 52 3.6.3 AREAINFO FILES .............................. 54 3.6.4 SMART RULES FILES ........................... 54 3.6.5 MESSAGE AREA MAINTENANCE .................... 54 3.7 FILE AREAS .......................................... 55 3.7.1 THE FILES DATABASE .......................... 55 3.7.2 CONVERTING TO THE FILES DATABASE ............ 56 3.7.3 CHANGING FILE AREA NUMBERS .................. 56 3.7.4 SETTING UP NEW FILE AREAS ................... 57 3.7.5 SAMPLE FILE AREA DEFINITION ................. 58 3.7.6 FILES DATABASE MAINTENANCE .................. 60 3.8 BARRICADED MESSAGE AND FILE AREAS ................... 61 3.9 WELCOME FILES ....................................... 62 3.9.1 THE STANDARD WELCOME FILE ................... 62 3.9.2 SPECIAL ANNOUNCEMENT FILES .................. 63 3.9.3 CUSTOM WELCOME FILES ........................ 63 3.9.4 SPECIAL OEC WELCOME FILES ................... 64 3.10 THE RELOGGING FUNCTION .............................. 64 3.11 EXPIRATION CONTROL SYSTEM ........................... 66 3.11.1 EXPIRATION CONTROL METHOD ................... 66 3.11.2 HANDLING EXPIRED CALLERS .................... 66 3.11.3 IMPLEMENTING EXPIRATION CONTROL ............. 67 3.12 "SECTIONS" OR "SIGS" ................................ 68 3.12.1 SYSOP DEFINED SECTIONS ...................... 68 3.12.2 USER DEFINED SECTIONS ....................... 69 3.12.3 THE SECTION MENU ............................ 69 3.12.4 RELATED CONTROL FILE OPTIONS ................ 70 3.12.5 SAFETY FEATURE .............................. 71 Page 4 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 3.13 TIME ZONE SETTINGS .................................. 71 4.0 THE OPUS EVENT SYSTEM .................................... 73 4.1 TYPES OF EVENT ...................................... 73 4.2 EXTERNAL EVENTS ..................................... 74 4.3 USER EVENTS ......................................... 75 4.4 MAILER EVENTS ....................................... 76 4.5 MATRIX EVENTS ....................................... 76 4.5.1 MATRIX EVENT FLAGS .......................... 77 4.5.2 MATRIX EVENT FIELDS ......................... 77 4.6 YELL EVENTS ......................................... 79 4.7 SCAN ALL EVENTS ..................................... 79 4.8 HOUSE-CLEANING EVENTS ............................... 79 4.9 OVERLAPPING BEHAVIOUR WINDOWS ....................... 80 4.10 ADVANCED EVENTS FOR TIME TRAVELLERS ................. 80 4.11 HOW TO SET UP EVENTS ................................ 82 5.0 WHEN THE SYSOP IS AT THE KEYBOARD ........................ 83 5.1 WHEN OPUS IS WAITING FOR A CALL ..................... 83 5.1.1 SETTING UP F1-F10 BATCH FILES ............... 85 5.2 SYSOP CALLING FROM KEYBOARD ......................... 87 5.3 WHEN A CALLER IS ONLINE ............................. 88 5.4 CHAT MODE ........................................... 90 5.4.1 CONFIGURING THE CHAT FOSSIL ................. 90 6.0 THE MATRIX ............................................... 91 6.1 NETMAIL FOR THE COMPLETE NOVICE ..................... 91 6.2 FILE REQUIRED FOR NETMAIL ........................... 92 6.3 OVERVIEW OF NETMAIL ................................. 94 6.4 QUICK START TO NETMAIL .............................. 95 6.5 OPUS DEFAULT NETMAIL BEHAVIOUR ...................... 102 6.5.1 BEHAVIOUR WINDOWS ........................... 102 6.5.2 BUILDING MAIL BUNDLES ....................... 103 6.5.3 FILENAMES DRIVE OUTBOUND MAIL ............... 103 6.6 HOW IT ALL WORKS .................................... 105 6.7 CONTROLLING OUTBOUND CALLS .......................... 107 6.7.1 OPUS CONTROL FILE ........................... 107 6.7.2 MATRIX BEHAVIOUR WINDOWS .................... 108 6.8 SETTING UP BEHAVIOUR WINDOWS ........................ 111 6.8.1 THE ZONE MAIL HOUR .......................... 112 6.8.2 OVERNIGHT LONG DISTANCE ..................... 112 6.8.3 DAYTIME LOCAL-ONLY .......................... 112 6.9 HOW TO GET INTO THE MATRIX .......................... 113 6.9.1 MATRIX STRUCTURE ............................ 114 6.9.2 MATRIX ADDRESSES ............................ 114 6.9.3 FINDING YOUR NETWORK ........................ 115 6.9.4 ASKING FOR AN ADDRESS ....................... 115 6.9.5 GETTING ALONG IN THE MATRIX ................. 115 6.10 MATRIX FILE REQUESTS ................................ 116 6.10.1 REQUEST METHODS ............................. 116 6.10.2 ENABLING/DISABLING REQUESTS ................. 116 6.10.3 THE OKFILE LIST ............................. 117 6.10.3.1 MAGIC FILENAME REQUESTS ........... 117 6.10.3.2 DOLLAR SIGN FILENAMES ............. 118 6.10.4 THE ABOUT FILE .............................. 120 TABLE OF CONTENTS Page 5 6.10.5 THE FILES FILE .............................. 120 6.10.6 MAKING A FILE REQUEST ....................... 121 6.10.7 MAKING AN UPDATE REQUEST .................... 122 6.11 THE MATRIX MENU ..................................... 122 6.12 FORCING AN OUTBOUND CALL ............................ 123 6.13 UNSUCCESSFUL CONNECTIONS ............................ 124 6.14 MATRIX SESSION SCRIPTS .............................. 124 6.14.1 CONTENTS OF A SCRIPT FILE .................. 125 6.14.2 SCRIPT CHECKLIST ........................... 127 6.14.3 SAMPLE SCRIPT .............................. 128 6.15 MATRIX ORIENTED BATCH FILES ......................... 129 6.16 CHECKLIST FOR GOING ONLINE .......................... 131 7.0 IMPLEMENTING POINT SUPPORT ............................... 132 7.1 WHAT IS A POINT? .................................... 132 7.2 HOW DO POINTS WORK? ................................. 133 7.3 HOW TO BECOME A FIDONET POINT ....................... 133 7.4 SETTING UP AS A BOSSNODE ............................ 134 7.5 SETTING UP AS A POINT ............................... 135 8.0 IMPLEMENTING UUCP SUPPORT ................................ 136 8.1 DEFINITIONS ......................................... 136 8.2 ElEMENTARY FIDONET <--> UUCP ........................ 137 8.3 DIFFERENCES BETWEEN FIDONET AND UUCP ................ 138 8.3.1 THE UUCP ADDRESS STRING ..................... 138 8.4 OPUS UUCP FEATURES .................................. 139 8.4.1 SCOPE OF THE UUCP FEATURES .................. 139 8.4.2 CONTROL FILE PARAMETERS ..................... 139 8.4.3 THE DEFAULT UUCP GATEWAY .................... 140 8.4.4 THE DEFAULT ADDRESS STRING .................. 141 8.4.5 THE UUCPLIST ................................ 141 8.4.6 ADDRESS STRING VERIFICATION ................. 142 8.4.7 ADDRESS STRING HANDLING ..................... 142 8.4.8 FORWARDING UUCP E-MAIL TO THE MATRIX ........ 143 8.5 THE UUCPLIST ........................................ 143 8.5.1 CREATING THE UUCPLIST ....................... 143 8.5.2 FINDING A PROPER UUCP ADDRESS ............... 144 8.5.3 VIEWING THE UUCPLIST ........................ 145 8.6 UUCP PROCEDURES ..................................... 145 8.6.1 USING NO UUCP FEATURES ...................... 146 8.6.2 ASSIGNING A GATEWAY ......................... 147 8.6.3 USING THE DEFAULT ADDRESS STRING ............ 147 8.6.4 OVERRIDING THE DEFAULT ADDRESS STRING ....... 148 8.6.5 USING THE UUCPLIST .......................... 150 8.7 EDITOR AND HANDLING MENUS ........................... 150 8.7.1 EDITOR MENU ................................. 151 8.7.2 HANDLING MENU ............................... 151 8.8 CREDIT WHERE CREDIT IS DUE .......................... 151 9.0 ECHOMAIL .................................................. 152 9.1 AN ECHOMAIL TUTORIAL ................................ 152 9.1.1 ORIGIN LINES ................................ 152 9.1.2 PRIVATE MESSAGES ............................ 153 9.1.3 PERSON-TO-PERSON MESSAGES ................... 153 9.1.4 THANK-YOU MESSAGES .......................... 153 Page 6 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 9.1.5 OFF-TOPIC MESSAGES .......................... 153 9.1.6 REPLIES SHOULD STAND ALONE .................. 154 9.1.7 DELAYED REPLIES ............................. 154 9.1.8 COMMERCIAL ADVERTISEMENTS ................... 154 9.1.9 COST OF ECHOMAIL ............................ 154 9.1.10 CONCLUSION .................................. 154 9.1.11 ENCOUNTERS OF AN ABBREVIATED KIND ........... 155 9.2 HOW ECHOMAIL STARTED ................................. 155 9.3 ROUTING AND COORDINATION ............................. 157 9.4 GETTING STARTED WITH ECHOMAIL ........................ 158 9.5 THE ECHOMAIL SCAN PROCESS ............................ 160 10.0 USING AN EXTERNAL MAILER ................................. 162 10.1 OPUS CONTROL FILE SETTINGS ......................... 162 10.2 EXTERNAL MAILER SETTINGS ........................... 163 10.3 OPUS MAILER EVENTS ................................. 163 10.4 OPUS MAILER COMMAND LINE SWITCH .................... 164 10.5 EXTERNAL MAILER EXAMPLE ............................ 164 10.6 SCHEDULING EXTERNAL EVENTS ......................... 165 10.6.1 OPTION ONE ................................. 165 10.6.2 OPTION TWO ................................. 166 11.0 OPUS SECURITY ............................................ 167 11.1 ONLINE USERS ....................................... 167 11.1.1 SECTIONS ................................... 167 11.1.2 PRIVILEGE LEVELS ........................... 168 11.1.3 LOCKS AND KEYS ............................. 169 11.1.4 PASSWORDS AND BARRICADES ................... 169 11.1.5 THE USER LIST .............................. 170 11.1.6 OUTSIDE SECURITY ........................... 171 11.2 APPLICATION OF ONLINE SECURITY ..................... 171 11.2.1 MENUS ...................................... 174 11.2.2 AREAS ...................................... 175 11.2.3 OPUS EMBEDDED COMMANDS ..................... 176 11.3 MATRIX AND ECHOMAIL SECURITY ....................... 176 11.3.1 SESSION LEVEL PASSWORDS .................... 177 11.3.2 FILE REQUESTS .............................. 177 11.3.3 ECHOMAIL ................................... 177 11.3.4 INTRANSIT MAIL ............................. 177 11.4 OPUS NAME FILTER .................................... 178 11.4.1 CONTROL FILE SETTINGS ...................... 178 11.4.2 FILTER NAME FILE FORMAT .................... 179 11.4.3 BEHAVIOUR OF THE FILTER .................... 179 11.4.4 ERRORS IN THE FILTER NAME FILE ............. 180 11.4.5 SPECIFIC EXAMPLES OF USE ................... 180 11.4.5.1 ONE LETTER NAMES ................. 180 11.4.5.2 ROGUE MODEM NAMES ................ 180 11.4.5.3 SHY CALLER NAMES ................. 181 11.4.5.4 DIRTY WORD NAMES ................. 181 11.4.5.5 WANNABE HACKER NAMES ............. 181 12.0 OPUS FOLKLORE ............................................ 182 12.1 THE ELUSIVE NERF BAT, NERF.BAT ..................... 182 12.2 IDENTIFYING THE CHICO CONNECTION ................... 184 12.3 oPOLO0: OPUS POLICY, VERSION ZERO .................. 184 TABLE OF CONTENTS Page 7 12.3.1 DRESS CODE ................................. 185 12.3.2 ATTITUDE ................................... 185 12.3.3 BACKBITING, SNIDE REMARKS, AND ON AND ON ... 185 12.3.4 MATRIX ..................................... 185 12.3.5 TRANSIENTS ................................. 185 12.3.6 RULES IN A NUTSHELL ........................ 186 12.3.7 ENFORCEMENT ................................ 186 12.3.8 DISCLAIMER ................................. 186 12.3.9 MERIT BADGES ............................... 187 13.0 MORE INFORMATION ON OPUS ................................. 188 APPENDIX A (COMMENTED NERF.BAT) ............................... 192 Page 8 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL +--------------------------------------+ | The reward of a thing well done is | | to have done it. | | -- Waldo Emerson | +--------------------------------------+ 1.0 INTRODUCTION TO OPUS Gidday! Welcome to Opus, the Computer-Based Conversation System. You are given a limited licence to use the Opus-CBCS program as long as you use it in a LAWFUL and FRIENDLY manner. This is NOT public domain software and you are required to to follow the two licence requirements. There is no monetary fee. You may freely distribute the Opus-CBCS program, but it is not to be sold. If your system has a user fee, for example, you may not have Opus-CBCS online for download unless anyone who has not paid the fee can also download Opus-CBCS. Nobody is ever to make money from the distribution of the Opus-CBCS software. If you bought Opus-CBCS on diskette or by download, demand your money back in some lawful but unfriendly manner and report the vendor to your nearest Opus-Info system. If you need, or want, to say thanks for this system in some monetary way, you can send $50 to AmFAR/5900 Wilshire Boulevarde/Second Floor, East Satellite/Los Angeles, California 90036-5032/USA. AmFAR is the Americcan Foundation for AIDS Research, a non-profit, non-political, and non-affectational organisation that funds hundreds of AIDS research projects throughout the world. The Opus-CBCS program is copyright software. The copyright is held by Wynn Wagner III. The sole purpose of the copyright is to ensure that the Opus-CBCS program remains available for no money. The copyright is enforced. +----------------------------------------+ | Free? Does this mean I can't | | get a discount? | | | | Nunzio | | Opus By-Laws & | | Covert Action Committee | +----------------------------------------+ Because no money is charged, Opus sysops are not consumers. Opus is a community effort. INTRODUCTION Page 9 +----------------------------------------+ | Be sure you keep Opus free. | | | | Opus never was free. Just because | | there's no money charged doesn't | | mean it's free. The LAWFUL AND | | FRIENDLY license can be more | | expensive than money. | | | | --- from a conversation | +----------------------------------------+ 1.1 GUARANTEE You have to be kidding! Opus-CBCS carries only one guarantee: if you break it, you own all the parts. To put it another way, if you run Opus, you do so entirely at your own risk. The Opus-CBCS program may or may not work under your particular circumstances. If it does work, it is possible somebody will invent a way to destroy everything on your system. Opus contains lots of security features, but those features don not come with any sort of guarantee. However, you are most definitely not on your own. The Opus Community throughout the world are always willing to help, provided you observe the lawful and friendly Opus-CBCS licence requirements. Your best source of information and help is the FidoNet MEADOW echomail conference. There are also Opus-Info help systems in the USA, Europe, Taiwan and Australia. 1.2 USING OPUS Lawful and Friendly are the important words. The original author, and copyright holder, of this software takes the license quite seriously, and if you use Opus you have to do so in a lawful and friendly manner. 1.3 CREDIT AND GRATITUDE The following folks have gone out of their way to help the Opus project. This is the "Opus: Sine Qua Non" (the list of folks, without whom there would be no Opus): WYNN WAGNER III First Opus-CBCS author. Opus-CBCS copyright holder. He came, he coded, he produced Opus-CBCS. Page 10 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL DAVID FINSTER Contributor to the Opus V0.00 documentation. Opus V1.00 alpha tester. BOB HARTMAN In addition to tweaking Wynn's Sealink file transfer routine until it had a reasonable disposition, he is also the author of Opus!Comm (the first-ever FOSSIL program). RICK HUEBNER He sent code! Here are some of the modules that Rick originally wrote: OOMP (the internal echomail scanner), ZModem, and dialing scripts. He also designed the WaZOO file request mechanism. MIKE KELLEHER Original sysop of OPUSinfo There. Contributor to the Opus V0.00 documentation. JOHN MILLER The Opus V1.00 documentation editor. VINCE PERRIELLO The other alpha tester of Opus V1.00. Vince is also one of the prime instigators of the FOSSIL standard. GEORGE STANISLAV The first Opus V1.03 to V1.10 author or "LCD" (Lower Code Dweller). DOUG BOONE The second Opus V1.10 author; he pushed, coded, and kicked the Opus V1.10 release out the door when the world was wondering "Will Opus V1.10 ever be ready?". Also responsible for Opus V1.11 through V1.14. Not knowing the meaning of the word "quit", and ever a glutton for punishment, Doug also coded this V1.70 Opus release. BOB DAVIS The Opus V1.13 Technical Reference Manual writer. JON SABOL Contributor to documentation for Opus V0.00. The Opus V1.10 & V1.20 Beta Coordinator. TOM KASHUBA The Opus V1.10 Gamma Coordinator and author of the essential Opus V1.1x Opus MANager program. BILL BOLTON The original "OpusInfo Under". JON MARSHALL The Opus V1.70 Gamma Coordinator. Current maintainer of Wynn's Opus Matrix Message Masher code (oMMM). JOHN VALENTYN The Opus V1.70 files database coder, and adoptive parent of Doug's Opus File Area Manager (OPUS-FAM) program which he converted for Opus V1.70. INTRODUCTION Page 11 ULF NILSSON Opus V1.70 Language Coordinator, managed to find a and group of people to keep their translations current TRANSLATORS while Opus V1.70 was in development AND put up with the "normal" American Anglocentric attitudes and misconceptions. Providing full language support would have been impossible without all your help. THOMAS SUNDBLOM Who provided the idea for the automatic character set translation and gave us permission to use his table of character sets. TREVOR ROYDHOUSE Opus V1.70 Document editor and author. Who did more typing? PAUL KELLY Three Opus V1.70 beta testers who seemed to find MICHAEL MASTERSON an unlimited number of bugs, quirks and oddities. BEV FREED And provided an unlimited supply of suggestions. In addition to the active participants, the following should be mentioned for doing things without which we would have no Opus: Ward Christensen He thought up both XModem and bulletin board systems. Tom Jennings He originated the worldwide amateur electronic mail network now known as FidoNet . Chuck Forsberg He designed ZModem, the fastest and most reliable streaming file transfer protocol available. 1.4 DOCUMENTATION, CREDITS The Opus CBCS Sysop Operations Manual is intended to be a practical "how to" guide to setting up, customising and operating Opus V1.70. This manual is not the place to look for highly technical information on Opus V1.70; for that you should refer to the Opus Technical Reference Manual. Nor was it written as an installation or conversion manual for Opus V1.70 (although it may help); for those you should refer to the Doug Boone's STARTUP.DOC and CONVERT.DOC files. No document would be complete without giving credit to those who contributed to the effort. First and foremost, I want to thank DOUG BOONE. Again. Heaven only knows how he found the time, but he was always there to answer my questions and look over the documentation, even at the eleventh hour. I also have to thank my wife, Adrienne, who has put up with my living in front of this screen and keyboard for the last couple of weeks and more than usual anti-social behaviour. Page 12 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL Others who contributed to this documentation included (in alphabetical order): Bob Davis, Beverley Freed, Dave Hatch, Tom Kashuba, Paul Kelly, Robert Lilly, Robert Michal, Graham Stair, George Stanislav, John Valentyn, and Wynn Wagner III. Who were the rest? Maybe you? How? I cannot stress enough how valuable a resource the MEADOW echomail conference is when it comes to information about Opus. I have been an avid reader of the conference since it first became available in Australia in 1987. If you do not regularly read the MEADOW, you are most definitely missing out on part of Opus and the sense of Opus community. Trev Roydhouse, 13 July 1991. 1.5 CORRECTIONS, SUGGESTIONS Please send any corrections, suggestions, observations, wishes, etc to me at: Fidonet 3:711/401 (PEP) FidoNet 3:711/501 (V32) International FAX +61-2-887-1702 Domestic FAX (02) 887-1702 PO Box 1605, Macquarie Centre, NSW 2113, Australia. 1.6 MISCELLANEOUS Fido and FidoNet are trademarks of Tom Jennings. The Sealink file transfer method is copyrighted by System Enhancements Associates. They have released the protocol for general use in return for this notice. The word "opus" is Latin for "project." The plural of "opus" is "opera". Although some Opus system operators have adopted a certain penguin as a mascot, you should know that this is not official. Opus- CBCS software has nothing to do with the comic strip Bloom County that has a character named Opus. Any matters involving copyrights and/or trademarks on the penguin are between you and The Washington Post Co. OPUS V1.70 OVERVIEW Page 13 +---------------------------------------------+ | The fault lies not with our technologies, | | but with our systems. | | -- Roger Levian | +---------------------------------------------+ 2.0 OPUS V1.70 OVERVIEW Opus is an evolving computer-based conversation system that combines simplicity with configurability. Simplicity, in that a novice can have a rather nice bulletin board up and running very quickly. Configurability, in that an advanced sysop can turn the customization of the board into an art form. It is entirely up to you! Therein lies Opus's charm: it has all the power an advanced sysop demands, while still being easy for both the user and the system operator. Opus provides a feature-rich electronic messaging system, wide choice of file upload and download protocols, plus access to the world's premier amateur electronic mail network. Clearly, it would be a bargain at twice the price! 2.1 WHAT IS NEW IN OPUS V1.70 Opus 1.70 is a major internal structural change that is moving towards more of a database design instead of having tons of little files out there with which to deal. And yes Virginia, we are still in the small memory model. One important point to realize is that you can throw out nearly all the limitations that were in Opus 1.14. Opus 1.14 Opus 1.70 Number of file/message areas 254 32,765 Number of boards you can scan to 12 255 Maximum EchoMail message size 10k 60k Maximum number of lines in messages: 60 250 Full point support No Yes Full zone support No Yes Number of OECs you can run 10 No limit Number of menu items available 71 116 Number of menus 9 14 Page 14 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 2.1.1 SYSTEM FILES The SYSTEM*.DAT files are gone, replaced by a mini-file area database and mini-message area database and five index files. These index files are true buffered Bplus trees which will give you very fast lookups. 2.1.2 USER AND EVENT FILES * The event file is largely the same as Opus V1.14. There is some new information in the header of the schedule file to track the ID's of new users; * In the user file there is some new information added (see configuration & history menu details below); * the lastread pointers stored in the user file are superseded by individual last read pointer files in each message area. Opus now keeps track of the highest message read and the last message read separately; * The user file is indexed using a buffered Bplus tree to give fast lookups; * Opus is also tracking the total number of messages that a user has read and the total number of messages that they have entered. 2.1.3 USER KEYBOARD MACROS * Opus will store 3 user keyboard macros (message, file macro and default) of up to 15 characters in the user record. * Opus will choose the macro that matches where the user is in the menu structure. If the user presses the macro key in the message menu, Opus will execute the message macro. Opus will execute the default macro at any menu except the message and file menus. 2.1.4 MENUS * In HiTech the '>' after MORE in HiTech is blue and will flash, which hopefully will draw people's attention to it; * You can substitute your own menu prompts; * Users can choose to have the number of minutes remaining displayed as part of the menu prompts; OPUS V1.70 OVERVIEW Page 15 * NACL will allow '*', '@' and '&' for menu options; * You can define a file to be displayed to users as fancy, slow ASCII graphics menu at the MAIN / CONFIG / SYSOP / SECTION / CUSTOM menus if the user has graphic (ASCII) menus turned on. The Opus menu will follow unless the user's help level is "expert". * The echomail and matrix menus have been eliminated. Instead there is one, single message menu for all areas. SECTION MENU * Sections are used to break an Opus into "sub-boards" or "sigs". You might have a "Programming Section". File and message areas that relate to programming would all list that as their section, and underneath that you might have a "C Section" and a "Modula 2 Section" and so on. When a user goes into a section they only have access to other areas that match that section. Message Scan and file Locate for example would be narrowed down by going into a section. * Sections are selected/used like locks and keys, except that users can directly change their sections. * Users can make their own selection of message and file areas to be included in user defined sections. Opus remembers users' sections next time they logon. Users can choose to unselect their user defined, or sysop defined, section and revert to none. CONFIG MENU New configuration options allow users to: * always return to their last menu after logging on, AFTER going through the usual logon procedure. The only difference is that instead of the MAIN menu being the menu where users are dumped, it will be the last menu they used on their last call; * select what type of graphics to use every logon, right after giving their password; * have hotkeys at all help levels; * get long, tedious graphic (ASCII) menus in addition to the Opus menus; * display the number of minutes left online for this session as part of the menu prompt; * turn on/off being interrupted by other users on a multiline system with multiline chat available; * set a default file transfer protocol. ***WARNING*** This may Page 16 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL mess up the Zmodem "R)Zupload" that a lot of us use. HISTORY MENU * The configuration menu has been split into a "history menu", which is information about the user (eg password, city, language, telephone, alias, street address, birthday, and how listed in the user list) and a configuration menu which is how the user sees Opus. * Users can now change their logon name. * Users can now change their alias. * The history menu can be added to any menu, eg the main menu or the configuration menu, or both. MESSAGE MENU New options allow users to: * search forward from the next message to the last message looking for messages that are To: the current user. When it finds one, Opus stops and displays the message; * search forward from the current message looking for a match to a string that the user provides, then displays the messages it finds. This command remembers the last search string that a user asked for, so hitting a return will allow a user to continue a search without having to type in the string for each match; * review the rules at any time, even after reading messages. It is a "smart" menu item which only appears on the menu if RULES.BBS or RULES~.BBS exist in the message path; * allow users to enter a message to Sysop from wherever the option is available. It is a variant of the logoff message in that users are not asked for names or subject or anything. FILE MENU New menu options added to allow for: * searching the entire files database for files added since the user's last call, or the user can override it and specify a number of days; * downloading and automatically disconnecting if Opus thinks the download went successfully; * H)urling files across drives if there is enough room on the target drive; * setting a temporary upload/download path. Opus will not ask for descriptions for files uploaded in the temporary directory OPUS V1.70 OVERVIEW Page 17 and they will not be included in files database. * adding files to the files database from the keyboard. CUSTOM MENUS * Opus V1.70 allows the sysop to create up to 6 different custom menus. These menus may be attached anywhere. There is a limitation: only "global" menu commands can be attached to custom menus (refer to section 3 of the Opus V1.70 Technical Reference Manual). LORE/OPED MENU * New editor command to have Opus ask for a filename. If you have started editing a message, it is lost, only the file is saved; * The LORE help file will be shown the first 2 times the user enters a message via LORE, instead of during the first 5 calls. 2.1.5 VERSION 7 NODELIST SUPPORT * Uses less than 70% of the disk space needed for the Version 6 nodelist, includes Sysop names, will insert Sysop name in net mail. Use of the Version 7 nodelist is optional, Opus still supports the outdated Version 6 nodelist. * If you do use the Version 7 nodelist then Opus will list the Sysops when listing boards. * When Polling between callers, Opus will accept either an address or a Sysop name. * You can set the privilege needed to see who the Sysops are for the boards when listing boards in netmail or from the Matrix Menu. 2.1.6 SYSTEM SECTION * Opus will optionally answer the phone itself instead of relying S0=1 in the modem initialization string. * Opus will support the new HST/DS HST modem CONNECT 14400 connect message. * You may specify the path to find/put echotoss.log and also the name of your echotoss.log. Opus now uses echotoss.Log for its internal echomail scanner, so external programs that use the echotoss.log will be picked up by Opus. Page 18 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL * Enable multiline chat ... this is not a real multiline chat, but at least messages can be sent between tasks. * Tell Opus that its being run on a LAN and it should behave like a multitasker was being run (ie create INMAIL##.$$$ files). 2.1.7 LANGUAGE SECTION * Opus supports the multiple character sets as set out in the file FSC-0050 and as implemented in the program OPMED 3.0; * The number of user-defined languages has been expanded from 6 to 12; * Option to change the IBM line-drawing characters in Opus to lotek ASCII characters instead of the high-bit characters. 2.1.8 EQUIPMENT SECTION * Rudimentary MOUSE support (sysop configurable on/off) * Four configurable predial strings for dialling outbound calls. Opus will check the Modem byte in the nodelist, and if it is set to one of these values Opus will use the predial string that corresponds to the first match. If no modem flag has been set for a node, Opus will use its default dial prefix string. 2.1.9 MATRIX AND ECHOMAIL SECTION * You can increase a user's Matrix Credit while a user is online; * A new option to tell Opus that if it cannot find an address in the nodelist to send the mail to the Net Host instead of marking it as "undialable". (This only works with the Version 7 nodelist); * New options to ask users of the specified privilege and above whether the message is a file request or an update file request. MULTI-ZONE SUPPORT * Opus will handle multi-zone holding areas (ie zoned outbound directories: outbound.###). You can still put everything in a single outbound directory, but if they exist Opus will use the outbound.### directories; * If you give an address in the definition of an echomail area, Opus will use that address in your messages from that area; OPUS V1.70 OVERVIEW Page 19 * If you have multiple zone / net /node addresses, Opus will use its "best fit" address for the calling/called node in the YooHoo packet instead of the first (primary) address. POINTNET SUPPORT * Opus will run as a BOSS node and strip off a point's SEEN-BY and Origin lines and put on yours; * Opus will also run as a point; * You can either be a BOSS or a POINT, but not both. EXTERNAL MAILER HOOKS If you give the CTL file an External Mailer string to look for, if Opus sees that string at the name prompt it will create a "MAILER.BAT" file and exit with the specified DOS errorlevel. UUCP SUPPORT * When forwarding messages to the netmail area, if the message is "To: uucp", Opus will not insert the From/To/Date stuff at the head of the text of the message so the UUCP address will be preserved as the first line in the message; * UUCPlist is like FidoUser.Lst, except it is a list of UUCP addresses, not FidoNet addresses. If this option is on, you simply enter Netmail messages with the person's name on the address line; * If a message has a UUCP address on it, you can set a privilege level for a new command that will allow some people to delete the UUCP address that has been read out of the original message; * When entering a message to "UUCP", Opus will put in the address of your UUCP gateway automatically; * In the MATRIX section of the CTL file you can specify an address so that if Opus is sending a reply back to a UUCP address, the message will be routed to this address automatically instead of wherever it entered FidoNet. 2.1.10 SESSION SECTION New options added to: * use/update LASTREAD for the Sysop who uses an external message editor; * define the file to be displayed if user does not get the password right; Page 20 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL * define a file where all downloads will be logged; * define a file where all uploads will be logged; * encrypt the users' passwords in the user file (they cannot then be unencrypted); * control the privilege needed to download or check the contents of files that are not listed in the files database. USER LOGON New options added to: * prompt new users for either their ALIAS or REAL name at first logon after they have entered their name the first time; * allow new users to choose from the languages the sysop has made available; * toggle on/off whether or not to ask new users for their city/state; * specify a default number of days until new users' access expires; * specify a default number of minutes until new users' access expires; * specify default keys for new users; * specify a default section for new users; * define a file to help the user with new user logon configuration; * allow users / new users who have a specified privilege to logon without giving any password. SPECIAL CONFIGURATION LOGONS * A user, even a new user, can enter their name plus a string of configuration commands at logon. These commands will override whatever has been stored in the user record or, if it is a new user, bypass the "Mirror shades" questions entirely; * Opus will accept name1 name2 /pmypwd for quick logons. OPUS V1.70 OVERVIEW Page 21 2.1.11 FILES DATABASE This is actually a system of three files. One file contains all the information about what files you have on your board, one is the index to all the filenames on your board, and one is an index into the first file in each file area. * You can specify where in each file area listing new files will be added either when uploaded or hurled. Normally new files are appended to the end of the listing. * You can specify full paths to files if they are not in the default directory for that area. * Who uploaded the file, and when, is stored with each file. * The file date and time is preserved when files are received via Zmodem transfers. The search for new files will look at the upload date/time, but the users will see the actual file creation time when they do a F)iles listing. * When a user does a L)ocate, or searches for a string with the F)iles command, they will also optionally get an additional line of information including who uploaded the file, when, and how many times it has been downloaded. * The F)iles display has been modified so it does a word-wrap for users who have screens wider than 60 characters. Descriptions can be up to 256 characters each. * Each individual file can have its own download privilege and locks. * When attempting to do a download, if the file is NOT in the current area, Opus will try to jump to the area where the file is located. Privileges and locks are honoured. * Opus will not allow users who have privilege below ASSTSYSOP to upload duplicate file names anywhere unless you specifically allow duplicate files. * If a user has never been in a file area, Opus will show them a RULES file if one exists. * You can specify file areas from which files may be downloaded without being counted as part of the ratio or daily download limit. FILE AREAS * File and Message areas are now completely separate. There is no place where they interact with each other. Even the barricade paths can be completely separate; * In both the file and message areas you can embed an Page 22 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL "applications" string in the area definition in the database for use by, eg, an intelligent message renumberer; * The number of external protocols Opus will accept has been increased from 8 to 16. * During a file L)OCATE, Opus will list the areas as they are checked. New options added to: * define what section(s) an area should be considered to be part of; * define a file in each file area to be shown before the file listing; * specify a private upload path; * specify a private upload path user privilege. Uploads from users with the specified privilege or greater will go to the private path; * specify a private upload key; * specify a private upload key path where uploads from a user with the private upload key will go; * define a file to be displayed to a user before the Opus menu for this file area if they have graphics (ASCII) menus turned on; * define ratio privileges in file areas. Ratios only come into effect if the user's privilege is equal to or below what you set for that area; * specify the privilege necessary to display the information stored in the files database on who uploaded new files; * allow duplicate files to be uploaded in a specified file area. Opus will then not check for duplicate files when uploads start in this area; * specify that files uploaded in a particular area will be assigned a specified privilege for downloading; * show the two-line listing instead of the single line listing; * specify a privilege level for displaying who uploaded files (the date of upload and how many times downloaded info will still display in two line listings). OPUS V1.70 OVERVIEW Page 23 2.1.12 MESSAGE AREAS * File and Message areas are now completely separate. There is no place where they interact with each other. Even the barricade paths can be completely separate; * In both the file and message areas you can embed an "applications" string in the area definition in the database for use by, eg, an intelligent message renumberer; * Opus will check to see if private messages are to either the user's name or current alias. * The 10k limit on echomail messages has been lifted, instead you can specify a limit in the CTL file from 3k up to 60k; * The 60 line limit on messages has also been lifted. Instead in each area you can specify a maximum number of lines, the default is 60, and Opus will give users that many lines or as many as it can in the amount of free memory it has available. The range of lengths that NACL will allow is from 10 to 250 lines. New options added to: * specify the keys needed to access the message upload command; * specify the privilege required to use the message upload option for this area; * specify the keys needed for users to read PRIVATE messages that are not to / from them; * specify the privilege needed for users to read PRIVATE messages that are not to / from them; * define a file that will be shown to users who have graphics menus on before the Opus menu; * define an ORIGIN line for use in each echomail message area; * specify a DOMAIN for use with MSGID in a message area; * specify the ADDRESS for use in an area for the Origin line, MSGID, and SEEN-BYs. * specify the addresses to scan mail to. Opus V1.70 will scan to 255 addresses per area; * changes to the next area that has new messages in it up to the high message area set in the CTL file. Page 24 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 2.1.13 OPUS EMBEDDED COMMANDS * Skip the rest of the line if user section is equal to specified section; * Skip the rest of the line if user section is not equal to specified section; * Show the last date/time the user accessed a particular file area; * Show a specified file and return to the current location in the original file; * Show the rest of a line only if the user's baud is greater than or equal to a specified baud; * Record the current position in the current file, jump to specified position in the current file and return to original position when specified; * Stuff commands available from the current menu into the command buffer and quit the OEC file; * If the user's help level is not equal to the help level on the line, the rest of the line is skipped. * Add specified keys for the user. This in addition to the default logon keys which may be specified in the control file; * Clear specified keys for the user; * Display the total number of messages a user has read; * Display the total number of messages entered by user; * Get and save a string up to 58 characters long from the user. When Opus hits a ^OC or ^OH or ^OG, whatever the user has entered will be appended to the command you gave. * Log special debugging info; * ^OC rereads LASTUS##.DAT, now there is an OEC that is identical in function, except that LASTUS##.DAT is not reread; * Send a message to the user on the current task. Sounds useless right? Well, suppose you added it to the end of BYEBYE.BBS ... * The ability to stack OEC files, where one file calls another and then returns to the original point; * Send a message to a specified task (like the inter-line chat menu item); * See who else is online on multi-line systems; OPUS V1.70 OVERVIEW Page 25 * Look for the interline CHAT## file and display it if it exists; * An OEC like ^OC which does not fill the command buffer with an ENTER when it returns; * An OEC like ^OC which does a system() call, does not re-read LASTUS##.DAT, and does not fill the command buffer with an ENTER when it returns; * Check for the existence of a specified filename. If the file does not exist, the rest of the line is skipped; * Run a program and return the DOS errorlevel of the program that was called; * Run a program (as above), but do not re-read LASTUS##.DAT; * Compare the DOS errorlevel returned from the program run (operates just like "if errorlevel" does in DOS batch files). 2.1.14 COMMAND LINE OPTIONS * Force Opus to do an EchoScan right away. 2.1.15 NIEL KEYS EXTENSION Opus will execute a batch file in the miscellaneous directory that corresponds to the function key pressed when it is waiting for a call. 2.1.16 EXTERNAL PROGRAMS Programs that are called from the menus as _OUTSIDE items, Opus will pass everything else that the user has typed as arguments after filtering it. Opus will filter out <>/\-":' characters. 2.1.17 ERRORLEVEL EXITS * Exit after upload; * Exit after local messages entered. Page 26 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 2.1.18 TRULY MISCELLANEOUS * More [Y,n,=]? When users are listing areas, they quite often just type in a number and Opus says something about, "I do not understand 27, Use 'Y' for Yes and 'N' for No.". 1.70 will just accept the number as an area selection and go on; * Opus will log the size of the file in file transfers, including mail transfers; * The low-level disk routines have been stripped down, the rust scraped off and they were all chromed and converted to _fastcall calls; * If the Sysop puts a jump to another menu but never defines that menu, users were cut adrift in limbo. Now Opus will check to make sure that there really is a menu to go to, and if not, will log the error, tell the user to tell the Sysop about it, and send them to the MAIN menu; * "Press ENTER to continue" will pass along any commands that have been typed in; * Fixed the timer so that if Opus is re-started with fewer than 3 minutes before a "hard" event, Opus will know that it should go into its "pending event" mode and drop DTR so no incoming calls will be accepted. 2.2 REQUIRED HARDWARE In general, you have a reasonable chance of getting Opus 1.70 to work on any MS-DOS computer. Opus V1.70 uses a little more memory than V1.14 to do some tricks. In Opus V1.14 the "minimum" was 128k plus the size of the nodelist index file. For Opus V1.70 the minimum is 128k plus the size of nodelist index file plus the size of the largest *.USL file in your language directory; and if you are using the internal echomail scanner in Opus V1.70, add the size of the maximum echomail message you want to be able to handle. In most cases, you will want to be able to run external programs (eg file compressors and uncompressors) from Opus, and that requires anywhere from 256k to 400k depending on the file compressor you choose. Hardware incompatibilities are resolved through a special program called a FOSSIL. It contains modem, keyboard and video methods for specific hardware configurations. It means the same version of Opus can run on an IBM PC, an IBM PS/2, a DEC Rainbow or a Tandy 2K. The only difference is the FOSSIL program. Theoretically, Opus will use any modem that uses the Hayes command set and supports DTR. It has been successfully tested with the USR DS/HST, Telebit, Netcomm, Dataplex, MultiTech and the Hayes families. If you use another modem brand, Opus should work but there are no guarantees. If you get other brands of modems to work with Opus, please contact OPUS V1.70 OVERVIEW Page 27 one of the Opus-Info nodes and let them know the brand name, the initialization string and what you did to get it to work. Also, Opus REQUIRES a storage device larger than a floppy drive. Generally, this will be a hard drive, but could just as easily be cartridge media such as a Bernoulli Box. There are absolutely no plans to release a version that will run on floppies; the support files simply take too much room. 2.3 REQUIRED SOFTWARE Several pieces of software are required to make Opus work. A couple are worth singling out. First, DOS 2.1 or higher ... 2.0 and below are NOT supported. In fact, not all the Opus features will work under DOS 2.1. DOS 3.1 or higher is recommended for a fully-featured Opus system. There are no guarantees that DOS 2.1 will be supported in future releases of Opus. Next, the FOSSIL. This is where Opus's low-level communications routines live. The FOSSIL is a memory-resident assembly language program or device driver designed especially for Opus. It supplies the routines Opus needs to communicate with the modem. If you are running other memory-resident programs, you may experience difficulty with the FOSSIL. Installing the FOSSIL last may solve the problem, but it is NOT guaranteed. Switching to another FOSSIL may also solve your problems. 2.4 MESSAGES Messages can be of three basic types, or scopes: local, Matrix and echomail. A message's scope determines its behavior on an Opus-based system. 2.4.1 LOCAL MESSAGES Local messages are the simplest form available, common to almost all BBS systems. Local messages are available to a predefined group of users on a single BBS -- the one where they were entered. 2.4.2 MATRIX/NETWORK MESSAGES Matrix is the Opus word for network. This was chosen because of the ambiguity associated with the word "network". The Matrix is defined as a group of bulletin boards which can exchange information via the public switched telephone network (PSTN). Page 28 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL Opus V1.70 can place outgoing Matrix calls, and receive incoming mail from other Opera, or other systems running either the FidoNet or WaZOO matrix protocols. 2.4.3 ECHOMAIL MESSAGES EchoMail provides a means of maintaining the same message base on multiple bulletin boards. This allows conferencing -- even internationally -- if you choose to do so. Remember, phone calls placed for mail transfers cost the same as regular calls. Be aware that anything involving Matrix transactions can involve long distance phone charges. 2.5 EXTENDED MESSAGE AREA ATTRIBUTES A variety of message area attributes are supported. With them, you can define exactly what type of messages will be placed in what area. Private only All messages entered in this area will be marked "private," and cannot be read by other users. Public only All messages in this areas can be read by all users. Read-only Messages in this area can be read by callers, but only sysops and assistant sysops can enter new messages. Anonymous In an area marked as "anonymous," Opus will ask the user to supply a pseudonym. Alias In an area marked as "alias", Opus will use the user's alias on messages from the user. EchoMail Conference-type message bases are recognized. The user will be told that the message will be broadcast, and Opus will automatically do such echomail-oriented processing as inserting an "origin line" into the message. Inbound-only Echomail messages are tossed into this message area, but messages are never scanned out to other systems from this message area. Useful for "read- only" echomail conferences. Matrix messages These are treated like FidoNet messages. The user is asked where the message is to be sent, to whom and to what address. OPUS V1.70 OVERVIEW Page 29 Barricaded Barricaded areas may have a special password(s) associated with them so that only users who know the password(s) get the specified privilege level in that area. Barricaded areas may also have special privilege levels associated with certain users' names. By using this feature you can allow users higher or lower privileges in certain areas. These attributes may be combined in any fashion. You can require all messages in your Matrix area to be private, or all EchoMail messages to be public. It is up to the sysop as to how message areas will behave. 2.6 FILE TRANSFERS Opus supports four different types of file transfers: uploads, downloads, Matrix and file requests. These enable the sharing of public domain or "shareware" software among users and other bulletin board systems. 2.6.1 UPLOADS Uploading is defined as a user sending a file TO a BBS. This lets users share programs they have written or collected. 2.6.2 DOWNLOADS Downloading is defined as a user receiving a file FROM a bulletin board system. This allows a single point to serve as a "holding tank" for software that can be freely shared among users. 2.6.3 MATRIX Matrix transfers are uploads or downloads between two Matrix systems. You can direct Opus to send a file to any other system in the Matrix. Opus will accept incoming Matrix files any time it is not busy. Page 30 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 2.6.4 REQUESTS File requests are another variant of Matrix transfers between two Matrix systems. You can direct Opus to obtain a file from any other system in the Matrix which accepts WaZOO file requests. Opus cannot initiate SEAdog-style "bark" requests (but will accept and process such requests -- see below). Opus will accept both WaZOO and "bark" file requests from other Matrix systems, if it has been setup to do so. Any system can initiate a WaZOO file request simply by sending a file with a ".REQ" file extension containing a list of the requested files. 2.7 EXTENDED FILE TRANSFER PROTOCOLS Several transfer protocols are supported in Opus. These include Zmodem, Ymodem, Xmodem, Telink, and SEALink. Opus V1.70 also has 16 "slots" available for installation of external protocols, at the sysop's discretion -- for example, Windowed Xmodem (WXmodem), Sliding Window Kermit, and YmodemG. These will be described more thoroughly in the file transfer section. The precise manner in which Opus interacts with external protocols is detailed in the Opus Technical Reference Manual; refer to that manual for the fine technical details. 2.8 OEC FILE CAPABILITY OEC (Opus Embedded Command) files provide a world of customisation possibilities for you to explore. Opus Embedded Command files support both AVATAR and ANSI graphic codes as a user option. If you use Avatar graphic codes in files, Opus will send them to Avatar users, convert them into ANSI for ANSI users or strip them for TTY users. Through the use of an embedded command, you can make any support file branch to an external program. The sysop is responsible for ensuring that the program directs its output to the comm port. This feature allows multiple "Outside" features to be supported. Questionnaire information can be collected from within any OEC file. This can be used to log the activity of any displayed section of your bulletin board. You can insert a person's name, display a quote, date and time, etc., within any OEC file. Virtually anything Opus knows about the user can be displayed at any point in the support files. Additional embedded commands allow you to make any OEC file a submenu. This is handy for things like multiple bulletins, interactive help systems, etc. You will find a more details on OECs in the section of this manual on Setting Up Opus. For the complete list of OECs and the OEC file mechanism, refer to the Opus Technical Reference Manual. OPUS V1.70 OVERVIEW Page 31 2.9 ECHOMAIL ENHANCEMENTS Opus lets the sysop decide whether EchoMail SEEN-BY lines are displayed to the user. Few appreciate the unsightliness of this part of EchoMail, and Opus eliminates that problem. If you do not care for SEEN-BYs, Opus lets you disable their display on a privilege level basis. The display of extended addressing can be disabled. As more distinct addresses become available over the Matrix, more information will need to be embedded within the body of messages. Opus lets you control who can and cannot see this information. Opus automatically inserts its own origin line if a message area is marked as echomail. This lets other systems know which Matrix system originated the message and what software processed the mail. You can tell Opus to uncompress and toss compressed mail and EchoMail packets automatically. You do not have to declare an external event to extract compressed mail packets and toss EchoMail -- Opus does this for you. 2.10 MATRIX/NETWORK MAIL INTERFACE Opus can receive mail at anytime. Matrix/Network transactions are not restricted to fixed time slots. You can also send mail to another Opus at anytime. 2.11 OPUS OPERATING PHILOSOPHY The operating philosophy of Opus is based on the KISS principle: -={ KEEP IT SIMPLE SYSOP! }=- Opus is very easy to use if you let the installation kit do its job. A sysop can lead a very satisfying life with the basic Opus installation. It will still be a superior system, requiring a minimum of maintenance. There are thousands of custom features available; each Opus board will probably look and act differently, but there is no guarantee that any of the customization methods will be easy or immediately apparent. It is best to start with a basic system and to customize things gradually after gaining experience with Opus. The difficult functions are always available, but never required. If you want to tailor your system to look and act a certain way, you can, any time. The rewards you reap are proportional to the amount of work you put into the system, and that can run into years if you let it. Page 32 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL +------------------------------------------------------------+ | Nothing in the world can take the place of persistence. | | Talent will not; nothing is more common than | | unsuccessful men with talent. Genius will not; | | unrewarded genius is almost a proverb. Education will | | not; the world is full of educated derelicts. | | Persistence and determination alone are omnipotent. The | | slogan "press on" has solved, and always will solve, the | | problems of the human race. | | -- Calvin Coolidge | +------------------------------------------------------------+ 3.0 SETTING UP OPUS V1.70 To set up a new Opus V1.70 system, or to convert from a previous version of Opus, refer to the separate installation manual. Having installed Opus V1.70, there are many ways to customise your shiny, new Opus system: the control file, the menu system, privilege levels and locks for access to message and file areas as well as menu commands, "sections" or "sigs", barricaded message and/or file areas, Opus embedded command (OEC) files, bulletins, special announcements, custom welcome files and caller expiration control to name but a few. These, and others, are dealt with in the following sections. Let the fun begin! 3.1 THE CONTROL FILE The Opus control files (BBS.CTL) is the single best place to find ways of customising your system. Please refer to section 2 of the Technical Reference Manual for a detailed description of the many control file options which are available. SETTING UP OPUS V1.70 Page 33 3.1.1 CONTROL FILE MAINTENANCE The control file (BBS.CTL) can be split into separate sections for easy maintenance or separate compilation. This is especially handy on multiline systems where you do not want to have to alter more than one control file to add a new message area. On single line systems, it is also handy to be able to just produce the BBS.PRM file rather than also regenerating all the necessary system files for the message and file area definitions and the menu system files. You can also do separate compilations of: * the parameter file (BBS.PRM); * the file and message area system files (SYFILE.DAT, SYSMSG.DAT, NAME.FDX, NAME.MDX, NUMBER.FDX, NUMBER.MDX and ECHO.MDX); and * the menu files (eg ENGLISH.MNU). 3.1.2 THE PARAMETER FILE To do a compilation of just the parameter (BBS.PRM) file you need to include the System Section, Language Section, Equipment Section, Matrix and EchoMail Section and Session Section of your control file in BBS.CTL. You may keep these different sections all in the one file or each in its own file. If you split the different sections into separate files, your BBS.CTL might contain just the following lines: include c:\opus\config\system.ctl include c:\opus\config\language.ctl include c:\opus\config\equipmnt.ctl include c:\opus\config\matrix.ctl include c:\opus\config\session.ctl Running NACL BBS would then produce a compiled BBS.PRM file. 3.1.3 FILE AND MESSAGE AREA SYSTEM FILES To do a compilation of just the file and message area system files, you need to include the File Areas and Message Areas Sections of your control file. You may keep these different sections all in the one file or each in its own file. In either case, you must put your File Areas BEFORE your Message Areas or NACL will laugh at you ... loudly! There is also one other special requirement in this situation. You must add a PATH OVERRIDE line to the beginning of your area files. The path you define here should be the same as you defined for PATH SYSTEM in the System Section of your control file. If you do not do so, yep, you guessed it in one, NACL will laugh at you ... loudly! Page 34 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL If you split the File Areas and Message Areas Section into separate files, your AREAS.CTL file might contain just the following lines: include c:\opus\config\filearea.ctl include c:\opus\config\mesgarea.ctl Running NACL AREAS would then just produce the file and message area system files. 3.1.4 MENU FILE(S) To do a compilation of just the menu file (eg ENGLISH.MNU), you need to include the Menu Section of your control file in a separate file (eg MENU.CTL). Running NACL MENU would then just produce the menu file(s). There is one gotcha though. The new compiled ENGLISH.MNU file will be in the directory from which you ran NACL. You need to move it to the directory defined with the LANGDIR option in the Language Section of your control file. 3.1.5 ALL FILES To compile your whole system, your BBS.CTL file might contain the following lines: include c:\opus\config\system.ctl include c:\opus\config\language.ctl include c:\opus\config\equipmnt.ctl include c:\opus\config\matrix.ctl include c:\opus\config\session.ctl include c:\opus\config\filearea.ctl include c:\opus\config\mesgarea.ctl include c:\opus\config\menu.ctl or it might contain the following lines: include c:\opus\config\system.ctl include c:\opus\config\areas.ctl include c:\opus\config\menu.ctl SETTING UP OPUS V1.70 Page 35 or for a multiline system you might have two BBS.CTL files like this: 711_401.CTL include c:\opus\config\sys401.ctl include c:\opus\config\areas.ctl include c:\opus\config\menu.ctl 711_501.CTL include c:\opus\config\sys501.ctl include c:\opus\config\areas.ctl include c:\opus\config\menu.ctl 3.1.6 MACRO SUBSTITUTIONS As if the ability to split the control file into its separate component section was not enough, you can also use macro substitutions in the control file. For example, your BBS.CTL might contain the following: Misc = c:\opus\misc Help = c:\opus\help Task = 01 Port = COM2 include c:\opus\config\system.ctl include c:\opus\config\areas.ctl include c:\opus\config\menu.ctl The macros defined above are then used like this in the separate control files: PATH MISC $(Misc)\ PATH SPANN $(Misc)\ USES PASSWORD c:\opus\user$(Task).dat USES SCHED c:\opus\sched$(Task).dat LOG FILE c:\opus\opus$(Task).log OUTPUT $(Port) NACL would make the macro substitutions and interpret the above lines as follows: PATH MISC c:\opus\misc\ PATH SPANN c:\opus\misc\ USES PASSWORD c:\opus\user01.dat USES SCHED c:\opus\sched01.dat LOG FILE c:\opus\opus01.log OUTPUT COM2 Page 36 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL You can also use the macros in the include parameters like this: Node = 401 include c:\opus\config\sys$(node).ctl include c:\opus\config\areas.ctl include c:\opus\config\menu.ctl 3.2 THE MENU SYSTEM The Opus V1.70 menu system is extremely flexible, especially with the addition of the six CUSTOM menus, the ability to use alternative menus in specified areas and the ability to replace the normal Opus menus. Menu prompts may now also be customised! Please refer to section 3 of the Technical Reference Manual for a detailed description and list of the many menu options which are available and how they may be implemented. 3.2.1 CUSTOMISING MENU PROMPTS You customise the menu prompts by specifying the prompt you wish to use in quotation marks after the name of the menu in menu section of the control file. For example: MAIN MENU "Sentry Main Menu" 3.2.2 CONTROLLING ACCESS TO MENU COMMANDS A caller's access to menu options may be controlled by using one of the Opus privilege levels (Hidden, Sysop, AsstSysop, Clerk, Extra, Favored, Privil, Worthy, Normal, Limited, Disgrace, Twit) and by setting locks on the menu command to which callers will need the corresponding key(s). The format is: MENU_COMMAND ! "" The first character of the description filed is used by Opus for the command letter that the caller should type to execute the command. Be careful not to use the same letter twice in the same menu or Opus will only ever let the caller execute the first command with the common command letter. Note that the use of locks on the command is optional, whereas a privilege level must be specified. SETTING UP OPUS V1.70 Page 37 For example, the file download command could require the caller to have NORMAL access or above and also the key for lock X. This is what the entry in the control file would look like: F_DNLD Normal !X "Download a file" Do not overlook the fact that privilege levels for some menu commands may be overidden by other control file options. For example, in the definition of a file area you can specify the DOWNLOAD PRIV and the DOWNLOAD LOCK options which will override the privilege and locks you have set on the menu command FOR THIS AREA ONLY. There are other similar control file options which will override menu command settings, please refer to section 2 of the Technical Reference Manual for the full list of such options. 3.2.3 DISPLAYING OEC FILES Bulletin or help files may be shown to callers by adding the _SHOW menu command to any menu. You can add as many _SHOW menu commands to the same menu as you wish. For example: _SHOW Twit "Software Bulletin" = c:\opus\misc\sware _SHOW Twit "Hardware Bulleton" = c:\opus\misc\hware _SHOW Disgrace "Editorial" = c:\opus\misc\edtorial _SHOW Twit "? Help" = c:\opus\misc\menuhlp Note that although you do not use a file extension on the name of the file to be shown, it must be an OEC file with either a .BBS or .GBS file extension. The .BBS files are preferred because if you use Avatar graphics commands in them, Opus will send Avatar to callers who support Avatar, and send ANSI graphics commands to callers who support ANSI or strip the commands for TTY callers who support neither Avatar nor ANSI graphics commands. A .GBS file is only shown to callers who support ANSI and is therefore largely superseded. Refer to section 4 of the Technical Reference Manual for a detailed description and listing of OEC commands. 3.2.4 RUNNING EXTERNAL PROGRAMS External programs may also be run from the menus. For example, here is a sysop menu you could implement: % SYSOP MENU SYS_MAIL Sysop "Matrix setup" _OUTSIDE Sysop "Events" = DOS c:\opus\oevent.exe /a _OUTSIDE Sysop "Outside" = EXIT 12 _MAIN Sysop "Quit" _SHOW Sysop "? HELP" = c:\opus\hlp\syshelp END Menu % Page 38 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL Choosing the "Events" command would run the OEVENT.EXE (Opus Event Manager) program with the /a command line. Choosing the "Outside" option would cause Opus to exit to the batch file from which you run Opus (NERF.BAT) with a DOS errorlevel of 12. Your batch file should trap that errorlevel and act on it. See Appendix A for a sample NERF.BAT batch file. Refer to section 3 of the Technical Reference Manual for details of the various different methods of implementing the _OUTSIDE program option. Further discussion of these methods may also be found in section 7 of the Technical Reference Manual. For the correct method of implementing external file protocols (ie, so that Opus will keep track of caller uploads and downloads and daily limits), refer to section 7 of the Technical Reference Manual. 3.2.5 GLOBAL MENU COMMANDS Global menu commands (those with a leading underscore character) may be included in any menu. For example, in the message menu you could add the following: _FILE Disgrace "Jump to File Menu" to jump to the file area menu, and in the file area menu you could add the following: _MESSAGE Disgrace "Jump to Msg Menu" to jump to the message area menu -- all without having to go through the main menu! Refer to section 3 of the Technical Reference Manual for the full listing of global menu commands. 3.2.6 AUTOMATIC ZMODEM UPLOAD Opus can be configured to receive Zmodem uploads automatically without the caller having to type UZ (Upload Zmodem). The Zmodem protocol states that the uploading software should start by sending 'rz\r', in which the '\r' stands for carriage return. Thus if your menu choice for upload is 'R' (as in RUpload Zmodem), the caller need type nothing, he/she just has to start sending the file(s) and the Zmodem protocol will let Opus know about it. You can add the 'R' option and keep the old "U)pload" option at the same time. Opus can handle multiple menu items with the same meaning. Note that this may not work right for the callers with Hotflash. After Opus receives the 'r', it will clear its menu buffer (thus discarding SETTING UP OPUS V1.70 Page 39 the 'z' and the CR) and ask what protocol you want. With all other types of menu, automatic Zmodem uploads work well. There is one last gotcha: if the caller has set a default file protocol, and that protocol is not Zmodem, this will not work! 3.2.7 SUPERSEDED MENU COMMANDS Some menu commands from Opus V1.1x versions have been superseded. Most notably, the configuration menu commands which dealt with things about the caller have been transferred to the history menu. Refer to section 3 of the Technical Reference Manual for the full listing of menu commands and details of which menu commands may appear on which menus. 3.2.8 ALTERNATIVE MENUS There is truly no end to the flexibility of the Opus Menu System. For each area, for very special purposes, you can define an alternative menu file to use just for that area. With alternative menus, you can create a special personality or command set for a particular area. To implement this feature, copy your current menu section from your control file to a separate file and call it, for example, MENU001.CTL. Use your trusty wordprocessor to customise those menu(s) that you wish to be different. Now compile just that menu file by running NACL MENU01. NACL will produce a new ENGLISH.MNU file in the directory from which you ran NACL (so do not run NACL in the same directory as your existing ENGLISH.MNU file!). You should now rename your new ENGLISH.MNU file to ENGLISH.001. Wait a minute ... you now need to edit the MENU option in the relevant message and/or file area definitions in your control file to reflect the particular menu number you wish to be used for those areas. For example, you may wish to use the modified menu only in Message Area 20. You would modify the message area 20 definition like this: AREA 0020 SPECIAL MENU 001 etc Recompile your control file with NACL (or just the file and message area definitions section of the control file -- refer to section 3.1.1 above for how to do this). Now when Opus switches to that area, it would use ENGLISH.001 instead of ENGLISH.MNU. Note that if you support more than one language, you would have to Page 40 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL create an alternative menu with the same number extension for each language you support. You will generally not need to use this option for most situations. 3.2.9 ASCII MENUS Menu system not flexible enough for you? Yep, you guessed it. There is more. With Opus V1.70 you can also implement what are somewhat misleadingly referred to as ASCII menus. These menus are really custom menus which you can use to replace the normal Opus Main, Config, History, Section, Sysop and six Custom menus. Opus rather cleverly uses smoke and mirrors to achieve this replacement. The ASCII menus feature was added so that sysops could replace the fairly quick-displaying Opus menus with those long, slow graphics menus that some sysops and callers prefer [climbing off soapbox]. Several control file options should be set if you are going to use this option. In the Session Section of your control file, uncomment the LOGON ASCIIMENU option (and make sure it is adequately described in your CONFHELP.BBS file). New callers will now be given the option of using ASCII menus and the option will also now appear on the configuration menu. You also need to uncomment each of the following options in the Session Section of your control file for which you are going to define a corresponding ASCII menu file: USES MainMenu MAIN USES ConfMenu CONF % USES SectMenu USES SysopMenu SYSOP USES HistoryMenu HIST % USES CUSTOM1Menu % USES CUSTOM2Menu % USES CUSTOM3Menu % USES CUSTOM4Menu % USES CUSTOM5Menu % USES CUSTOM6Menu Note that you do not specify a file extension for your replacement menu files. These files follow the normal OEC (.BBS/.GBS) file standard, so you can use any of the Opus Embedded Commands in them! Refer to section 4 of the Technical Reference Manual for a full description of OEC files and the complete list of OECs available. Now for the smoke and mirrors part. When a caller chooses the ASCII menu option at logon, the caller gets expert help automatically selected ... ahah, no normal Opus menus are shown, only the ASCII menus which you have defined. Of course, a caller can choose their help level from the configuration menu and might decide to set it to regular for the one line command letter prompts. If the caller selects SETTING UP OPUS V1.70 Page 41 novice help, the caller will get the ASCII menus followed by the normal Opus menus. Smoke and mirrors are not that good! 3.2.10 OEC MENU PROMPTS A new Opus Embedded Command widget in Opus V1.70 especially designed for menus is ^FM. This OEC simulates the current Opus (or your customised) menu prompts so that it looks to the caller as if the caller is still inside Opus and not inside one of your OEC files which was called from the relevant menu. Refer to section 4 of the Technical Reference Manual for the complete listing of the many OECs available. Some examples of the usage of OECs may be found in the Implementing OEC Files section of this manual. 3.2.11 MENU SAFETY FEATURE If the Sysop puts a jump to another menu in a menu, but never defines that other menu, callers used to be lost in limbo. Now Opus V1.70 will check to make sure that there really is a menu to go to, and if not, will log the error, tell the caller to tell the Sysop about it, and then send the caller to the MAIN menu. 3.3 BOMBING RUNS Check that you have your full complement of HE bombs on board and that the bomb bay doors have been properly secured, ooops, wrong document file. [Editor's note: this gag is probably copyrighted / patented / trademarked by Jon Sabol.] Opus lets you do message bombing runs (to use the old Fido-talk) or "carbon copies" (to use SEAdog-talk). You can enter the one message and then send it to a bunch of other people. You might like to stop here for a few minutes and imagine just how unpopular you could quickly become with Network Hosts if you indiscriminately use bombing runs for Matrix messages ... , sorry, wrong -- you really cannot imagine. To use this feature you enter a message normally and save it. You then choose the Forward command (the MSG_FORWARD menu command) and Opus will ask you: * whether to use the same message area; * whether you wish to delete the original message; * whether to make the new message(s) private; Page 42 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL * (if you are forwarding the message to the matrix message area or in the matrix message area, other questions may be asked depending on the MESSAGE EDIT ASSUME and ASK settings in your control file); * whether you wish to make a bombing run (yes, you do); * (if in the matrix message area, you may be asked for the matrix address of the addressee -- ignore this by pressing ENTER); * for the addressee (ignore this, type something to keep Opus happy - if you answered private above, it must be someone in your user file); * whether you wish to use the original subject line; * for the route file! The "route file" must be in the following format: Zone:Net/Node.Point First_Lastname where is optional and may be one of -c (crash) or -h (hold). Note that each part of the person's name must be separated from the other by an underscore. If you are logged in from the from the keyboard, you can specify CON for the route file and Opus will let you key in one Z:N/N.P F_L entry at a time. Press ENTER to finish. 3.4 IMPLEMENTING OEC FILES Opus Embedded Command (OEC) files probably offer room for the most creativity. You can use embedded commands, video and cursor commands to create lavish widgets for callers. Entering the control codes for Opus Embedded Commands can be tricky depending on the facilities offered by your favourite wordprocessor for entering. There are some tools available that will make this task somewhat easier for you: OEC Compilers and a program called CTRLCODE. OEC compilers let you use "English" like commands to create your OEC files. You then "compile" these plain text files into the OEC files. The compiler translates the English expressions into the relevant control codes (correctly with a byte of luck). Grizzled Opus veterans will probably prefer to enter the control codes directly. Even this task is made considerably easier with the CTRLCODE program. This program lets you create a text file containing the caret sign "^" (the "^" sign is located above the number 6 on the top row of your keyboard) followed by the appropriate letter. So, you type ^X which is two text characters, then run CTRLCODE which will convert those two characters into the corresponding single character control code. Follow that? Sorry, you really do have to be a grizzled Opus veteran . SETTING UP OPUS V1.70 Page 43 Example uses of only some of the many OECs available are set out in the following sections. The sections only just begin to scratch the surface when it comes to OECs. For the complete listing of OECs and explanation of OEC files, refer to section 4 of the Technical Reference Manual. 3.4.1 QUOTATION OF THE MOMENT You can set Opus up to display a quotation of the moment to callers by, for example, embedding ^F^A in your WELCOME file (to show the quotation at logon) or your BYEBYE file (to show the quotation at logoff). If you are going to use the welcome or byebye files, do not forget to define the USES WELCOME and USES BYEBYE options in the Session Section of your control file (BBS.CTL). To use the quotation option, you must also have defined a quotation file with the USES QUOTES option in the Session Section of your Opus control file. For example: USES QUOTES c:\opus\misc\quotes The format for the quotation file is fairly simple. It is a normal text file. Each quotation is separated from the other by a single blank line. Here is a sample: Sex is hereditary. If your parents never had it, chances are you won't either. JOSEPH FISCHER Real knowledge is to know the extent of one's ignorance. CONFUCIUS A committee is a body that keeps minutes and wastes hours. W.G.P. A fool says "I can't"; A wise man says "I'll try". ANON You could also make the quotation of the moment an option off one of your menus. _SHOW Disgrace "Quotes" = c:\opus\misc\quote And QUOTE.BBS would contain: Quotation of the moment: ^F^A ^A Page 44 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 3.4.2 PASSIVE QUESTIONNAIRES Opus allows you to implement questionnaires in OEC files. Here is a sample questionnaire using OECs followed by an explanation (line nos have been added for the commentary that follows only): 00 ^K 01 ^OOc:\opus\misc\answers 02 ^OP 03 04 Stop typing by here --v 05 |----------------------------------------------| 06 Street Address: ^ONAddress 07 |----------------------------------------------| 08 City, State : ^ONCityState 09 |----------------| 10 Postcode : ^ONPostCode 11 |--| 12 Age : ^ONAge 13 |----------------| 14 Home Phone : ^ONHome 15 |----------------| 16 Work Phone : ^ONWork 17 18 How did you hear about this bulletin board? (you have 2 Lines) 19 1--------------------------------------------------------------| 20 ^ONInfo 21 2--------------------------------------------------------------| 22 ^ONInfo 23 24 Thanks, THE SYSOP. 25 26 ^A Line 00: ^K turns off the More prompt which would otherwise mess up your questionnaire. Line 01: ^OO opens an answer file for the caller's responses and for the information collected in line 02. Line 02: ^OP posts the caller's name, city/state and the date/time of the call to the answer file declared in line 01. Line 03: Blank (purely for aesthetics). Line 04: Limit caller input; in fact, Opus will accept up to 79 characters plus an ENTER. Line 05: As line 04. Line 06: ^ON is used to collect input from the caller. The is optional, but very useful for reminding sysops with short-term memory loss of the question that goes with the caller's answer. SETTING UP OPUS V1.70 Page 45 07 - 25: More of the same. Line 26: ^A pauses the screen and prompts the caller to press ENTER to continue. An answer file created by the above questionnaire looks like this: * Trev Roydhouse Remuera Auckland 12 Jul 91 11:46:18 ADDRESS: 11 Westbury Crescent CITYSTATE: Remuera, Auckland POSTCODE: 5 AGE: No HOME: 546-065 WORK: 546-065 INFO: I saw your ad on Kinko's BBS a few weeks ago and have been INFO: meaning to call ever since. 3.4.3 ACTIVE QUESTIONNAIRES As well as "passive" questionnaires, the Opus Embedded Commands also allow you to create "active" questionnaires. That is, questionnaires which ask questions or perform actions based on the caller's answer to the previous question. Here is a sample questionnaire using OECs followed by an explanation (line nos have been added for the commentary that follows only): 00 ^K 01 ^PNTX 02 ^OOc:\opus\misc\tennis 03 ^OP 04 ^F^F, are you a tennis fanatic? (y,N) ^ORYN| 05 ^OMFanatic 06 ^OUN ^OQ 07 ^OU| ^OQ 08 ^OUY You are! Prove it ... 09 ^OUY 10 ^OUY The year of the first Australian Davis Cup win was: 11 ^OUY a. 1900 b. 1939 c. 1942 d. 1946 12 ^ORABCD| 13 ^OMAnswer 14 ^OUB 15 ^OUB Correct! You will now have access to the Tennis 16 ^OUB EchoMail message area. Type 40 or DEUCE at the 17 ^OUB Message Menu Change Area prompt. 18 ^OUB ^PAT ^OQ 19 20 Wrong! 21 ^PAX ^OQ Line 00: Turn off that pesky more prompt. Page 46 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL Line 01: If the caller does not have the keys specified by ^PN (here the T key) sees rest of file (see below for significance of T). Line 02: See line 01 for explanation. NOTE: ^PNTX would not work -- that means if the caller does not have the T _AND_ X keys, see rest of file. Line 03: ^OO opens an answer file for the caller's responses and for the information collected in line 04, 06 and 14 for the sysop's future reference. Line 04: ^OP posts the caller's name, city/state and the date/time of the call to the answer file declared in line 03. Line 05: ^F^F displays the caller's first name for the personal touch. ^OR defines the valid responses to this question. In this example they are Y, N or ENTER. Line 06: ^OM posts the caller's answer to a multiple choice question in the answer file. optional, but very handy for reminding the sysop with short-term memory loss what the question was that goes with the answer. Line 07: ^OU will execute if, and only if, the caller's previous response matches the specified character. ^OQ terminates the OEC file. Line 08: As for line 07, except that it caters for the ENTER response. Line 09: As for line 07, except that it caters for a Y response. 10 - 12: More of the same. Line 13: ^OR see line 05 for explanation. Line 14: See line 06 for explanation. Line 15: See line 07 for explanation. 16 - 18: More of the same. Line 19: This line executes if, and only if, the caller's response was that specified by ^OU; in this case B (the correct answer). ^PA adds the specified key to the caller's keys; in this case the key T is added to give the caller access to the Tennis echo. ^OQ terminates the OEC file. Line 20: Ah yes, some people will try anything! SETTING UP OPUS V1.70 Page 47 Line 21: But only once! See line 19 for explanation; in this case the caller is given the X key to prevent any further attempts (see line 02) to answer the question correctly. The ^OQ is probably not needed, but I like working with safety nets. An answer file created by the above questionnaire looks like this: * Trev Roydhouse Behind The Screen 12 Jul 91 13:19:08 FANATIC: N * Joe Blow No Fixed Abode 12 Jul 91 13:24:27 FANATIC: | * Trev Roydhouse Behind The Screen 12 Jul 91 13:24:52 FANATIC: Y ANSWER: B 3.4.4 SENDING A MESSAGE TO THE NEXT CALLER You can allow callers, even on single line systems, to send a message to the next caller by using the ^FL OEC. Opus will not ask the caller which task to send the chat message to; it selects the current task. This OEC could be put in your BYEBYE file (make sure you have defined this file with the USES BYEBYE option in the control file) like this: Leave a message to the next caller? [y,N] ^ORYN| ^OY ^FL Then the caller could leave a CHAT## to the current task number and hang up. The next caller comes on line and as soon as that caller hits a menu, Opus displays the message from the last caller. Page 48 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 3.4.5 OEC FILE STACKING The ^OA OEC starts displaying . When is done, Opus returns to the current file at the current position. You can stack this command. Here is an example: file1.bbs contains: file3.bbs contains: This is file1.bbs This is file3.bbs ^OAfile2 ^OAfile4 This is file1.bbs This is file3.bbs ^OAfile5 This is file1.bbs file4.bbs contains: This is file4.bbs file2.bbs contains: This is file2.bbs file5.bbs contains: ^OAfile3 This is file5.bbs This is file2.bbs The above sequence of OEC files would display to a caller as follows: This is file1.bbs This is file2.bbs This is file3.bbs This is file4.bbs This is file3.bbs This is file2.bbs This is file1.bbs This is file5.bbs This is file1.bbs This OEC uses a doubly linked list so the limitation is how much memory your system can find, but it is recommended that it be kept down to 4-5 deep. Another method of OEC file stacking is by using the ^OX OEC. This OEC records the current position in the current file, jumps to (position is the number of bytes from the beginning of the file) and when ^OY is encountered, Opus returns. Here is an example: This is the beginning of MAIN Menu.... ^OX0105 And this is back to MAIN.BBS ^OQ This is some point further along in Main MENU ^OX0226 This is back to mid-point further along in MAIN MENU ^OY This is yet further along in MAIN MENU SETTING UP OPUS V1.70 Page 49 The above example would display as follows: This is the beginning of MAIN Menu.... This is some point further along in Main MENU This is yet further along in MAIN MENU This is back to mid-point further along in MAIN And this is back to MAIN.BBS This OEC can be stacked up to 10 levels deep. 3.4.6 COMMAND BUFFER STUFFING The ^OG OEC stuffs commands into the command buffer and quits the OEC file. You may use any commands available from the current menu. For example, if you have an OEC that ends with ^OGG, Opus quits the OEC file and starts the logoff procedure. You can also have it go to the download, upload, statistics, or any of the codes that are valid for the CURRENT menu. You can set up a fairly complex script via stacked commands, using either Escaped Hex codes or plain ASCII. Here is a script that you might use as a "fail-safe" to clear graphics: _SHOW Twit "If_All_Else_Fails" = c:\misc\bomb BOMB.BBS 10f1 C V P H N Q (Main Menu, Change Menu, Video/Plain, Help/Novice, Quit to Main menu) Suppose at the end of an OEC file off your File Menu which listed "MY_LIST.BBS" you included: Download this file? Z)modem Y)modem X)modem K)ermit N)one ^ORZYXKN| ^OUZ dz my_list.bbs ^OUY dy my_list.bbs ^OUX dx my_list.bbs ^OUK 5004 k my_list.bbs ^OUN ^OQ ^OU| ^OQ Opus starts the download with the right protocol if a caller wants to download the file. You can also use the Full Tilt Boogie (FTB) menu commands by preceding them with an escape. What you are doing is stuffing the command buffer with keystrokes. If you send Opus off to do something illegal, because of privileges or whatever, it will be Page 50 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL handled just as though the caller were pressing the keys. The full list of FTB commands is listed in section 4 of the Technical Reference Manual. 3.4.7 REGULATING PEAK TIME CALLER ACCESS To have Opus only allow those callers with a privilege level of Favored or higher to log on during specified hours, create two WELCOME files, a standard one named WELCOME1.BBS and a special one named WELCOME2.BBS that has the following at the beginning: 00 ^L 01 ^PBF ^OSwelcome1 02 ^PBF ^OQ 03 04 I'm sorry, but this system runs restricted access between the 05 hours of {start-time} and {end-time}. 06 07 Please call back after {end-time} 08 09 Thank You, THE SYSOP. 10 11 ^F^N Line 01: Clears the screen (aesthetics again) Line 02: If caller's privilege is below Favored, skip this line. Callers at or above Favored are shown the normal WELCOME file. Line 03: Quit this OEC file now for Favored callers. 04 - 10: Message for callers below Favored. Line 11: Hang up on callers below Favored. Then setup an informal external event to run at {start-time} that exits with a DOS errorlevel of, say, 50 which is trapped by your NERF.BAT file like this: IF ERRORLEVEL 50 GOTO REST_ACCESS [etc] :REST_ACCESS COPY WELCOME2.BBS WELCOME.BBS GOTO START_OPUS SETTING UP OPUS V1.70 Page 51 and at {end-time} run another informal external event that simply exits with a DOS errorlevel of, say, 49 which is trapped by your NERF.BAT file like this: IF ERRORLEVEL 49 GOTO REST_ACCESS [etc] :NORM_ACCESS COPY WELCOME1.BBS WELCOME.BBS GOTO START_OPUS For a commented, sample NERF.BAT file refer to Appendix A of this manual. For information on scheduling informal events, refer to the section of this manual which describes the Opus Event System. 3.5 EXTERNAL PROGRAMS External programs provide lots of help in customising your Opus CBCS. Here are a few which were available at the time of publication: CAYENNE ... a program to de-compile your Opus control file, also used in conversions from the previous Opus version CONFILE ... a program to convert the old FILES.BBS file listings into the Opus V1.70 files database DOORMAGIC ... a program to create various "door" control files for running "outside" or "door" programs written for other BBS software NACL ... a program to compile your Opus control file O_RENUM ... an Opus message area renumberer OEVENT ... the Opus event manager OFARE ... a program to re-index your Opus V1.70 files database OPHONE ... an external chat program OPUS-FAM ... the Opus File Area Manager OUFM ... an Opus User File Manager PTIC ... a program to add new "ticked" files to the files database UNCON ... a program to unconvert the new Opus V1.70 files database into the old FILES.BBS file listings Page 52 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 3.6 MESSAGE AREAS Message areas and the method of storing messages in Opus V1.70 are the same as in previous versions of Opus. The setting up and maintenance of message areas is discussed in the following sections. 3.6.1 CHECKLIST FOR NEW MESSAGE AREAS Checklist for setting up a new message area: * Create a subdirectory for the message area; * Edit your BBS.CTL file to include the new message area definition in the Message Areas Section; * Run NACL against your modified BBS.CTL file (refer to the section of this manual on control file maintenance for the gory details). 3.6.2 SAMPLE MESSAGE AREA DEFINITION Message area definitions are found in the Message Areas Section of your control file. Here is a sample message area definition which lists all the possible control file options for such a definition: SETTING UP OPUS V1.70 Page 53 AREA 001 GENERAL % NAME % MENU % SECTION % PRIVATE MESSAGES ONLY % PUBLIC MESSAGES ONLY % READ-ONLY % ANONYMOUS OKAY % ALIAS % ROUTE LOCAL % ECHOMAIL % MATRIX ACCESS PRIV Disgrace EDIT PRIV Disgrace % ACCESS LOCK % EDIT LOCK PEEK PRIV Sysop % PEEK LOCK % Upload PRIV % Upload LOCK PATH c:\msg\general\ TITLE General Interest Messages [Local] % MAXLINES % BARRICADE % ADDRESS % ORIGIN % DOMAIN % PICTURE % HELP % CHARSET % PASSTHROUGH % INBOUND-ONLY % SCAN % APPLICATION % EXTERN RENUM % EXTERN MAILCHECK END AREA You guessed it, please refer to section 2 of the Technical Reference Manual for a detailed description of each of the control file options in the sample message area definition above. NOTE: In pre-V1.70 Opus versions, areas had to be numbered consecutively. If you skipped a number, all higher-numbered areas were invisible to callers; although they were still accessible, they did not appear on the Opus-generated area change list. This does not apply to Opus V1.70. All message areas will show up on the Opus-generated area change list EXCEPT where the caller does not have thee required privilege level or key(s). Page 54 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 3.6.3 AREAINFO FILES You can put an AREAINFO.BBS (or AREAINF~.BBS file for systems which support more than one language) file in each message area directory. This file will then be shown to every caller each time the caller enters the relevant message area. You could use the file for displaying the rules of that specific message areas. It is particularly useful in trading post echomail areas for warning callers not to place commercial advertisements, for example. As the file is a normal OEC file, you can stop it being shown to your trusted callers over and over again by using OECs to only show it to those with a certain access level or below or without certain keys. 3.6.4 SMART RULES FILES There is a "smart" menu command which you can use to allow callers to display the rules file in message areas. You put the MSG_RULES menu command on your message menu and it will only show up when a RULES.BBS (or RULE~.BBS file for those systems which support multiple languages) file is found in the relevant message area directory! In addition, Opus will automagically show the rules file, if it exists, to any caller whose lastread message pointer for the area is zero. In file areas, you need to define the rules file in the file area definition using the RULES control file option. The file will only be shown to those callers who have never before entered the relevant file area (you can cause it to display again by deleting the LFILE.DAT file in that file area's download directory -- that file stores who was in the file area and when for use by one of the Opus Embedded Commands). Refer to section 2 (areainfo and rules files) and section 4 (OECs) of the Technical Reference Manual for further details. 3.6.5 MESSAGE AREA MAINTENANCE Messages are stored in individual files. Message #1 is in a file called "1.MSG", for example. Large gaps between message numbers can cause big online delays. There are several public domain message renumber utilities. You should renumber message areas regularly. One thing you should also do occasionally: reorganize your physical drive. Several utilities are available (eg, Optimize, DOG, SD) to do SETTING UP OPUS V1.70 Page 55 such things. They are handy and highly recommended. In technical terms, these programs "de-fragment" your disk. Run them once a month or so. 3.7 FILE AREAS Probably one of the biggest changes between Opus V1.70 and previous Opus versions is the fact that V1.70 now uses a database for keeping track of files instead of the plethora of individual FILES.BBS files that the grizzled veteran Opus sysop either learned to love or loved to hate. Despair not! Utilities have been provided to convert FILES.BBS files into the new files database AND to unconvert the new files database into FILES.BBS files AND to manage the new files database. 3.7.1 THE FILES DATABASE The Opus V1.70 files database is actually a system of three files. One file contains all the information about what files you have on your system (FILESBBS.DAT), one is the index to all the file names on your system (FILESBBS.NDX), and one is an index into the first file in each file area (FILESBBS.ADX). Here are a few of the highlights of the new files database: * You can specify where in each file area listing new files will be added either when U)ploaded or H)urled by inserting a greater than sign > in the listing for an area. Normally new files are appended to the end of the listing for an area. * You can specify full paths to files if they are not in the default directory for that file area. This will probably be of benefit to those sysops who run CD-ROM drives on their systems. * Who uploaded the file and when is stored with each file. * The file date and time is preserved when files are received via Zmodem transfers. The search for new files will look at the upload date/time, but the callers will see the actual file creation time when they do a F)iles listing. * When a caller does a L)ocate, or searches for a string with the F)iles command, they also optionally (sysop configurable by privilege) get an additional line of information including who uploaded the file and when. * The F)iles display has been modified so it does a word-wrap for callers who have screens wider than 60 characters. File descriptions may be up to 256 characters long. Page 56 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL * Each individual file can have its own download privilege and locks. Normally they will be set to the area's download privilege and locks, unless you have set the NEW PRIV option in the file area definition. You can also override the privilege and locks on a file- by-file basis. * If a caller tries to download a file from an area, and the file does not exist in that area, Opus will look for the file in all the other areas to which the caller has access and, if it finds it, the download will continue as normal! * Opus will not allow callers who have privilege below ASSTSYSOP to upload duplicate file names anywhere unless the DUPES option has been specified in the file area definition. * If a caller has never been in a file area before, and the sysop has defined a RULES file in that area's definition, Opus will show the caller that file. The idea behind this is that you might want to have some areas that have minimal restrictions on them, like an area that has nude GIF files in it. You could ask "Are you over 18?" and if the answer is no, send the caller somewhere else using OECs. * If you implement the FREE control file option in a file area definition, then Opus will not consider files downloaded from that area to be part of the callers upload:download ratio or daily download limit. This should work properly even when callers are downloading a batch of files from different areas. The only problem is that Opus will not know which files are "free" and which are not when reading the log file produced by external protocol drivers. It will add the file sizes to the total downloads and daily downloads when using an external protocol. 3.7.2 CONVERTING TO THE FILES DATABASE You convert your old-style FILES.BBS file area listings to the new files database by running the CONFILE program. Please refer to the documentation supplied with CONFILE for a blow- by-blow description of this procedure. 3.7.3 CHANGING FILE AREA NUMBERS What do you do when you want to move a particular file area to a different area number? For example, you want to make your current games files area which is area 15 into a new area 88. You have a lot of typing to do, right? Wrong. John Valentyn sent along this recipe just for you: SETTING UP OPUS V1.70 Page 57 * Run UNCON to take all the file descriptions for area 15 from the files database to create an old-style FILES.BBS file for you; * Edit your control file (BBS.CTL), changing file area 15 to file area 88; * Run NACL against a copy of your control file that includes the Message and File Area Sections (refer to the section of the manual dealing with control file maintenance for more details); * Run OFARE, which will see that area 15 has been deleted and that area 88 is a new area, and will merge the FILES.BBS for area 88 back into the database. 3.7.4 SETTING UP NEW FILE AREAS Checklist for setting up a new file area: * Create a download subdirectory for the file area -- the download subdirectory contains the files you want to make available to your callers; * Copy the relevant downloadable files into the download subdirectory; * As necessary, create an upload and/or private upload and/or keyed upload directory for the file area -- the upload subdirectory/ies is/are the hold any files that callers might send to you; * Create an old-style FILES.BBS file listing which includes the descriptions of the files for the new file area -- the FILES.BBS file is a normal text file which contains the filenames beginning in column 1, followed by a space character, followed by the description of the file; comment lines must be indented at least one space character or they will be treated as filenames. There is also an EFW (environmentally friendly widget) bonus with the new files database -- an "alternative file path" for pointing to files that are not in the relevant file area directory, but are in another directory elsewhere on your system. Why EFW? It saves you hard disk space! To take advantage of this EFW, you put the full path to the file in the FILES.BBS file in addition to the filename, for example: z:\file\thisfile.zip Folks with CD-ROM drives may also like to take advantage of the fact that you can also put the full path to a file in the FILES.BBS file, so that when it is converted in the files database, the file path will be correct. Page 58 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL * It is a good idea to leave 4 lines at the beginning of the new FILES.BBS listings so that the HiTech menus do not leave the topmost two or three lines of the listing on the screen -- in fact, this is a feature and not a bug. The first few lines are reserved for the a file area heading which is not erased each time the screen scrolls; * Edit your BBS.CTL file to include the new file area definition in the File Areas Section of the control file; * Do NOT forget to include an upload area number in your file area definition or you will experience this problem: > Also, I have uploaded files going into a particular > directory. The files go there, but when I do a new > files scan, they are listed in the area the caller was > in when the file was uploaded. In the area the caller > uploaded, the file and description are listed, in the > upload area, the file without a description are also > listed. UPLOAD PATH H:\NEWFILES\ <-----------------| Path UPLOAD AREA 31 <-----------------| Area # * Run NACL against your modified BBS.CTL file (refer to the section of this manual on control file maintenance for the gory details); * Run OFARE to update the files database. 3.7.5 SAMPLE FILE AREA DEFINITION File area definitions are found in the File Areas Section of your control file. Here is a sample file area definition which lists all the possible control file options for such a definition: SETTING UP OPUS V1.70 Page 59 % AREA 0001 INFO % % MENU % SECTION TITLE Information File Area % PREFILES % ACCESS PRIV Disgrace % ACCESS LOCK % DOWNLOAD PRIV Disgrace % DOWNLOAD LOCK DOWNLOAD PATH C:\FILES\INFO\ % % BARRICADE % RULES % PICTURE % HELP RATIO PRIV Twit % % Default Upload Area UPLOAD PRIV Hidden % UPLOAD LOCK UPLOAD PATH C:\FILES\NEW\ UPLOAD AREA 3 NEW PRIV Disgrace % DUPES % FREE % % % PRIVATE Upload area by Privilege PUPLOAD PRIV Twit % PUPLOAD PATH PUPLOAD AREA 3 % % PRIVATE Upload area by Keys % KUPLOAD LOCK % KUPLOAD PATH KUPLOAD AREA 3 % % APPLICATION % END AREA % You guessed it, please refer to section 2 of the Technical Reference Manual for a detailed description of each of the control file options in the sample file area definition above. Page 60 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 3.7.6 FILES DATABASE MAINTENANCE When a caller uploads a file, Opus will automatically put the file into files database. To add, delete or move files from the files database, or to edit the file descriptions, use the Opus File Area Manager (OPUS-FAM) program. Uhuh, please refer to the documentation that comes with OPUS-FAM for full details of this procedure. OPUS-FAM will also run in batch mode to produce file listings for file request lists (see below). You can also use Opus itself to "adopt" files which are not listed in the database, "orphan" files that are listed in the database, and "hurl" files from one area to another INCLUDING across physical drives! Yep, go check out section 3 of the Technical Reference Manual for the appropriate menu commands to include on your file menu. If you have other programs that need access to the old-style FILES.BBS file listings, use the UNCON program. UNCON with no parameters will regurgitate FILES.BBS in all areas, or you can put a list of areas on the command line and only those areas will get new FILES.BBS listings. UNCON.EXE will rename any existing FILES.BBS to FILES.BAK before writing the new FILES.BBS. To do minor, automatic maintenance there is OFARE. OFARE should be run as part of your automatic housekeeping like renumbering messages. It performs a number of functions, including re-packing the database as new files are added, expanding wildcard listings in the database to reflect any new files that have been added or deleted, eliminating files that have been deleted from the database and, optionally, eliminating any "Missing" files from your database. Here is a sample batch file: REM Sample nightly housekeeping REM Pick up any new files and remove deleted and missing files ofare /m REM Save the old files database in case of trouble pkzip -mex oldfiles filesbbs.o* REM Update FILES.BBS to match the database uncon 1 2 3 4 5 6 7 8 10 REM Produce the FILES lists opus-fam -l SETTING UP OPUS V1.70 Page 61 3.8 BARRICADED MESSAGE AND FILE AREAS You can "barricade" message and file areas in Opus so that a caller needs another password to get into the area. This password not only admits the caller to the area, but is associated with a privilege level which the caller will have ONLY while in that area. Be careful that the privilege level associated with each password is equal to or higher that the privilege required for access to the area and its associated menu commands. Whenever users leave a barricaded message or file area, they lose the higher or lower privilege which was conferred on them. As an added security measure, if a user logs off or otherwise disconnects while in a barricaded area, Opus always resets the last message or file area accessed, as appropriate, to area number 1 and resets their privilege level to what it was before they entered the barricaded area. YOU CANNOT, THEREFORE, BARRICADE FILE AREA NUMBER 1. Unlike Opus 1.1x, both message and file areas may be separately barricaded by defining a password file associated with the relevant area definition in the control file. To implement barricaded areas you need to define a generic "warning" file shown to callers who attempt to enter the barricaded area. This is defined using the USES BARRICADE control file option which you will find in the Session Section of your control file. Here is a sample warning file: Warning! Warning! ^G^G^G This is a password protected area. If you have stumbled in here by mistake, press ENTER or RETURN to return to the system. Any other action will be recorded as an attempt to enter this area and you will be disconnected. In fact, Opus will not disconnect the caller if the caller incorrectly guesses the password twice in a row. Instead, Opus will return the caller to the area change menu. Your callers do not know that though! You also need to define a "password" file which contains the passwords and associated privilege level. The file may also contain a caller's name and an associated privilege level, in which case the caller will not be asked for a password, but will be admitted to the area with the assigned privilege (useful for co-sysops maybe). This password file is defined with the BARRICADE option in the area definition section of your control file. Each area may have its own password file, or you may use the same one in each area. Here is a sample password file: Page 62 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL SESAME ASSTSYSOP ;for area moderator SHILOH PRIVIL ;for those who can enter echomail messages GREYSTOKE NORMAL ;for those who cannot enter messages PERFECT NORMAL ;for those who cannot enter messages K9W3F1 SYSOP ;for the sysop Ken Morgan TWIT ;for poor Ken Joe Smith NORMAL ;for Joe Neither Ken Morgan nor Joe Smith would have to give a password for the barricaded area. Instead, their privileges would be automatically set by Opus. The comment field after the password is optional, but handy to keep track of who has what access. 3.9 WELCOME FILES Opus has a rich assortment of welcome files available for you to bend your mind with. Here's a summary: * The standard WELCOME file; * Custom welcome files (CWFs); * Special announcement files (SPANNs); * The special OEC file (SPOEC). For the particular sequence in which Opus will show these files to a caller, refer to the flowchart of the Opus login sequence in section 5 of the Technical Reference Manual. 3.9.1 THE STANDARD WELCOME FILE The standard welcome file is shown to ALL your callers, if you have defined such an file with the USES WELCOME option in the Session Section of your control file. As this is just a normal OEC file, you can use the Opus Embedded Command set in the file to do WAW (wierd and wonderful) things. SETTING UP OPUS V1.70 Page 63 3.9.2 SPECIAL ANNOUNCEMENT FILES Special announcement files are shown only to those callers whose records in the Opus user file you tweak. There are five "counters" in each caller record for associated special announcement files. The counters can be set to show each of the five special announcement files a certain number of times (up to a maximum of 255). Opus will then show the caller the corresponding special announcement file and decrement the counter by one each time the caller logs on to your system. To implement this option, you need to define the PATH SPANN option in the System Section of your control file to point to the directory in which the special announcement files will be stored. The special announcement files are named SPANNn.BBS where "n" is a number from 1 to 5 to correspond with the five counters in each caller's record in the user file. The SPANN file is a normal OEC file, so you can use the full set of OECs in it. Here's a sample SPANN file: >>>> Access Upgraded <<<< ^F^F, as you have correctly answered the Q)uestionnaire, your access has now been upgraded to VERIFIABLE member. Choose O)utside from the M)ain Menu, then M)embership details for further information regarding membership. TREV. (Sysop: Sentry (02) 428-4687 & Sentry's Shadow (02) 418-6682) ^A No, there is more. You also need to set the relevant SPANN counter(s) in the caller's record in the user file. You can either use a program called, appropriately enough, SPANN (by Doug Boone) or OUFM (the Opus User File Manager by yours truly) to set these counters either globally or for specific callers. 3.9.3 CUSTOM WELCOME FILES Custom welcome files (CWFs) are shown to individual callers only. The files are shown again and again until you delete them, or you can rig up a file which will delete itself using OECs after it has been shown. For once, you do not have to specify anything in your control file! Instead, there is a special format for the CWF filename: the filename is based on the caller's record number in the user file. The records in the user file are 1-based (ie, the first record is number 1) to make life easy for you. The files have the standard OEC file extension (.BBS -- if you use .GBS you better make sure that the caller has the required video mode set or the caller will not see your handiwork). Page 64 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL The CWFs must be stored in the same directory as the one from which you run the Opus program. One last point, you do not need to put a ^A pause OEC in these files as Opus will add one automatically at the end of the file for you. 3.9.4 SPECIAL OEC WELCOME FILES Special OEC welcome files (SPOECs) are shown only to those callers you select. There is a field in the caller's record in the user file for defining an 8 letter filename without the extension which is assumed to be the standard OEC file .BBS/.GBS extension. You can define this file using the OUFM (Opus User File Manager) program. This file REPLACES the normal welcome file shown to all callers (ie, the SPOEC file is shown instead of the normal welcome file). I have one defined in my user record to bypass the normal logon bulletins; although you could also skin this hassle by using privilege level OECs in the normal welcome file. If your system is used by a club of some sort, a SPOEC file may be useful for showing only club members details of upcoming events. The only limit is your imagination. 3.10 THE RELOGGING FUNCTION If you, or your callers, need to exit Opus to run a particular online program, you can relog on to the system and end up back at the menu which you exited from without having to go through the normal log on procedure! The infamous Opus relog function . To implement the relog function you need to set the SECURE, RELOG and AFTER RELOG EXIT options in the Session Section of your control file. Go on, refer to section 2 of the Technical Reference Manual for details of these options. To exit from Opus you need to set up an _OUTSIDE EXIT menu command off one of your menus like this: _OUTSIDE Sysop "Drop to DOS" = EXIT 15 SETTING UP OPUS V1.70 Page 65 and then trap the DOS errorlevel of 15 in your NERF.BAT batch file like so: :OPUS CHAT 30 SET PORT=2 OPUS BBS :TEST IF ERRORLEVEL 255 GOTO ERROR255 [...] IF ERRORLEVEL 15 GOTO DOS IF ERRORLEVEL 4 GOTO ERROR4 IF ERRORLEVEL 3 GOTO ERROR3 IF ERRORLEVEL 2 GOTO ERROR2 IF ERRORLEVEL 1 GOTO OFFLINE GOTO ERROR0 :DOS NEWBAUD Q:\OPUS\LASTUS00.DAT IF ERRORLEVEL 96 GOTO REMOTE_DROP IF ERRORLEVEL 48 GOTO REMOTE_DROP IF ERRORLEVEL 24 GOTO REMOTE_DROP IF ERRORLEVEL 12 GOTO REMOTE_DROP IF ERRORLEVEL 3 GOTO REMOTE_DROP IF ERRORLEVEL 0 GOTO LOCAL_DROP :REMOTE_DROP CTTY COM%PORT%: :LOCAL_DROP COMMAND :RETURN Q: CD Q:\OPUS CTTY CON OPUS BBS -O GOTO TEST and you need to re-run Opus with the -O command line switch. IMPORTANT: make sure you define an AFTER RELOG EXIT errorlevel and that the flow of your batch file does not keep executing Opus with the -O command line switch or else ... > Hi everyone, I've been having this strange problem and I > can't figure it out. ... Opus reload will reload itself over and over again after each caller who goes outside. Page 66 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 3.11 EXPIRATION CONTROL SYSTEM The optional Opus caller expiration control system allows the termination of caller access based on either expiration date or minutes given and used, or both. Since this system operates independently of the existing daily time and file download limiting, all three forms of limiting can be used in combination. All control settings are made on a per caller basis so you can have a mix of callers with different forms of limiting. Additional per-user settings control whether a caller is disconnected, demoted, both, or neither. 3.11.1 EXPIRATION CONTROL METHOD Expiration control may be based on: Date ..... When a caller's ByDate flag is enabled, that caller is "expired" on the given expiry date. Time ..... When a caller's ByTime flag is enabled, that caller is "expired" when the caller has used (debited) as many minutes as the caller was given (credited) as shown by the Debit and Credit minutes fields in the caller's user record. These fields act in much the same way as the FidoNet credit/debit fields do in that they continually accumulate and their difference is the actual balance remaining. You can set a caller's user record for both Date and Time expiry so as to allow the case where you want a user to consume their given minutes within some calendar time frame to avoid the case where some low activity caller takes 10 years to use the 30 minutes of usage credit. 3.11.2 HANDLING EXPIRED CALLERS The way an expired caller is handled is controlled by the AxeUser and DemoteUser flags in the caller's record. If neither is set then the caller will only get the relevant warning and/or expiration messages (see the section on Implementing Expiration Control below). DemoteUser .. If enabled, the caller's privilege is reset to the expiration privilege value in the control file. If that value has not been set, then the caller is forced to the lowest privilege (Twit). AxeUser ..... If enabled in the caller's record, the caller is rather unceremoniously disconnected by Opus. SETTING UP OPUS V1.70 Page 67 Both Demote and Axe can be used together so that you can reduced a caller's privilege level and stop the caller from logging on. That may be handy when you want to signal an external maintenance utility by setting the privilege level to something unique for further, external processing or purging. 3.11.3 IMPLEMENTING EXPIRATION CONTROL First of all, you need to decide how you are going to implement the expiration control system (if at all). You can make expiration control automatic for all new callers to your system by defining the LOGON XDAYS and/or LOGON XMINS and EXPIRE PRIV options in the Session Section of the control file. You may also want to define the EXPIRE DAYS, EXPIRE MINUTES and USES XDWARN, USES XTWARN, USES XDGONE, USES XTGONE options in the Session Section of your control file. The USES XD/XTWARN options allow you to define OEC files to give callers separate expiration warning messages for date and time expiry when callers are within a preset number of days or minutes from expiration. These time limits are defined with the EXPIRE DAYS/MINUTES options. The USES XD/XTGONE options allow you to define OEC files to give callers expiration messages for date and time expiry when callers have expired. When the caller is within the preset number of days from expiration, the caller would be shown XDWARN.BBS at logon. Here is a sample file using the expiration OECs: G'day ^F^F, I just thought you should know that your access to this system will expire in ^XD days on ^XC. ^A If the current date is greater than or equal to the expiry date you have set, then the caller is shown XDGONE.BBS which would typically say: >> Attention << Access Expiration >> Attention << ^F^F, your access to this system expired on ^XC. Please bribe the Sysop NOW if you wish further access! ^A Page 68 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL To implement expiration control fo your existing callers, you will need to use OUFM (Opus User File Manager) to set the relevant fields in the callers' user records. Refer to the documentation that comes with OUFM for further details. 3.12 "SECTIONS" OR "SIGS" Each online user of a system can be allocated a "section" by the sysop at logon, or can define their own section from the section menu if it has been implemented. The ability to choose sections from the section menu can, of course, be restricted by privilege level and/or by locks. A section restricts a user's access to your Opus system. It is used to allocate message and file areas, so that a user will only be able to access those areas which are included in their allocated or chosen section. You can look at sections as being something like TBBS Sigs, except that the use of sections in Opus is optional. Callers could use MSG_NAREA and sections to make Opus operate somewhat like the old CP/M Citadel BBS system. When you read all the messages in one area and then go on to the next area with unread messages, you only get those areas that you were interested in. Or you can look at sections as being something like TBBS Sigs, except that users do not _have_ to use them. 3.12.1 SYSOP DEFINED SECTIONS You define the section(s) to which a message or file area belongs in the message or file area definition in the control file (BBS.CTL) using the SECTION item. For example, you could setup your system to have: * an Assembly language section (SECTION AP); * a C language section (SECTION CP); * a Turbo Pascal section (SECTION TP); and * a Programming section (SECTION P). If callers are allocated section P by the sysop at logon, or they choose that section themselves (if there is a section menu to which they have access), then they will only have access to those message and file areas which have either the P or A or C section set in their area definition (in this example, the Assembly, C and Turbo Pascal areas). If callers are allocated section A, or they choose that section themselves, they would only have access to message and file areas that have the "A" section set in their area definitions (in this example, only the Assembly language area). SETTING UP OPUS V1.70 Page 69 3.12.2 USER DEFINED SECTIONS A User Defined Section (UDS) is a section that callers can create on their own. Callers can have any combination of up to 80 areas in their section. They can have 1 file area and 79 message areas or 40 message areas and 40 file areas, or any other combination. Opus keeps track of how many message and how many file areas the caller has selected. Although in most ways UDS are just like any other section, User Sections have a couple of extensions to be considered, MSG_SCAN, F_NEW, MSG_NAREA, F_LOCATE and the NextArea/PriorAreas will no longer be concerned with high message/file area limits. They read the area table in the user record directly. 3.12.3 THE SECTION MENU A new addition to the Opus V1.70 menu system is the Section Menu. You do not have to have a section menu, it is optional. A sample section menu is set out below: % SECTION MENU _PICK_SECTION Disgrace "All areas" = _PICK_SECTION Disgrace "Programming" = PCA _PICK_SECTION Disgrace "LOCAL" = L _PICK_SECTION Disgrace "Buy & Sell" = B _PICK_SECTION Disgrace "Opus" = O _SHOW Twit "?Help" = C:\Hlp\Sections _MAIN Twit "Quit section menu" END Menu % It is worth pointing out that there is no misprint or typographical error in the first _PICK_SECTION menu command -- there is nothing after the "equals" sign. You NEED this option if you are going to allow your callers to get out of their sections. Without it, you will only cause yourself and your callers grief ... as several Beta and Gamma testers can attest. To allow callers to set up their own UDS (User Defined Sections) instead of choosing sections which have been set up in advance by the sysop, your section menu might look like this: % SECTION MENU _PICK_SECTION Disgrace "All areas" = _MAKE_SECTION Disgrace "Make area list" _MY_SECTION Disgrace "Use area list" _SHOW Twit "?Help" = C:\Hlp\Sections _MAIN Twit "Quit section menu" END Menu % Page 70 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL The _MAKE_SECTION menu command allows callers to add/delete message and/or file areas to their section. The _MY_SECTION menu command then allows callers to select their UDS. It is a good idea to include the "All areas" option so that callers can quickly and easily reset their area list to all areas without having to individually add message and file areas. 3.12.4 RELATED CONTROL FILE OPTIONS There are several options in the Session Section of your control file that you may need to define: USES MAKE c:\help\makesec This option defines the help file that will be shown before users start making their own user defined section or if they press '?' to get help. MAKESECTION ABC This option defines the section that callers will be dumped into while editing their section. Consider that if a user is inside their UDS, they could not add any new areas, because no more areas would be available to them! You should define this option. LOGON SECTION This option defines the section which will be assigned to all new callers to your system without sysop or caller intervention. USES SECTMENU This option defines the so-called "ASCII" menu to replace the "normal" Opus menu. SECTION This option is not in the Session Section of your control file. Look for it instead in the message and file area definitions. It defines the section(s) to which the particular message or file area belongs. As ever, full details of these control file option may be found in section 2 of the Technical Reference Manual. SETTING UP OPUS V1.70 Page 71 3.12.5 SAFETY FEATURE Sections have a special inbuilt safety feature to protect callers from themselves and you: if a caller goes into a section and fails to get into a file or message area for three tries, Opus will drop the caller back to the "default" section that you defined in your control file with the MAKESECTION option. You _did_ define that option ... better go do it now! 3.13 TIME ZONE SETTINGS Internally, Opus always works in Universal Coordinated Time (what was called Greenwich Mean Time when grizzled Opus veterans were not so grizzled). You are rarely affected by this. In fact, you may not have even realized it until now. Your SCHED.BBS (or whatever name you have defined in your control file for the USES SCHEDULE option) file is probably in local time ... so you need to tell Opus how to convert the time or you will have to learn to live in interesting times. Please find the item (below) that applies to you and put it into your AUTOEXEC.BAT file. USA EASTERN ---------------------------------------------- For standard time......... SET TZ=EST05 For daylight time......... SET TZ=EST05EDT USA CENTRAL ---------------------------------------------- For standard time......... SET TZ=CST06 For daylight time......... SET TZ=CST06CDT USA MOUNTAIN ---------------------------------------------- For standard time......... SET TZ=MST07 For daylight time......... SET TZ=MST07MDT USA PACIFIC ---------------------------------------------- For standard time......... SET TZ=PST08 For daylight time......... SET TZ=PST08PDT Page 72 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL OTHER (STANDARD) TIME ZONES ---------------------------------------------- Yukon..................... SET TZ=YST09 Alaska.................... SET TZ=AST10 Bering.................... SET TZ=BST11 Bratislava, Czechoslovakia........ SET TZ=CET-1 Sydney, Australia............. SET TZ=EST-10 Perth, Western Australia..... SET TZ=WST-8 The `TZ' means `Time Zone'. The first three characters are the initials used the time zone The final three characters represent the deviation from Universal Coordinated Time (UTC -- blame the French for it not being UCT). THE OPUS EVENT SYSTEM Page 73 +-------------------------------------+ | Events or ... | | | | things that go bump in the night. | +-------------------------------------+ 4.0 THE OPUS EVENT SYSTEM The first thing you need to understand about how events work in Opus V1.70 is to understand that the term "event" is convenient, but sort of misleading in some cases. What we are talking about are behaviour windows that modify the default behaviour that you have set in the Opus control file. Events, for some fixed period, change the way Opus will work during that period. In Opus, you can have an event that runs every day, just weekdays, just weekends, one day every week, or every Monday-Wednesday-Friday. Events can also run past midnight. You can have as many as 254 events in Opus, or as few as 1. There is no requirement that you have an external event every day. The event manager assumes that there is an event 24 hours away, and looks for anything closer. If it does not find anything, Opus will just report that the next event is 24 hours away and go on, 24 hours later, (assuming there have not been any calls in or out to reset the event manager), Opus will just go check the event file again. As virtually everyone using Opus 1.03 discovered, Microsoft's time library had a glaring weakness when dealing with UTC (Universal Coordinated Time, what used to be called GMT). Starting with V1.10, Opus does NOT use Microsoft's time library. The environment and the DOS clock are read directly. 4.1 TYPES OF EVENT There are seven basic types of event or behaviour window: Matrix: Changes the way Opus handles outgoing and incoming mail (often referred to as Z events). User: Changes the way Opus handles users, giving them more, or less, time and download privileges. Scan all: Forces Opus to scan all echomail message areas for new outgoing echomail messages. Housecleaning: Deletes all those pesky .$$5 files in the outbound mail holding subdirectory. External: Halts Opus operations to return control to DOS or a batch file. Page 74 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL Yell: Opus will allow the remote user to request help from the Sysop if allowed. Mailer: This event can be used to control whether the Opus internal mailer or an external mailer is used. Some types of event or behaviour window come in two flavours: Forced: These events MUST start at a certain time, and Opus will get Guido to do whatever it takes to prevent human users from interfering with the start of these events. If for some reason Opus is inactive when a forced event should have started, Opus will execute the event as soon as it starts up again. Informal: These events start and end on a more flexible schedule. They do not interfere with human callers by limiting the caller's time. Instead, they start as soon as Opus is free after the specified start time for the event. Opus will execute any informal events that have not run if it has been inactive for some reason. The following list shows which events are which flavour (if any): External event: can be forced or informal or neither (see below). Matrix window: always informal, unless they occur in those periods when you do not allow human callers. User events: always informal. Scan event: always informal. Yell event: neither forced nor informal. Mailer event: always forced. Housecleaning: always informal. 4.2 EXTERNAL EVENTS External events are used when you want Opus to stop operating and return control to your batch file. You can specify external events as being Forced or Informal or you just create an external event without declaring it to be either Forced or Informal. In that case the event will affect users who log on before the start of the event, but Opus will make no effort to execute the event if it was skipped for some reason and is now over. THE OPUS EVENT SYSTEM Page 75 There are two inter-relationships between External events and Matrix Behaviour Windows (Z events) that should be pointed out: * There is a field called an "errorlevel offset" in the Matrix Behaviour Window. This offset will be ADDED to the errorlevel from any exit during that behaviour window. * The "Exits suppressed" flag in Matrix Behaviour Windows, does NOT affect External Events. It only affects matrix exits such as "Exit after Arcmail" and "Exit after Matrix". It is used to prevent your system from performing a matrix exit after a mail session (eg you may wish to process all incoming mail once only after the end of the zone mail hour so that your system is available for incoming mail for the whole hour). Generally it is better to make all external events last 0 minutes and either Forced or Informal so that Opus will release control to the batch file for the minimum amount of time necessary to perform the specified task or whatever. If you give the event some length, and it is completed before that time is up, Opus will exit again with the same errorlevel to the batch file over and over until the time period specified for the external event has passed. 4.3 USER EVENTS User Events are more accurately described as User Behaviour Windows. They allow you a great deal of flexibility in how Opus will treat human callers during the time window in which they are enabled. There are two active fields in a user behaviour window: the Download multiplier and the Time multiplier. These fields only affect callers who have a privilege level below ASSISTANT SYSOP. SYSOP and ASSISTANT SYSOP are not affected by these behaviour windows. A value of "20" is considered to be neutral, users will get exactly what you have specified in your Opus control file. A value of "10" in the Time Multiplier would give users 1/2 the amount of time specified in the PRM file. A value of 50 in the Download Multiplier would give users two-and-a-half times as many kilobytes of download access during the specified time window. Page 76 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL If you have set your Opus control file so that it reports something like this: DEFINE Normal Cume 120 DEFINE Normal Time 60 DEFINE Normal File Limit 500 and you have a user behaviour window with a Download Multiplier of 30 and a Time Multiplier of 40, a NORMAL user would get: DEFINE Normal Cume 120 * 40/20 = 240 DEFINE Normal Time 60 * 40/20 = 120 DEFINE Normal File Limit 500 * 30/20 = 750 If you had a user event with a Download Multiplier of 0 and a Time Multiplier of 10, a NORMAL user would get: DEFINE Normal Cume 120 * 10/20 = 60 DEFINE Normal Time 60 * 10/20 = 30 DEFINE Normal File Limit 500* 0/20 = 0 4.4 MAILER EVENTS A mailer event lets you decide when you want to use the internal Opus mailer or an external mailer as a "front-end" to your Opus system. The external mailer command line is specified in the Opus control file. Whether you want to use the Opus internal mailer or the external mailer as your default mailer may also be set in the Opus control file. You can then use the mailer event to override the default setting in your Opus control file. If an external mailer is chosen, Opus loads and initializes itself, and then loads the external mailer. When a call comes in the mailer answers the phone. If it is another FidoNet system sending mail, the mailer handles everything. If it is a human calling in, the mailer is dropped out of memory and Opus takes over. Since Opus is already in memory and initialized this method is a LOT faster than the way other software deals with external mailers. However, it is memory intensive. 4.5 MATRIX EVENTS Matrix events are more accurately described as Matrix behaviour windows. They are primarily used to control the way outbound calls are made. Should any calls be made? Should they be local or long distance calls? How do you define a "local" call? How often should calls be made? All matrix behaviour windows are considered to be informal except for those in which the behaviour window does not allow human callers. THE OPUS EVENT SYSTEM Page 77 4.5.1 MATRIX EVENT FLAGS Matrix events have 7 possible flags. You do not have to set any of them if you do not wish to use their functionality. The Matrix event flags and their meanings are listed below: Mail Allow outbound calls to placed during this window. Local-Only Only make calls that are equal to or below the cost of the local cost field. No-Local Only make calls that are above the value stored in the local cost field. Continuous-Mail Only call those systems in the nodelist that are marked as being able to handle continuous incoming mail. (CM in FidoNet.) Suppress-Exits Do not allow matrix exits for packing, unpacking or otherwise processing incoming mail. Mail-Only Do not allow human callers online. Just handle mail. Requests Allow file requests to be honoured. (Usually disabled during the zone mail hour.) NO-Out-Reqs Do NOT allow Opus to make outbound requests. This only works with oMMM V1.70 and OMAIL V0.41 and above by creating special names for the file that forces Opus to make calls. Do NOT send outbound requests during Zone Mail Hour. 4.5.2 MATRIX EVENT FIELDS Matrix events have 5 possible numeric fields. You do not have to set any of them if you do not wish to use their functionality. The Matrix event fields are set out below: Local Cost Range: 0-255 Set the value that will be considered to be a "local" phone call during this event. If you have the Local- Only flag set, then only calls to those boards listed in your NODELIST.DAT file that are at or below the value stored in Local Cost will be made. If you have the No-Local flag set, then only calls to those boards that have costs ABOVE this value will be made. Page 78 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL Error Offset Range: 0-255 A value that will be added to any exits made during this event. One use would be to pack mail with different routing verbs at different times of the day. You might want to pack all local mail as HOLD during Zone Mail Hour to keep your board free during ZMH. Call-Frequency Range: 5-40 (5 is more frequent, 40 is less frequent) Controls how often Opus will check the outbound mail directory (ie tickle the hard disk unless you are running a disk cache) looking for mail to be sent. Opus will not find something every time, but it will reinitialize the modem each time. The default value is 14. With this setting Opus will place an outbound call roughly every 90 seconds. With a setting of 5, Opus will try to make a call roughly every 10 seconds, with a value of 40, it will be roughly 12 minutes between calls. Request limit Range: 0-255 Controls the number of minutes that Opus will allow another system to file request from your system. Opus will check AFTER each requested file is sent to see if the specified number of minutes has expired. If it has, Opus will hang up. Otherwise, Opus will proceed to send the next requested file, even if the time it takes to send that file will exceed the total number of minutes specified in the request limit. The word "roughly" came up in that paragraph a lot. The reason is that the time between calls has a random factor of +/-25%. So if you have the default frequency set, the average time between calls will be 90 seconds, but it might be as low as 45 seconds or as high as 105 seconds. With a value of 40, the time between calls might be as low as 8 minutes and as long as 16 minutes. The formula for creating the time to the next outbound call is: time = (45 + (rand() % 31)) * call-frequency * call-frequency ------------------------------------------------------ 14 * 14 THE OPUS EVENT SYSTEM Page 79 4.6 YELL EVENTS Yell events are used to determine when the sysop wishes to allow callers to page the sysop for an online chat. If no yell events are specified, then users will be told that yell is disabled whenever they choose the Y)ell menu command. If a yell event exists, and a caller pages the sysop between the starting and ending time defined by the yell event, Opus will cause the speaker on the sysop's computer to beep. The length of this beeping can be controlled by using the "errorlevel" field to set the number of seconds for which the speaker is to beep. 4.7 SCAN ALL EVENTS Scan all events cause Opus to scan all echomail message areas, except inbound-only areas, for new echomail messages to be scanned out. This only works if Opus is handling echomail processing internally. 4.8 HOUSE-CLEANING EVENTS House-cleaning events are used to clean out the .$$n files in the Opus outbound mail holding directory (or directories if you are using zoned outbound directories. These flag files are incremented from .$$1 to .$$5 to prevent Opus from wasting its time and your money making unsuccessful calls to systems which CONNECT but do not successfully complete a mail transfer for whatever reason. If .$$5 flag files are not deleted, Opus would not make calls to those systems again. It is therefore a good idea to run a house-cleaning event at least once a day, especially if your system is a major mail mover. Page 80 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 4.9 OVERLAPPING BEHAVIOUR WINDOWS The end of a behaviour window is considered to be as important as the start of an event, so Opus also tracks the end of an active event. Two events of the same kind can overlap. If you have two windows that overlap, Event 1 starts at 1:00 and ends at 5:00, Event 2 starts at 2:00 and ends at 3:00 like this: ÚÄÄ Z event 2 ÄÄ¿ ³ ³ 1:00 2:00 3:00 4:00 5:00 ³ (A) (B) (C) ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄ Z event 1 ÄÄÄÄÄÄÄÄÄÄÙ A) Next event at 2:00, Event 1 is active. B) Next event at 4:00, Event 2 is active. C) Next event at 5:00, Event 1 is active. 4.10 ADVANCED EVENTS FOR TIME TRAVELLERS One neat trick that Opus will allow you to use is that events can begin and end in different time zones. This can be a lot of help when you are trying to handle mail routing through your lowest cost carrier and dealing with FidoNet's Zone Mail Hour. For example, Sysop-X (Guido?) has a Matrix Event that starts at midnight local time (0:00 hours) and ends at 9:00 UTC (the start of FidoNet's Zone Mail Hour in Zone 1). The next Matrix Event runs from 9:00 UTC to 10:00 UTC (Zone Mail Hour in Zone 1) and then another event takes over at 10:00 UTC and ends at 6:40 local time. Why go through all that? Simple, when Daylight Savings time ends all Sysop-X has to do is reset the time on the computer and the TZ environment variable. The events will automatically swing around and adjust themselves to either Daylight or Standard time accordingly. THE OPUS EVENT SYSTEM Page 81 This is what Sysop-X's schedule looks like: Tag Day Start End Run Exit Mail LO NL CM SX MO RQ FR 000 Z SMTWTFS 0:00 L 9:00 U ENA Y N N Y N N Y 10 001 X SMTWTFS 8:59 U 8:59 U ENA F 030 002 H SMTWtFS 9:00 U 9:00 U ENA Clean Holding Area 003 Z SMTWTFS 9:00 U 10:00 U ENA 050 Y N 11 N N Y Y 20 004 U SMTWTFS 10:00 U 6:00 L ENA User event, DL = 50 Time = 40 005 Z SMTWTFS 10:00 U 6:40 L ENA Y N N Y N N Y 10 006 X SMTWTFS 10:00 U 10:00 U ENA F 050 007 S SMTWTFS 5:45 L 5:45 L ENA Scan All Echo Areas 008 X SMTWTFS 5:46 L 5:46 L ENA I 060 009 U SMTWTFS 6:00 L 8:00 L ENA User event, DL = 20 Time = 20 010 X SMTWTFS 6:40 L 6:40 L ENA I 059 011 Z sMTWTFs 6:40 L 18:00 L ENA Y Y N Y N N Y 30 012 Z Smtwtfs 6:40 L 17:00 L ENA Y 45 N Y N N Y 30 013 Z smtwtfS 6:40 L 23:00 L ENA Y 40 N Y N N Y 24 014 U Smtwtfs 8:00 L 18:00 L ENA User event, DL = 30 Time = 30 015 U sMTWTFs 8:00 L 15:30 L ENA User event, DL = 60 Time = 40 016 U smtwtfS 8:00 L 22:30 L ENA User event, DL = 30 Time = 30 017 Y SMTWTFS 10:00 L 21:00 L ENA Yell Event 018 U sMTWTFs 15:30 L 22:30 L ENA User event, DL = 20 Time = 20 019 Z Smtwtfs 17:00 L 22:00 L ENA Y 10 N Y N N Y 32 020 U Smtwtfs 18:00 L 22:30 L ENA User event, DL = 15 Time = 15 021 Z sMTWTFs 18:00 L 22:00 L ENA Y 10 N Y N N Y 24 022 X SmtwtfS 21:00 L 21:00 L ENA I 055 023 Z SMTWTFs 22:00 L 23:00 L ENA Y 20 N Y N N Y 24 024 U SMTWTFS 22:30 L 9:00 U ENA User event, DL = 30 Time = 30 025 Z SMTWTFS 23:00 L 0:00 L ENA Y 40 N Y N N Y 12 000 Make calls Anywhere until ZMH 001 External event to pack logs before ZMH 002 Clean out all *.$$? flags in Outbound dir. 003 Zone Mail Hour, No humans, do not call the local boards 004 Users get 2+ times download/time 005 End of Zone Mail hour, early morning Mail status 006 End of Zone Mail hour, Renumber message areas 007 This is the Scan All event 008 Do morning Polls 009 Users get "normal" time/download 010 Morning external, unpack MegaList, run POLE_MQ 011 Weekday Mail status, no long distance calls. 012 Sunday morning/afternoon Mail status 013 Saturday Mail status 014 Users get extended time/dl on weekends 015 Users Weekday get extended time/download during business hours 016 Users get extended time/dl on weekends 017 Daily Yell event 018 Users get limited time/dl during "prime time" 019 Sunday 5:00 p.m. Mail. Reach Out America off 020 Users get limited time/dl during "prime time" 021 Early evening mail status, Use PC Pursuit 022 Evening Poll set up. 023 Reach Out America starts. Call in US, but outside of California Page 82 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 024 Users get 50% extra 10:30 p.m. to ZMH 025 Make calls inside California, but no non-USA calls 4.11 HOW TO SET UP EVENTS To set up events in Opus V1.70, the program to use is Doug Boone's OEVENT.EXE Version 0.81. It was used to generate the event listings in section 4.10 above. For further details on the operation of OEVENT, please refer to the documentation that comes with OEVENT. WHEN THE SYSOP IS AT THE KEYBOARD Page 83 +--------------------------------------------+ | "He's crazy!" | | "Yeah, but he has all the machine guns." | | | | -- Miami Vice | +--------------------------------------------+ 5.0 WHEN THE SYSOP IS AT THE KEYBOARD Opus has four basic modes: * When the system is waiting for a call or an event; * Sysop "calling" the system from the keyboard; * When a caller is on-line; and * Chat mode. The following sections describe the use of the local keyboard in each of these modes. 5.1 WHEN OPUS IS WAITING FOR A CALL When Opus is sitting at the "Ready" prompt waiting for your next lucky caller, or the next scheduled event or matrix behaviour window, you may: * Hold down CONTROL and press C Hold down ALT and press Q This quits Opus and returns you to DOS. * Press ESCape This allows you to enter a DOS command. When the DOS command completes, you will be returned to Opus. Opus does not busy out the phone line during the lifetime of the DOS command. * Press F1 - F10 function keys This runs the batch file associated with the function key (see below for setting up these batch files). Page 84 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL * Press Y This overrides the scheduled Yell event and forces Yell ON; * Press U This overrides the scheduled Yell event and forces Yell OFF; * Press T This forces Opus to follow the scheduled Yell event; * Press the CURSOR UP key This increases the delay between outbound mail calls by Opus. The bigger the number, the longer the delay is between calls, the smaller number, the more often Opus will make calls. It is a manual way to override the outbound call frequency you set in the event file (see Opus Event System section of this manual). With a setting of 5 Opus tries to make an outbound call every 10 seconds and with a setting of 40, Opus tries to make an outbound call every 10 to 15 minutes. * Press the CURSOR DOWN key This decreases the delay between outbound mail calls by Opus. The bigger the number, the longer the delay is between calls, the smaller number, the more often Opus will make calls. It is a manual way to override the outbound call frequency you set in the event file (see Opus Event System section of this manual). With a setting of 5 Opus tries to make an outbound call every 10 seconds and with a setting of 40, Opus tries to make an outbound call every 10 to 15 minutes. WHEN THE SYSOP IS AT THE KEYBOARD Page 85 * Press M to select the Matrix Menu This option displays the current matrix behaviour window setting and gives you the option of checking the status of outbound mail (Information), polling another matrix system (Poll), unpacking any inbound mail bundles (Unpack), scan all your EchoMail message areas (Scan), clear the ########.$$n files from your outbound directory or directories (Clear undialables) or return to Opus (Quit). While you are in the Matrix Menu, Opus will busy out the phone line using the method specified in the control file (refer to the BUSY option in section 2 of the Technical Reference Manual). * Press C This forces Opus to make an outbound call now provided you have some outbound mail to deliver, the current matrix behaviour window and local call cost settings allow outbound calls at this time etc. You may have to press C several times to attract the attention of Opus. This is normal behaviour. * Press K This lets you log on to your system in "keyboard mode". (This is sometimes called "testmode" by a certain LCD.) See further the keyboard mode section below. 5.1.1 SETTING UP F1-F10 BATCH FILES To run a batch file associated with one of the function keys F1 through F10, batch files with the names F1.BAT through F10.BAT must exist in the Opus miscellaneous directory (ie the directory defined in your control file with the PATH MISC option). F1 usually means help, right? (I hope you pass this impromptu test or Guido will ...) Right. My F1.BAT file contains the following, which is very useful for those of us whose memories are in recess: Page 86 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL @echo off cls echo echo echo Function Key Batch Files echo echo F 1 - This help summary echo F 2 - Run User File Manager echo F 3 - List Opus.log echo F 4 - List disk cache stats echo F 5 - Drop to DOS, busy line out echo F 6 - Run Event Manager echo F 7 - Run Opus-Fam echo F 8 - echo F 9 - echo F10 - echo A "skeleton" or "generic" batch file which may be used to implement the other function key batch files is set ut below with comments (do not enter the comments if you decide to use it!): @echo off ;avoid screen clutter DOS 3.3+ at com%PORT%: h1 ;busy out the phone line ;insert your program etc here at com%PORT%: h0 ;hangup the modem goto end ;just to be safe :END ; " " " " c: ; " " " " cd \opus ; " " " " * AT is a small program which sends AT commands to your modem; if you do not have this program (stocked by most BBS file areas) you may be able to use: ECHO ATH1 > COM1: and ECHO ATH0 > COM1: * %PORT% is a DOS environment variable containing the communications port which is used by Opus on the system invoking the batch file (very handy if you are running a multi-line system). You can set it by placing SET PORT=1 (for com1:) in your NERF.BAT batch file; alternatively you can simply hardcode the entry in the function batch file like so: AT COM1: H0 and AT COM1: H1 * inserting COMMAND here will let you drop to DOS and busy out the phone line. WHEN THE SYSOP IS AT THE KEYBOARD Page 87 5.2 SYSOP CALLING FROM KEYBOARD When Opus is sitting at the "Ready" prompt waiting for a call or the next scheduled event, the sysop can log on to the system by pressing K. Opus will ask you to confirm it is you, will ask for your password etc and then log you on to the system. The keyboard works just like it would if you were calling in using a modem. There is only one primary difference. When Opus asks for your name, you can quickly get back to DOS by just pressing ENTER. You can also terminate Opus and get back to DOS by typing ALT-X from anywhere inside Opus (this also works remotely, Opus will log you off without asking you any questions at all, if you are using Avatar emulation to transfer ALT keys over the modem line -- see further below). A few things are different. If you find that Opus is not listening to your every keystroke when you try to abort searches and listings, and you have VIDEO IBM set in the Equipment Section of the control file, change it to VIDEO DOS and Opus may just pay more attention to your pounding on the keyboard. Also note that if you have IBM VIDEO set, any Avatar or ANSI graphics commands will be written straight to the screen ... not a very pretty sight unless you have honed your skill to translate these commands on the fly. In keyboard mode OpEd, the Opus full-screen editor, accepts additional keyboard commands as follows: ALT-R Open a quotation window ALT-Q Copy four lines of quotation into reply ALT-X Abort message ALT-W Save message + Copy four lines of quotation into reply TAB (Insert 8 spaces (insert mode) (Overwrite 8 characters (overwrite mode) PgUp Scroll message up PgDn Scroll message down CUP Cursor up CUD Cursor down CUL Cursor left CUR Cursor right HOME Move cursor to beginning of line END Move cursor to end of line INS Turn insert mode on DEL Delete character under cursor F1 Help screen F10 Editor Menu If you call your system remotely and have Avatar emulation turned on, Page 88 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL and are using a proper Avatar terminal emulator (such as TinyTerm or FrontDoor), you can transfer those keys over the phone line and use them in OpEd (to use OpEd you need at least an 80x25 screen AND screen clear turned on). To allow this transfer, press ScrollLock in FrontDoor, or Shift-F1 in TinyTerm, which will tell these programs to transfer any function keys remotely. The same key that turns this feature on in these two terminal programs turns it off. 5.3 WHEN A CALLER IS ONLINE When a caller is online, there are two different keyboard modes available: (1) the sysop can type commands as if the caller had typed them, and (2) the sysop can obtain information about the caller and change some of it while the caller is still online -- Opus will remember any changes made for next time the caller logs on. The full list of keyboard commands available while a caller is online are set out below: Add 1 minute to the caller's time Subtract 1 minute from the caller's time. C Go into chat mode (see below). CONTROL-X Ignominiously hang up on the caller! A (or CONTROL-A) Turn on the local keyboard. Opus will take commands from your keyboard or from the modem, but your keyboard had priority. Turn off the local keyboard. - ("minus") Lower the privilege level of the caller by one notch. Starting with Opus V1.70, this also changes the caller's time and download allowances to reflect those associated with the new privilege level for this call. + ("plus") Raise the caller's privilege level by one notch. Starting with Opus V1.70, this also changes the caller's time and download allowances to reflect those associated with the new privilege level for this call. O (or CONTROL-O) Turn off SNOOP. Only status-type messages appear on your monitor when the SNOOP is turned off. WHEN THE SYSOP IS AT THE KEYBOARD Page 89 N (or CONTROL-N) Turn on SNOOP mode. Your monitor will show everything that the caller's monitor shows. Z Zero the cumulative daily time for the caller. This has NO EFFECT on the time for the current call ... only the total time spent online for the day. Use and to change the caller's time limit for the call that is in progress. ? Show a detailed chart of information about the caller (eg keys, user macros, number of calls, time online today, file up/down loads etc, whether chat was requested). K Display the caller's keys. You can then toggle keys on or off by pressing those keys that you want to toggle on or off. This will cause the keys to redisplay. The caller's current keys are shown in upper case, the other keys are shown in lower case. Press ENTER to finish toggling the keys. Y Override the scheduled Yell event and force Yell ON; U Override the scheduled Yell event and force Yell OFF; T Force Opus to follow the scheduled Yell event; F1 Send F1.BBS or F1.GBS F2 Send F2.BBS or F2.GBS F3 Send F3.BBS or F3.GBS F4 Send F4.BBS or F4.GBS F5 Send F5.BBS or F5.GBS F6 Send F6.BBS or F6.GBS F7 Send F7.BBS or F7.GBS F8 Send F8.BBS or F8.GBS F9 Send F9.BBS or F9.GBS F10 Send F10.BBS or F10.GBS Page 90 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL The NIEL KEYS are sometimes called "function keys" by those who do not live in Dallas. Ask any grizzled Dallas Opus veteran why! The Niel Keys are a set of keys that work like photon torpedoes. You can send any one of ten OEC (BBS/GBS) files to the caller at the press of a button ... which means they can have ANSI graphics and OECs to do everything from greet the caller with the caller's own name, send a quote of the day, or even hang up on the caller (or all of the above). The F1.BBS / F1.GBS) files must be located in the Opus miscellaneous directory which is defined in the control file with the PATH MISC option. If you press any other key ... you will be shown a short status screen and a brief menu of some of these commands. 5.4 CHAT MODE Starting with Opus V1.10, chat mode is only available if you have loaded George Stanislav's "chat fossil" (a small Terminate and Stay Resident program) or you are using one of the several external chat programs which are available (eg William Beebe's OPHONE) via an external menu command. The chat fossil should be loaded from the NERF.BAT batch file which you use to start Opus. Load it just after the point that you load your fossil. If you run DESQview and load your fossil outside of DESQview, then load the chat module outside also. To chat with a caller is who online, simply press C. To end chat mode, use ALT-Q. 5.4.1 CONFIGURING THE CHAT FOSSIL You can configure CHAT.COM to slow down between the individual beeps. CHAT uses a very simple method of waiting between the beeps: it loops so many times. The default it uses is a 4.77 MHz PC. On any faster computer this is not the way to go! To slow it down, simply place a number on the command line. EXAMPLE, on a 386SX-16 computer: chat 30 This tells CHAT to repeat the loop 30 times. Play with the value till you find one that suits your particular system. THE MATRIX Page 91 +--------------------------------------------+ | Arrogance is the mother of invention. | | | | -- Guido Palermo | | Opus Bylaws and Covert Action Committee | | | | Actually, Guido just claims this | | quotation. When I checked, the | | quotation's serial number had been | | filed off ... so it's impossible | | to tell for sure. | +--------------------------------------------+ 6.0 THE MATRIX This is a general explanation of the procedures involved in setting up your system to send messages from your system to other systems in the Matrix. It assumes that you have followed the procedures outlined in the section in this manual entitled "Setting Up Opus V1.70" -- if you have not followed those procedures exactly, this section may not be of much help to you. Skip this section if you do not want to run netmail ... there is no rule that says you have to run netmail. Uhuh, I thought you might ... read on then. 6.1 NETMAIL FOR THE COMPLETE NOVICE This section is dedicated to the sysop who has no previous experience with netmail. If you follow the step-by-step instructions, you will quickly set up simple node-to-node netmail. This does not cover netmail comprehensively, but it will get you up and running without a lot of frustration. Advanced netmail topics will be covered in other sections of the manual. EchoMail is also dealt with in its own section of this manual. The novice's introduction to the Matrix can be overwhelming, especially with all the jargon and programs that abound: Page 92 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL +-----------------------------------------------------+ | ECHOMAIL PACKETS HIGHWATER MARKS | | | | DUPES NETWORK TOSSING NODES | | | | ROUTE PARSELIST BADWAZOO | | | | NODELIST SEEN-BY PATH ZMH | | | | NET REGION BUNDLES ARCS | | | | INBOUND HOST HUB SCANNING TOSSING | +-----------------------------------------------------+ No wonder it is confusing! Unfortunately, no single source of documentation or information covers it all. 6.2 FILES REQUIRED FOR NETMAIL If you check out an active Opus-CBCS, you will undoubtedly see many programs for doing all kinds of wonderful and interesting things. However, we are trying to save time and get you going. So here is a list of only the essentials that you will need: oMMM originally by Wynn Wagner III oMMM stands for the Opus Matrix Message Masher. This program is used to bundle messages for sending to other systems in the Matrix. You can use other similar programs which bundle messages, but oMMM was specifically written to support Opus and has some Opus-specific widgets that may not be found in other similar programs. NODELIST This is your "phone directory" of other systems in the Matrix. It contains information about each system's name, location, sysop, maximum baud rate and special information on operating times and types of mail that can be processed. The nodelist will be in a file named something like NODELIST.107 (the 107 means it was published on the 107th day of the year). The file is usually found compressed inside an archive that will have a file extension something like .A07 (ie the first digit of the raw nodelist's filename extension becomes an A to indicate that file is ARChived); such a file will need to be uncompressed before it can be used. THE MATRIX Page 93 The nodelist is published weekly by the FidoNet International Coordinator and available from most FidoNet bulletin board systems. Ask your local, friendly, FidoNet sysop if you cannot find it. In fact, it may pay to make friends with a local sysop because the file is currently over half-a-megabyte in size when archived, and just under one megabyte when unarchived. Downloading the nodelist at 2400 bps is not exactly high on the fun scale. OPARSE by Doug Boone =or= PARSELST by Bob Hartman This program is used to "compile" or "translate" the raw NODELIST data into a form usable by Opus. For example, the program will strip the area codes from local phone numbers. The program can also process a per-message "cost" item. This is the amount you would charge your users for sending a message, should you decide to give them access to the Matrix message area. Opus will use the "cost" information to decide whether a call to a remote system is local or long-distance. OPARSE will generate the advanced Opus V1.70 Version 7 nodelist files; PARSELST will generate the "old" Version 6 nodelist files used by Opus 1.1x and some other mailer programs. ARCA.COM by Vernon D. Buerg Used to create compressed mail bundles. DO NOT SUBSTITUTE ANY FILE COMPRESSION PROGRAM THAT CREATES COMPRESSED FILES DIFFERENTLY FROM ARCA without the prior approval of all of the other systems to which you intend sending mail bundles. ARCA is the lowest common denominator in file compression which is supported by every Matrix system. Other file compressors may not be supported by Matrix systems. ARCE.COM by Vernon D. Buerg Used to uncompress mail bundles from other systems which have been compressed with ARCA or another compatible file compressor. OEVENT.EXE by Doug Boone The Opus Event Manager which you use to setup events, or often more accurately described as behaviour windows, which affect how Opus will operate. Page 94 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 6.3 AN OVERVIEW OF NETMAIL Most novices are quickly confused by the complexities of netmail, but would appreciate a simple overview. The following flowcharts show what happens to incoming and outgoing mail bundles and which programs operate on them. Note that once your nodelist is compiled, only four programs are required to handle all forms of node-to-node mail: OPUS, ARCA, ARCE, and oMMM. Figure 6.3-1 The incoming mail bundle ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ ³ ³ ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º OPUS (Matrix session) º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ ³ ³ ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍ» º Is mail bundle compressed? º ÈÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍͼ ³ ³ Yes No ³ ³ ÉÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍ» ³ º ARCE º ³ º (decompressor) º ³ ÈÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍͼ ³ ³ ³ ³ ³ ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍ» º OPUS º º (inbuilt message unpacker) º º º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ ³ ³ ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º [Matrix Message Area] º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ THE MATRIX Page 95 Figure 6.3-1 The outgoing mail bundle ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º [Matrix Message Area] º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ ³ ³ ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º oMMM º º (creates message bundles from individual messages) º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ ³ ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º Is mail bundle to be compressed? º ÈÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍͼ ³ ³ Yes No ³ ³ ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ³ º ARCA º ³ º (compressor called by oMMM) º ³ ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍͼ ³ ³ ³ ÉÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍ» º º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ ³ ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º OPUS (Matrix session) º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ ³ ³ ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º Outgoing mail bundle º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ 6.4 QUICK START TO NETMAIL This section will list each step required to get node-to-node netmail working. It is a "cookbook". Rather than attempt to explain it all here, some assumptions are going to be made to keep it simple. You may wish to change things later. To get your system up and running quickly, the following assumptions have been made: * your system has at least 256k memory available to run Opus; and * your Opus system directory is C:\OPUS. If it is not, you will need to substitute your own directory pathname in the following instructions. Page 96 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL (1) Place the following programs and files in your Opus system directory (usually C:\OPUS where OPUS.EXE resides): OPUS.EXE ARCA.COM BBS.CTL ARCE.COM oMMM.EXE NACL.EXE oMMM.CFG NACL.HLP OEVENT.EXE NACL.MSG OPARSE.EXE =or= PARSELST.EXE The Latest NODELIST.??? file (2) Edit the PARSELST or OPARSE control file (PARSELST.CFG or OPARSE.LST) to represent your phone costs and local area code (see the documentation included with the PARSELST or OPARSE program). In the PARSELST.CFG file make sure you set the following options for Opus V1.70: ; Stuff everyone should have: Node 3:711/401 ; Your network address Country 61 ; Your country phone code MaxBaud 9600 ; Your highest baud rate ; For Opus V1.70 use the following: Complete ; Generate entire nodelist UseZone ; Do not change Zone to Region Version6 ; Generate Version 6 format files (3) Compile the nodelist by running OPARSE or PARSELST. (4) Create the following directories: C:\MSG\NET\ (where the individual messages are stored) C:\FILE\NET\ (where inbound files are stored) C:\OPUS\OUTBOUND\ (where outgoing message bundles are stored) NOTE: if you are going to be sending netmail directly to different Zones (ie, not routing it via the zonegate systems), you need to also create a C:\OPUS\OUTBOUND.ZZZ directory for each Zone to which you will be sending mail. The .ZZZ is the HEXADECIMAL number of the Zone, so Zone 3 is 3, but Zone 16 is 10. IMPORTANT: If you do create additional "zoned" outbound directories, make sure that they appear in your directory IN ORDER or else you will experience some grief to put it mildly (just ask Paul "I've broken it, Doug" Kelly). Watch out for disk defragmenters which order directory entries alphabetically! THE MATRIX Page 97 (5) There are several options in your Opus Control File which must be set in order to handle netmail. These options appear in two sections of the control file, "Equipment Section" and "Matrix and EchoMail Section". Since this section is devoted to the novice, all non-essential advanced options will be skipped. For full details of these control file options, refer to section 2 of the Opus Technical Reference Manual. Edit your Opus control file (named BBS.CTL) as follows: The Equipment Section OUTPUT COM1: % If your modem is attached to COM2: % substitute that for COM1: here. BAUD MAXIMUM 2400 % If your modem goes faster, substitute its % top speed here (typically 19200 or 38400 for % high speed modems). INIT ATZ| % The character string for Opus to send to % your modem to initialise it. % You should place any commands required to % setup your modem in the batch file which % runs Opus and store them in your modem's % non-volatile memory using the AT&W command. % If your modem does not have non-volatile % memory (ie it does not remember settings % when you turn the power off) you will need % to put your full initialisation string here. DIAL PREFIX ATDT % The character string for Opus to send to % your modem before the phone number to cause % it to dial out. % If your phone only supports pulse dialing % substitute ATDP for ATDT. % This is where you could add any special % characters required for ALL outbound phone % calls. For example, "ATDT0,," to go through % a PABX and obtain an outside line. DIAL SUFFIX | % The character for Opus to send after the % phone number. Usually just a carriage % return, represented by the "|" character. MASK CARRIER 128 % Refer to the Opus Technical Reference Manual % if you must know what this means. MASK HANDHSHAKING CTS % May be required for high speed modems or % modems that can accept data faster than % they send it PROVIDED you have setup % your modem to use "hardware flow % control". Page 98 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL SEND BREAK TO CLEAR BUFFER % Comment this line out by placing the % percent (ie "%") character in front % of the line UNLESS you have an HST % modem and have set its registers up % using the &Y0 command. SLOW MODEM % If you have a FAST computer (286 or better), % uncomment this line to make Opus put a tiny % delay between characters which it sends to % the modem EVEN if you have a FAST modem. The Matrix and EchoMail Section ADDRESS -1:-1/-1.0 % This is essential for sending/receiving % netmail. You are normally assigned a number % by a coordinator for your region or net. % Information on coordinator locations is % located in the nodelist. Before you are % assigned an official number, you should use % -1:-1/-1.0 as your address. Other local % sysops can temporarily patch your phone % number into their nodelists until you have % an "official" address. PATH NETINFO C:\OPUS\ % Tell Opus where to find your nodelist % files. USES VERSION 6 % If you are using OPARSE, comment out this % line if it exists by placing a percent sign % (ie %) character in front of it. PATH OUTBOUND HOLD AREA C:\OPUS\OUTBOUND\ % Tell Opus where to % store outgoing mail % bundles. This % directory can be % anywhere you want, % but the one shown is % recommended. Some % programs will use % this directory as the % default outbound. PATH INBOUND MESSAGES C:\MSG\NET\ % Tell Opus where to store % incoming messages. The % directory can be anywhere % you want, but it should be % the message area you % declared as being Matrix. PATH INBOUND FILES C:\FILE\NET\ % Tell Opus where to store files % that are sent to you by other % systems. THE MATRIX Page 99 SEND LOCAL % Opus will only send mail to % "local" cost nodes UNLESS you % override this behaviour. AFTER ARCMAIL EXTRACT PACKETS % Tell Opus to extract messages % from incoming compressed mail % files MESSAGE EDIT ASK CRASH SYSOP % Tells Opus to ask you about MESSAGE EDIT ASK FILEATTACH SYSOP % which message attributes MESSAGE EDIT ASK UPDATE SYSOP % you wish matrix messages MESSAGE EDIT ASK KILLSENT SYSOP % you create to have. Create a matrix message area definition in the Opus control file. It should reference the directory C:\MSG\NET\ and the message type should be "Matrix". Here is a sample Matrix message area definition with just the bare essentials: AREA 0005 MATRIX % Area number and name MATRIX % Matrix type message area ACCESS PRIV Disgrace % Access for access to the area EDIT PRIV Sysop % Access for E)nter & R)eply PATH C:\MSG\NET\ % Path to your matrix message area TITLE Netmail % Title for this message area END AREA % End of message area definition (6) Use NACL to compile your now modified BBS.CTL control file. NACL will produce a file called BBS.PRM which is the compiled version of the Opus control file. To compile your control file type the following line and press ENTER: NACL /L /V /I BBS > REPORT If there are any problems with the compilation of your BBS.CTL file, error messages listing the line numbers of the problem lines may be found in the file REPORT which is created using the above NACL command line. Use the error messages to track down the problem(s) and fix them; then recompile. (7) Make sure you have loaded your FOSSIL program by running the program (eg OPUSCOM1.COM, OPUSCOMM.COM or X00.COM) =or= by installing your FOSSIL device driver by putting a "device=" line in your CONFIG.SYS file in the root directory (c:\) of your boot drive and rebooting (eg DEVICE=C:\X00.SYS). (8) Run Opus by typing OPUS BBS and pressing ENTER. Page 100 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL (9) If you created the default event schedule with OEVENT.EXE, Opus outbound netmail behaviour should default to the settings in your control file. To confirm this is true, go to the Matrix menu (press "M" at the ready prompt while Opus is waiting for a call). Select the I)nformation option. At the top of the screen it should say: "Matrix Behavior: LOCAL" (10) Test the integrity of your setup by selecting the M)atrix menu (press M while Opus is sitting at the ready prompt) and then choose the P)oll option from the menu to call a known node in your local area. This part is really satisfying if everything works correctly. If it does not work, pay attention to any error messages which might hint at the problem, and then recheck EVERYTHING. (11) Terminate Opus by pressing ALT-Q. Now edit the oMMM configuration file to reflect your system (refer to the documentation included with oMMM for further details of the options in this file). The following is an example of a very simple, working oMMM.CFG file: ============================================================= ; this is line one of the file oMMM.CFG ; path to your matrix message area MESSAGEPATH c:\msg\net ; path to your outbound message holding area ; only specify your primary outbound path HOLDPATH c:\opus\outbound ; Matrix address of system. ADDRESS 65535:65535/65535.0 ;equivalent to -1:-1/-1.0 ; Define the program for creating compressed mail packets. Define_Stuffer ARC arca ; this is the last line of the file oMMM.CFG ============================================================ Run oMMM (type oMMM and press ENTER) and see if it terminates with any error messages. If it does, it will usually tell you the line number of the line in the oMMM.CFG file where the problem occurred so that you can correct it. You can ignore its complaint that there is no route file; you do not need one for the moment (refer to the oMMM documentation for details of the route file if you are curious). THE MATRIX Page 101 (12) Log on from the keyboard (type K at the ready prompt while Opus is waiting for a call). Enter a message in your Matrix mail area to a sysop of a local node, preferably one running Opus that can accept mail at any time. Mark the message as "Crash" (Answer YES to the CRASH question). After logging off, terminate Opus with ALT-Q and then run oMMM. oMMM will move any messages you have created in your matrix message area to the outbound holding area. Look for a screen report that it is processing the message. (13) Re-run Opus (OPUS BBS). Select the M)atrix menu (press "M" when Opus is at the ready prompt waiting for a call) and choose I)nformation; it should show your message in the outbound area, waiting to be sent. After Q)uitting the M)atrix menu, Opus will wait a few minutes, then attempt to send the message. If you are anxious, you can select the C)all option from the keyboard. You may have to press C several times to get Opus to pay attention. This will make Opus peek in the outbound holding area and send the mail immediately, regardless of cost. You can try it again with a file attached. Just attach a file when entering a message in the Matrix message area. (14) Test your ability to receive and unpack mail by having a local sysop send mail and files to you. If everything is working correctly, you will see it come in. If Opus does not unpack it automatically, choose the M)atrix menu, select U)npack and the mail bundle will be unpacked and the message(s) placed in the Matrix message area for you. Log on from the keyboard and verify the message(s) made it there. (15) Create a batch file, NERF.BAT, to run Opus and automate the bundling of mail by oMMM. The following is a very bare bones example NERF.BAT batch file which will handle mail bundling automagically (the file consists of the lines between the two lines of "======", with each line starting in column 1): ================================== C: CD \OPUS :OPUS OPUS BBS :TEST IF ERRORLEVEL 16 GOTO BUNDLE IF ERRORLEVEL 1 GOTO OFFLINE :BUNDLE oMMM GOTO OPUS :OFFLINE ================================== Page 102 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 6.5 OPUS DEFAULT NETMAIL BEHAVIOUR Opus can be configured in many different ways to accommodate the many variables in netmail as well as your own preferences. Some of the variables in netmail are: * your own system configuration - see the BBS.CTL file and refer to section 2 of the Opus Technical Reference Manual; * cost of outgoing phone calls - refer to the documentation for your nodelist compiler program for setting call costs, and to the section 4 of this manual on the Opus Event System for setting the cost of what are to be regarded as "local" calls; * scheduling mail traffic to conform to local, national or international mail schedules (eg Zone mail hours) - refer to section of 4 this manual describing the Opus event system and to the oMMM documentation which describes routing; * the display of various attributes associated with a netmail message while reading messages in Opus - refer to the BBS.CTL file and to section 2 of the Opus Technical Reference Manual; * the ability to define various attributes of a netmail message. 6.5.1 BEHAVIOUR WINDOWS Doing outbound mail with Opus is fairly simple. In fact, getting that message across has been one of the toughest jobs. Idea #1: With Opus, "mail events" do not exist. Instead, there are matrix "behaviour windows." With an event, you have to give every detail ... making statements that are procedural in nature. With a behaviour window, you paint with a wide brush telling the system what to do with different classes of remote system. When systems could handle Matrix mail only during special times, routing and times were important. Now that most systems can process mail at any time, the idea of a schedule becomes less important. The item of prime importance in Opus is COST. We are going to try to relieve you of the tedious details of scheduling and concentrate on doing things for the least cost. More on this later. THE MATRIX Page 103 6.5.2 BUILDING MAIL BUNDLES Idea #2: A "bundle" is what some other systems call a "packet." In network operations, a packet has a special meaning ... a meaning that has nothing to do with network mail. An "XModem Block" is a packet in network terminology. To avoid confusion with an established word, Opus documentation use "bundle". With some programs, bundles are built every time a mail schedule starts. As a result, one message may be put into a bundle several times. With Opus, bundles are built once. As Opus has no internal bundler (the thing that maintains message bundles destined for some other system) you must use an external program called oMMM (Opus Matrix Message Masher). You can exit Opus with a preset DOS errorlevel to call the bundler program when the contents of the Matrix area changes (refer to the AFTER EDIT EXIT line in the Opus control file). 6.5.3 FILENAMES DRIVE OUTBOUND MAIL Idea #3: The driving force behind outbound message and file traffic is filenames! You will have special subdirectories set aside just for bundles and other Matrix files. These subdirectories belong to Opus and should not have anything else put in there. Opus will maintain these subdirectories for you. As soon as you run oMMM, messages that are marked KILL/SENT in your Matrix message area will disappear. They have not been sent, yet. They have just been bundled up and deposited in your outbound mail holding area, ready to go. Bundle filenames The filenames of the bundles tell Opus how to treat the different bundles. Here is a typical bundle name: 12345678.OUT That says the bundle is for 1234/5678. The numbers are in hexadecimal (base 16). The ".OUT" means it is a regular bundle and, if left with that extension, will be treated by Opus like a .DUT file (see below). Other bundle extensions include: .CUT ... send the bundle to the destination node NOW, regardless of cost; Page 104 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL .DUT ... send the mail direct to the other node without routing it via another system; if the destination node can accept CM (Continuous Mail, ie, mail at any time) send it now provided there is no Opus behaviour window overriding this directive (eg local call cost is observed - see further the section 4 of this manual on the Opus Event System); .HUT ... hold the bundle for pickup by the destination node; .CRT ... the same as CUT but with an attached file request; .DRT ... the same as DUT but with an attached file request; .HRT ... the same as HUT but with an attached file request; .ORT ... the same as OUT but with an attached file request. One nice thing is that you can manually change the filename's extension if you need to do so. That would change the behaviour of the bundle the next time Opus sees it. Only change it if you know what you are doing! The oMMM program knows about these extensions and creates them based on information you put into the oMMM route file. You will have statements like this: ONEHOLD 1:119/5 That would create a .HUT bundle file of messages addressed to 1:119/5 that are to be HELD for 1:119/5 to pickup when it calls. Flow file names Files are also sent through the Matrix. oMMM builds and maintains a file that tells Opus what files to send to destination systems and what files to hold for pickup by destination systems. A typical "file attach" file might be named: 12345678.FLO Other flow file extensions are: .HLO ... hold these files for pickup .CLO ... crash these files to the other system NOW, regardless of the cost! .DLO ... send these files if the destination is capable of receiving CM (Continuous Mail, ie, can accept mail at any time). THE MATRIX Page 105 A flow file is just a text file. It contains a list of files that are to be sent to another system, for example: #c:\opus\outbound\00096581.mo1 #e:\pascal\program.arc Now for a few details about what may be contained in flow files: * Filenames in a flow file never include wildcard characters such as *.* or ????????.ARC etc; * Filenames in a flow file should always be fully pathed with disk drive letter and full directory path from the root directory (eg c:\opus\outbound\00095681.mo1 and not just 00095681.mo1); * If the first character in front of the disk drive letter is a # (hash sign or American pound sign -- NOT an English pound sign!) , Opus will truncate the file (make it zero bytes in length) after it has been successfully sent to, or picked up by, the destination system; * If the first character in front of the disk drive letter is a ^, Opus will delete the file after it has been successfully sent to, or picked up by, the destination system; * If there is no character in front of the drive letter, the file will not be touched after it has been successfully sent to, or picked up by, the destination system. Compressed messages The oMMM program will compress messages for you using your favourite file compressor. Do not forget that the only method of compression that is supported by ALL nodes in FidoNet is the original ARC compression employed by ARCA (to create compressed files) and ARCE (to extract compressed files). Details on how this is done may be found in the documentation which comes with oMMM. oMMM creates archives using the same numbering convention as other message archive programs. The filename is the difference between the sender's net/node and the receiver's net/node. The file extension is ."MO#" where `#' is a number between 0 and 9. In this case, MO stands for "Monday". oMMM will also produce "TU", "WE", "TH", "FR", "SA" and "SU" files depending on the day of the week when the archive is created. 6.6 HOW IT ALL WORKS So far, we have covered bundles and flow files. We have also hit on some of the high points of oMMM. More detailed information on oMMM may be found in the documentation which comes with oMMM. Page 106 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL This is the flow of a message ... If I have written a message to Doug Boone, the message is in my Matrix message area and I have flagged it as KILL/SENT and CRASH (ie, I do not want to keep a copy, so th original in the Matrix message area directory will be deleted after it has been bundled and moved by oMMM to my outbound mail holding directory). See below for why I used CRASH. oMMM is run, and converts the message into a bundle in the outbound holding directory. In my route control file for oMMM, I have this: ONECM 1:119/5 1:119/All This route control file line tells oMMM to build a compressed message bundle using my favourite file compressor (whatever is specified in the oMMM.CFG file) to 1:119/5 and mark it CRASH. In the bundle will be any messages to Doug (119/5) as well as messages to anybody else in Net 119. The ONECM verb should only be used when you know the destination system can receive continuous mail (the nodelist entry for the destination node is marked CM) and you want to send the message NOW, regardless of the cost. Now there is one GOTCHA that must be mentioned. If you are in a different zone from the zone you are sending to, AND you wish to send the message DIRECT from your system to the system in the other zone, you MUST mark the message as CRASH in the message editor or the message will be routed via the appropriate Zonegate system instead of being sent direct. If I did not want to incur the expense of an international phone call to send mail to Doug, in my oMMM ROUTE.CTL I could use the following lines instead: UNCM 1:119/5 ONEHOLD 1:119/5 First oMMM bundles messages it finds in the Matrix message area, then oMMM processes lines in the route control file sequentially -- one after the other starting with the first line. In this example, oMMM would create a compressed mail bundle containing any messages to 1:119/5 and mark it as a CRASH bundle (using the .CLO extension for the flow file). The UNCM verb would then turn the flow file into a normal .FLO flow file, and the ONEHOLD verb would change that .FLO flow file into a .HLO flow file. The mail will now be held for 1:119/5 to collect when Doug calls me. THE MATRIX Page 107 +-------------------------------+ | | | "Roads? Where we're going we | | don't need roads." | | | | - from Back To The Future | | | +-------------------------------+ Enter Opus, stage right. Opus can tell by looking at the outbound holding subdirectory that there is a bundle for Doug. Opus infers from the .CLO extension that Doug's system can receive continuous mail. It is in the middle of the afternoon. Phone rates between Sydney, Australia and Chico, California are the highest that they will be all day. It is a bad time to call. We are not controlling calling times because of our software. The software does not care. Both ends can handle Matrix traffic anytime. We are controlling calling times based on the phone rates. I have a Matrix behaviour window (Z-event) set in Opus that tells the system to make daytime calls only to local systems that can receive continuous mail. 6.7 CONTROLLING OUTBOUND CALLS You have two primary methods for controlling phone calls made by your Opus system: the Opus control file (BBS.CTL) and the event manager program which manages the schedule file of events. The control file method is in effect if there is no other event to override it. Matrix behaviour windows or Z-Events described below are used to override these control file events. 6.7.1 OPUS CONTROL FILE To disable outbound calls, uncomment this line (remove the percent sign % from in front of the line) in your Opus control file: SEND NOTHING To disable long distance outbound calls, uncomment this line in your Opus control file: SEND LOCAL Page 108 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL To enable the sending of mail to nodes which can accept Continuous Mail (these nodes are marked with the CM flag in the nodelist), ie, can accept mail 24 hours a day, uncomment this line in your Opus control file: SEND CM With those restrictions, Opus now attempts to send any outbound mail it finds in the outbound mail holding area(s). If you want to keep humans off-line during a critical mail period, uncomment this line in the Opus control file: REFUSE HUMAN CALLERS There is a way to override these control file settings: Matrix behaviour windows (or Z-Events). Read on ... 6.7.2 MATRIX BEHAVIOUR WINDOWS A Matrix behaviour window or Z-Event is set up using the Opus Event Manager, OEVENT.EXE by Doug Boone. The event starts out looking like any other event ... except that it has a Z for the tag. +----------------------------------------------+ | | | "But what HAPPENS during this event?" | | | | "Nothing. It's not a real event. A better | | phrase would be BEHAVIOUR WINDOW." | | | | Anonymous | +----------------------------------------------+ When a Matrix behaviour window or Z-Event is in progress, its settings remain in effect until the next "Z" event. In other words, the settings do NOT RETURN TO THEIR ORIGINAL VALUE at the "end" of this event. If you declare a Matrix behaviour window or Z-Event for every day of the week from 09:00 (9am) to 12:00 (noon), the behaviour you describe in that behaviour window will be in effect for those three hours. Here is the part that needs to be stressed: at noon, the behaviour will remain in effect unless there is another behaviour window declared to take effect then. THE MATRIX Page 109 That should probably be repeated: * You can set up Matrix behaviour in the Opus control file (BBS.CTL). If Opus runs into a Matrix behaviour window or Z-Event that is in progress, those control file values are gone for the life of the program; * To end a Matrix behaviour window or Z-Event, you have to begin another one. In this case, the duration of the event means, "go to these values whenever you find yourself in this time period". * The end of a Matrix behaviour window or Z-Event does NOT mean return to the old values. In addition to the start time and end time, there are several other decisions you must make when setting up a Matrix behaviour window or Z-Event: Offset errorlevel? .. The offset is added to any errorlevel that Opus exits with during this behaviour window. (Optional.) Mail? ............... YES: Opus can make outbound calls during this behaviour window. NO: Opus cannot make outbound calls during this behaviour window. Local only? ......... YES: only make calls to systems whose cost field (set by your nodelist compiler) is less than or equal to the "local cost" that you set for this behaviour window. NO: it is okay to make calls that cost more than the "local call" cost that you set for this behaviour window. No Local Mail? ...... YES: do not make calls to systems whose cost field is equal to or below the "local cost" that you set for this behaviour window. NO: it is okay to make calls to systems whose cost field is above the "local call" cost that you set for this behaviour window. #CM ................. YES: only make outbound calls to systems that are marked as CM in the nodelist. NO: outbound calls are not restricted to continuous mail systems. Page 110 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL Suppress exits? ..... YES: stop Opus from exiting with "after mail" exits (set in the BBS.CTL file) after inbound and outbound matrix calls. NO: allow Opus to exit according to the Matrix exits specified in the BBS.CTL file. Mail only? .......... YES: do not let human callers online, concentrate on mail. NO: human callers and the outbound calls can coexist. File requests? ...... YES: let other systems make file requests on your system. NO: do not allow file requests on your system. Frequency? .......... A numerical value used to regulate how often Opus make outbound matrix calls during this behaviour window. Range: between 5 and 40 (5= call every 10 seconds approx, 40 = call every 12 minutes approx). (Optional.) Local call cost? .... A numerical value used to set what Opus is to regard as the "local call" cost during this behaviour window. Used by the Local Only and No Local options above. (Optional, but you should really use it to get the most out of Opus and make outbound call scheduling cost effective.) +----------------------------------------------+ | | | Getting the cost information correct is a | | vital part of controlling outbound traffic! | | | +----------------------------------------------+ During the day (from 06:30 till 20:00 AEST), I have a Matrix behaviour window that has LOCAL, #CM, and FILE REQUESTS set to YES. My local call cost field for this behaviour window is 10c. I do not want to make long-distance calls, and I do not want to call systems that cannot handle mail on a continuous basis. WARNING MAIL MARKED AS CRASH WILL ALWAYS BE SENT WARNING ===---->> REGARDLESS OF COST. Do not mark mail as CRASH WARNING unless you really want to make that call NOW! THE MATRIX Page 111 Back to the example, in my oMMM route control file I might have the following lines: UNCM 1:119/5 ONEDIRECT 1:119/5 So, if I enter a CRASH message to Doug, there it sits, a .DLO file for Doug. Although it says Doug's board can accept mail on a continuous basis, the COST field in the nodelist for 1:119/5 is $2.50 which is above my local call cost field of 10c. It is an international phone call. Opus will not call 1:119/5. At 20:00 AEST, the phone rates are lower. I have another behaviour window that allows #CM and Non-local calls. In other words, at 20:00 AEST I drop the requirement that all calls be local. At that point, Opus will start trying to send the mail to Doug. Here is how my Z-Events would go: Daytime ..... CM, Local Overnight ... CM, Non-Local ZMH ......... Mail only For ZMH (Zone Mail Hour), I drop the CM requirement. That lets Opus send to systems that cannot handle continuous mail. The point to all of this is that messages stay bundled all the time. What changes is the behaviour of Opus. That is about it ... At this point, the standard reaction is "I have some special cases that this won't handle. I have several pages of routing and batch files to do all this special stuff." Possibly, just possibly, there are some special cases that Opus outbound cannot handle. I cannot think of any. Guido says there are none, so do not try thinking any up unless you are fond of grey cement shoes and wooden overcoats. 6.8 SETTING UP BEHAVIOUR WINDOWS Set up your schedule of Matrix behaviour windows using those set out below as examples of how to control when Opus will make outbound calls depending on the cost of the calls. You can fine tune them if you want, or add more. The examples below are just meant to serve as a realistic guide as to how you should go about setting up Matrix behaviour windows. Page 112 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 6.8.1 THE ZONE MAIL HOUR The theory is, if you cannot get a message to another system at any other time, you can send it during the relevant zone mail hour (ZMH). One hour is supposed to be set aside for Matrix traffic ... with no human callers. Being able to accept traffic during ZMH is the sole requirement for maintaining your listing in the FidoNet nodelist. File requests are often disabled during the ZMH, although this is optional. Tag: Z (Matrix Behaviour Window) Day: ALL Start: (the start of the appropriate ZMH) End: (60 minutes later) Mail: Yes Local only: No No Local: No CM: No Suppress exits: Yes Mail only: Yes File requests: No (optional) Frequency: 15 Local call cost: not applicable 6.8.2 OVERNIGHT LONG DISTANCE This behaviour window tells Opus that it is okay to make long distance calls because rates are low ... but only if the remote systems can receive mail on a continuous basis. Tag: Z (Matrix Behaviour Window) Day: ALL Start: 00:00 End: 06:00 Mail: Yes Local only: No No Local: No CM: Yes Suppress exits: No Mail only: No File requests: Yes (optional) Frequency: 40 Local call cost: not applicable 6.8.3 DAYTIME LOCAL-ONLY During the day, when long distance phone rates are high, you should probably tell Opus not to make any long distance calls. In fact, the only calls should be to local systems that can accept mail continuously. THE MATRIX Page 113 Tag: Z (Matrix Behaviour Window) Day: ALL Start: 06:00 End: 23:59 Mail: Yes Local only: Yes No Local: No CM: Yes Suppress exits: No Mail only: No File requests: Yes (optional) Frequency: 40 Local call cost: (set an appropriate number of cents, depending on what you have in your nodelist control file call cost table for local calls) You should not skip setting the "local call cost"; it is one of the main ways of controlling the cost of outbound phone calls made by Opus and will reward you in the long run by saving you unnecessary phone charges. When Opus implemented the "local call cost" field, Guido now sold all his shares in the local phone company. Need we say more? 6.9 HOW TO GET INTO THE MATRIX The term "Matrix" is used to mean the worldwide amateur email network that is sometimes called FidoNet. Although this section describes the operation of FidoNet, there is nothing to stop you from creating and maintaining your own private nodelist or joining another network using FidoNet technology. Getting into FidoNet consists of getting a Matrix address. Those numbers are assigned by NET HOSTS. Normally, you cannot call your net host or log onto his/her system. That is not the way this works. Instead, you have to send a message requesting an address direct to the Network HOST to prove that your system is capable of supporting netmail. When your address is assigned, you will be informed of the address in a return message from the network host to ensure that you are also able to receive netmail. By the time you have an address, you will have proved that you have a minimally functioning system! You will have sent and received mail. Page 114 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 6.9.1 MATRIX STRUCTURE The Matrix is a loose collection of fiercely independent systems and system operators. To break things down into manageable pieces, the Matrix is divided five ways. You will be dealing with the NETWORK and NODE items for the most part: ZONE ... a very large geographical area, normally a continent (Zone 1 = North America, Zone 2 = Europe & United Kingdom, Zone 3 = Australia & NZ, Zone 4 = South America, Zone 5 = Africa, Zone 6 = Asia); REGION ... normally a large geographical area, but smaller than a continent; NETWORK ... an even smaller geographical area, often based on a local phone company free/low cost calling area; NODE ... an individual system (you may be a node!); POINT ... a sub-node (you may be a point!). Unless you are sending international email, you do not have to worry about zones. Zone Coordinators are responsible for overseeing the coordination of ZONES. Major cities are usually designated as NETWORKS in the Matrix. The person who coordinates things in a network is called a Network Coordinator (among other not-so-nice things sometimes!). The person who oversees the running of the networks in a REGION is called the Regional Coordinator. A NODE is part of a net or a region. The person who runs a node is you, the Sysop. Your system may be either a NODE or a POINT (if it is a point, refer to section 7 of this manual for details of setting up as a point. 6.9.2 MATRIX ADDRESSES A Matrix address looks like this: 3:711/401.5 That is a system in zone 3, net 711, node 401, point 5. Most of the time, you will see the shorthand version of that: 711/401 The address of a Network Coordinator or "host" system looks like this: NET/0 The host for net 711, for example, would be 711/0. The zero for the second digit is the signal that the address refers to a host. THE MATRIX Page 115 The address of a regional coordinator looks just like a network coordinator's address except that the first sequence of digits refers to the REGION not the NET. Whatever you do, do not make up your own matrix address; use -1:-1/-1.0 until you are officially assigned a matrix address. 6.9.3 FINDING YOUR NETWORK Here is how to find the network in your area: * Using a text editor or viewer, look at the raw NODELIST.nnn file. Search for your city or town -- or perhaps for other phone numbers having your area code. * Find the line that begins with the word HOST. Here is an example: Host,711,SYDNEY_NORTH,Springfield_NSW,Kevin_Mann,61-43-23-2275, 9600,PEP,MNP,CM This line tells you that folks living in North Sydney are in net number 711. The Network name indicates this, but may not always. If it does not imply a geographical area, check the location which occurs before the sysop name. If you live in a small town, you may not be in a net. Rural areas are covered by regions. If your town is not in the nodelist, do a text search for a nearby town or your State. 6.9.4 ASKING FOR AN ADDRESS * Use Opus to generate a Matrix-area message to your network host or regional coordinator; * Use Opus & oMMM to send your message; * Wait patiently for a reply. If you do not hear anything for a few days, you might call the host system and leave a local message. 6.9.5 GETTING ALONG IN THE MATRIX Please remember that network coordinators and regional coordinators do not get paid elephant dollars or even peanuts. It is a hobby for them. Getting hooked up to the Matrix can be a frustrating experience sometimes. The network coordinator knows that ... he/she had to go through it, too! Page 116 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL It is OK to ask for help. When things are finally running smoothly, you ought to consider offering to help. YOU ARE NOT A CONSUMER ... this is a hobby where everybody pitches in. There's plenty to do, and no net host can do it all. The point is that being in the Matrix is not like subscribing to a commercial service. 6.10 MATRIX FILE REQUESTS A file request is when one matrix system asks another matrix system for a file. It is something like logging onto the other system and downloading a file, but it is handled during a matrix session rather than a human caller session and is usually quicker (read cheaper) because you do not have to go through the logon sequence and then search the file areas for the file you want. Of course, it is only really of benefit if you know the name of the file you want in advance. File requests can help here too. If you request the magic filename FILES, most system will send you a compressed file containing an up to date list of files which they have available for request. 6.10.1 REQUEST METHODS There are currently two methods for handling matrix file requests: "bark" and WaZOO. "Bark" is a telink-transfer method used by some non- WaZOO systems. The WaZOO method uses zmodem and offers more capabilities than the older method. Opus will process incoming "bark" style file requests, INFO ==---->> but never initiates such requests. Opus always initiates "WaZOO" style file requests. 6.10.2 ENABLING/DISABLING REQUESTS If you want to allow other systems to make file requests from your system, comment this line in the Matrix and EchoMail Section of your Opus control file (BBS.CTL) by placing a percent sign % in front of it: REFUSE FILE REQUESTS See the section called "Matrix Behaviour Windows". You INFO ==---->> can override these control file settings with a matrix behaviour window (or Z-Event). THE MATRIX Page 117 6.10.3 THE OKFILE LIST You will need a file containing a list of files approved for file requests. This is a standard, garden-variety text file. It MAY include wildcards. Declare the file like this in the "Matrix and EchoMail Section" of your Opus control file: USES FILEREQ OKFILE c:\opus\okfile.lst This is a "raw" list of fully-pathed filenames. Normally, only one filename should be on a line. The items must begin in the far left column. The format of a normal OKFILE listing is: [!] For example, you might place the following in your OKFILE: c:\comms\*.* c:\net\node*.a?? c:\pascal\tp-tutor.zip c:\forth\this.one You can also include an optional password like this: c:\private\*.* !sesame The requesting system must supply the password with the request or Opus will not send the requested file if it is in the c:\private\ directory. Instead, Opus will send the ABOUT file as it does with all failed requests. The password is always listed as the second item, regardless of the type of request (magic, dollar sign, normal). 6.10.3.1 MAGIC FILENAME REQUESTS Opus also provides support for so-called "magic" filename requests. A magic file request is where you "define" an arbitrary "magic" name and associate it with a particular file or files which will be sent if another system requests the magic name. The format of the OKFILE for a magic filename is: @ [!] For example, you might place the following in your OKFILE: @OPUS120 c:\120\oexe_120.zip @OPUS120 c:\120\odoc_120.zip =or= @OPUS120 c:\120\oexe_120.zip c:\120\odoc_120.zip Notice that each line begins with an "at" sign @ to alert Opus to the fact that this is a magic file request. Page 118 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL You may prefer the first method of putting each associated file on a separate, especially if you have 10 or more files being sent in response to a magic filename. It makes it easier if an update comes through if you do it on a line-by-line basis. You can also optionally password protect magic filenames, for example: @BETA120 !kinky c:\120\oexe_120.zip @BETA120 !kinky c:\120\odoc_120.zip Notice that the password is preceded by an exclamation point and is the second item listed. The password is always the second item listed, regardless of the type of request (magic, dollar sign, normal). 6.10.3.2 DOLLAR SIGN FILENAMES +-------------------------------+ | The following material is not | | for novices or the squeemish. | | | | -- Guido | +-------------------------------+ You can execute a .COM, .EXE, or .BAT file from inside your OKFILE by using a dollar sign in column one. For example, if the remote system does a WaZOO file request for "LIST" and your OKFILE contains this line: $LIST C:\STUF\GETDIR.BAT %04x %04x The `%04x" items are for Opus to use to stick in additional information. They are C-Language format symbols. For more info on this convention, refer to a book on C. The data is available IN THIS ORDER: Remote net number (integer) Remote node number (integer) Future releases might include more than just those two items, so anything you do with the data should be protected from additional information appended to this list. When the LIST request comes through, Opus will bring up a copy of COMMAND.COM and try to execute "C:\Stuf\GetDir.Bat". The GetDir file could contain this: DIR *.ARC > %1%2.DIR ECHO ^%1%2.DIR >> C:\OUTBOUND\%1%2.HLO THE MATRIX Page 119 See what we did? Opus supplied the net/node of the remote system. The "%04x" items asked that the net/node be passed as two 4-character hex numbers. The batch file did a directory of all the archives in the current subdirectory, and piped the directory listing to a file made up of the net/node number and a tag of ".DIR". Then we told DOS to append or create a .HLO file for the remote system in which the .DIR file is listed. In addition, we used a "^" as the first character of the listing in the .HLO file as a signal that the .DIR file should be deleted after it is sent. Another use would be at a zone gateway. You could use this feature as a "Directory Assistance" method. Let's say I need to know all the systems in Sydney, Australia. I could put this in a .REQ file: INFO SYDNEY At the gateway, the system could have a customized program that did a case-insensitive pattern match on the other zone's node list. The system could have this in its okfile: $INFO ZONEFINO.EXE %d %d "ZoneInfo.Exe" would be the name of the program that searches the node list. Note that the ZoneInfo program would have to open up the .REQ file. The other system has sent additional information with the request ("Sydney"), and this additional information is only available in the .REQ file itself. The information is not pulled out by Opus. Leaving it in the .REQ file gives your external program the maximum amount of flexibility. Anyway, the ZoneInfo program opens the .REQ file, looks for "INFO", pulls the next token from the same line ("Sydney"), goes through the node list doing a pattern match, creates a text file with the requested information, appends a .HLO file using the net/node information supplied on its command line by Opus, and quickly exits. I said "quickly" because this entire procedure had to be finished before ZModem times out. If your external program will take more time than is available, you can always just drop DTR on the modem to end the session and create a .HLO file so the remote system can call back later for the information it wanted. Another example, in your OKFILE place the following line: $sendlogs !password c:\opus\getlog.bat %d %d GETLOG.BAT contains: pkzip c:\opus\logs c:\opus\*.log omail kill c:\opus\logs.zip -h%1/%2 -poutbound This example runs the batch file, GETLOG.BAT, passing the calling system's net/node number. The program OMAIL then runs, creating a file attach to the calling system, and Opus then regains control and then sends the file log.zip to the calling system during that call and then deletes the file logs.zip (which is why OMAIL was called with the kill command line switch). Page 120 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL If you need the information, the original .REQ file will be available in your inbound files directory to your external batch file or program. When Opus sees a dollar sign in the OKFILE, it will immediately call the external program/batch file. In other words, if there are any actual file requests in the .REQ file following the dollar-sign activator, those file requests will be ignored. The power offered by the dollar-sign convention is extraordinary. Its primary limitations are your ability and creativity. The dollar-sign convention offers low-level access to your system. Do not use it unless you are sure you know what you are doing. -- Wynn Wagner III 6.10.4 THE ABOUT FILE The ABOUT file is sent on file requests for "ABOUT," or when a file request cannot be satisfied because the file requested does not exist or is not listed in your okfile.lst or its name in the okfile.lst is misspelt. The ABOUT file should tell the requestor something about your system (eg, its main purpose or theme) and perhaps your file requesting policy (eg, when file requests can be made, how often, how many etc). It could also list any MAGIC filenames (see the section on the okfile above). Opus sends the ABOUT file if a file request fails. So, you might like to explain in the file that it may have been received because the file which was requested could not be found or was PASSWORDED (see the section on okfile.lst above). As you include the extension in the control file, the file can be a TXT, DOC, ARC or any other kind of file. 6.10.5 THE FILES FILE If the sysop of another system wants to know what files you have available for file requesting, the standard Opus method is to request a file called FILES. When Opus receives a request for FILES, it will automatically transmit the file that you have declared like this: USES FILEREQ FILELIST c:\opus\filelist.arc As you include the extension in the control file, the file can be a TXT, DOC, ARC or any other kind of file. However, it is kinder to your long-distance and international file requestors to use one of the several available file compression programs to compress the file and thereby save them a large phone bill. It will also ensure that Guido does not send Nunzio around to measure you for those grey concrete shoes he makes. THE MATRIX Page 121 6.10.6 MAKING A FILE REQUEST There are several ways to make a WaZOO file request. You can use standalone programs to generate the file request file (########.REQ) and then have Opus deliver the file, or you can use Opus together with oMMM to generate the file request file. The file request file is simply a text file which contains a list of the file(s) being requested. Wildcards are allowable. Each filename should be on a line by itself. You may add a password after the filename using an exclamation point / bang / this sign ! immediately followed by the password with no intervening space (for example, thisfile.exe !password). The filename is special and looks like this: 11112222.REQ "1111" ... a four-digit hex number that is the NET of the system that has the files we are requesting. "2222" ... a four-digit hex number that is the NODE of the system that has the files we are requesting. "REQ" ... the file tag that tells Opus this file contains file request information. * Opus still knows how to respond to the older "Bark" style method for file requests, but it does not initiate such a request. * The presence of a ".REQ" file does not make Opus make an outgoing call. Only ".?UT" and ".?LO" files cause a phone call. To generate the file request file with Opus: * enter a netmail message in your Matrix message area to the node from which you are requesting the file; * put the name of the sysop (or just Sysop) from whom you are requesting the file on the To: line ; * put the name of the file you are requesting on the subject line of the message (and !password, if applicable); * invoke the handling menu (in LORE, press enter on a blank line - in OpEd, press ^KH) by choosing H and set the "Request a file" attribute to YES; * save the message (see note below); * run oMMM which will create the .REQ file for transmission by Opus. Page 122 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL The message which you entered, assuming you did enter some "body" for it, may or may not also be sent to the system from which you were requesting the file. Check your oMMM.CFG file to ensure that the NAKED request option is not uncommented. oMMM V1.70 will only create the .REQ file if you have NAKED uncommented. The accompanying message (if any) will not be sent -- and this means that Opus will not try to make an outbound call, although you may force it to do so by POLLING the system to which you now have a valid .REQ file waiting to be sent. Another way that some grizzled Opus veterans and a certain LCD have been known to use to create requests is to use: echo nodediff > c:\outbound\00770000.REQ echo > c:\outbound\00770000.DLO If you do not understand this method, do not worry about it. When you become a grizzled Opus veteran, you will! (You do have to know the hexadecimal filename for the destination system before you can use this method -- see above for how to work it out.) 6.10.7 MAKING AN UPDATE REQUEST Making an update file request is just as easy as making a normal file request. What is an update request? Good question. Oh, you want an answer! It is a request which is conditional on the date of the file you are requesting being newer than the copy of the file you already have. To make an update request, refer to the section above on making a normal file request. The method is almost identical, except that you set Update Request to YES instead of Request a File and when you enter the filename on the subject line, you must give the full path to the copy of the file you already have on your system (ie you must type in something like c:\files\thisfile.exe rather than just thisfile.exe). When Opus calls the other system and transfers the .REQ file, the other system will only send you another copy of the file if it is newer than the one you already have! Advanced Users: note that you can also manually create "update" requests which will result in your being sent a file older than the one you have (hint: look at a sample update .REQ file and think about the time offset specified therein). 6.11 THE MATRIX MENU When Opus is at the ready prompt waiting for a call or the next scheduled event, you can get to a special Matrix section. Press "M" when you see the "Ready" prompt line. The menu includes the following options: THE MATRIX Page 123 I)nformation: This generates a chart showing the status of pending outbound traffic and where it is going. P)oll: Force a call to another system whether there is any pending outbound mail or not. If a connection is made, Opus will dynamically generate and transmit a dummy message bundle if a real one is not available. As many as 10 tries will be made. You can stop the poll by pressing . If no connection is made after several attempts, Opus will recycle to its on-line ("Ready") state. If a connection is made, you can expect all items for that node to be transmitted ... except those marked as "hold" or "left". When you cancel a poll, you may have to press a few times. The first will cancel the current call; the second one will cancel the poll. U)npack: Process/toss any PKT files found in the current default subdirectory. This does the same thing as the "-u" command line option. S)can Scans the echomail message areas looking for new messages that need to be gathered up into the outbound area. C)lear undialables Resets the "unavailable" counter for any boards that Opus has found to be unreachable, so calls may once again be made to them. Q)uit Quits so that Opus goes back to waiting for the next caller or scheduled event. 6.12 FORCING AN OUTBOUND CALL When Opus has outbound traffic but is waiting for a call, you can force it to make a call immediately. Simply press "C" when you see the "Ready" prompt line. If it has any pending mail (not counting "hold" items), Opus will make a call. In other words, this does not cause Opus to make a call it would not have made, it merely speeds up the process. Sometimes Opus will just flicker your modem lights instead of actually making a call. This is normal behaviour. Just select C)ALL again. Page 124 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 6.13 UNSUCCESSFUL CONNECTIONS Opus maintains a counter. It is incremented when there is an unconsummated connection. Whenever there is a carrier but no successful Matrix session, this counter gets bumped. +-----------------------------------------------------------+ | IMPORTANT: If Opus finds a counter file showing it tried | | five times unsuccessfully to call a node, it | | will not make any more calls to that node. | +-----------------------------------------------------------+ You can manually delete a counter file to enable further calls to the node in question. If you have some kind of daily house-cleaning routine, you could put this into your batch file: DEL C:\OPUS\OUTBOUND\*.?$? The path should be your Opus hold area. It deletes all files that have "$" as the middle character of the extension. Every time you use this statement, it will re-enable calls to nodes that had unsuccessful tries earlier. There is also a HOUSECLEANING event which will remove these counter files. 6.14 MATRIX SESSION SCRIPTS Instead of (or in addition to) a phone number, the "phone" field of a record in the node list can contain the name of a script file. The script file name and optional phone number must be in the following format: "FILENAME.EXT"123-456-7890 The quotation marks are mandatory; they tell Opus that this is a script name. The name within the quotes must be the simple filename (no directory path) of a script file in the subdirectory you've declared as being the NET_INFO subdirectory. The phone number, if given, must be in the format shown. It's used only by the AREACODE and PHONE script commands. Script names may be easily inserted into the node list by using the PHONE and/or DIAL substitution commands provided by PARSELST: phone 124/210 "HardWire.Scr" or Dial / 011- 1-201- "PCP.SCR"201- ... 1-919- "PCP.SCR"919- THE MATRIX Page 125 6.14.1 CONTENTS OF A SCRIPT FILE A script file is created with a text editor. Each line must contain a KEYWORD (refer to the Opus Technical Reference Manual for a fuller description of the full list of keywords). In many cases, a script file will contain other material. The keyword must be in the far lefthand column of each line. The system is not sensitive to the case of keywords ... uppercase and lowercase are treated the same. Some keywords require additional information. You should put a single space after the keyword, then start typing the additional information. In other words, if you put a keyword then TWO spaces ... the second space will be considered part of the additional information. Keywords Remember: In actual practice, the following keywords must always begin appear in the far lefthand column. Xmit: Send something to the modem. As in the modem initialization string in the control file, Opus understands the following special characters: ~ slight pause | transmit a character EXAMPLE: xmit ATZ| xmit AT|~ATH0| Dial: Transmit whatever additional information appears on the same line of the script, then wait for a modem response. If the modem reports any kind of failure (eg, "BUSY"), the script will be terminated. NOTE: The dial "prefix" and "suffix" from the control file are NOT used here. EXAMPLE: dial 555-1212 Areacode: Transmit the area code portion of the phone number given after the script file name, eg: "xxxxxxxx.xxx"@@@-xxx-xxxx This is primarily useful for placing PC-Pursuit calls. EXAMPLE: areacode Page 126 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL Phone: Transmit the local phone number portion of the phone number given after the script file name, eg: "xxxxxxxx.xxx"xxx-@@@-@@@@ This is primarily useful for placing PC-Pursuit calls. EXAMPLE: phone Pattern: Designate a text string to be searched for by the WAIT command. Up to 4 such text strings, numbered 0-3, may be searched for simultaneously. Each string may be a single "word" (no embedded spaces) up to 20 characters long. Upper/lower-case ARE significant; a pattern will only be matched by an identical incoming string. EXAMPLES: pattern 0 : pattern 1 OPUS pattern 2 (disables pattern) Wait: Wait for any of the text strings previously designated by PATTERN to be received from the remote system. The command will continue until either a match is found, or there is no input from the remote system for the specified number of seconds. The silence timeout defaults to 40 seconds if not given. If no match is found the script is terminated. EXAMPLES: wait wait 20 Session: In most cases, this will be the last keyword in your scripts. It means Opus should begin a network session with the remote system. The session begins with whacking, if necessary. Then it moves through the SYNC procedure into the exchange of bundles and files. EXAMPLE: session Dos: Send a command to DOS. You can process something.or even summon a stand-alone netmail session-handler. EXAMPLE: dos DIR dos ARCA test *.pkt Carrier: If there is no carrier when Opus reaches this keyword, the script will terminate. EXAMPLE: carrier THE MATRIX Page 127 Init: Go through the normal modem initialization routine. EXAMPLE: init Baud: Set the computer's async port to the remote system's baud rate. EXAMPLE: baud 6.14.2 SCRIPT CHECKLIST * Script file names are in quotes in the node list phone field; * All script files must be in the NET_INFO subdirectory; * Each line must have a keyword in the far lefthand column; * Most keywords require additional information. This information should be separated from the keyword by a single space character; * Most script files should end with "session". Page 128 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 6.14.3 SAMPLE SCRIPT This script, for PC PURSUIT, was done by Rick Huebner: +--------------------------------------------+ | init | | baud | | | | xmit ~~AT|~~ATDT3417733|~(32 squiggles)~ | | carrier | | | | xmit ~|~D~| | | pattern 0 = | | wait 10 | | xmit ~D1| | | | | pattern 0 @ | | wait 10 | | xmit ~c dial | | areacode | | xmit /12,username| | | pattern 0 = | | wait 10 | | xmit ~password| | | | | pattern 0 CONNECT | | wait 20 | | xmit ~~~~|~~~~I|~~~~ATZ| | | | | pattern 0 OK | | wait 20 | | xmit ~ATDT | | phone | | xmit | | | | | pattern 0 OPUS | | pattern 1 SEA | | pattern 2 Fido | | wait | | xmit ~~~~~~ | | carrier | | | | session | +--------------------------------------------+ THE MATRIX Page 129 6.15 MATRIX-ORIENTED BATCH FILES Any batch file for Opus must be able to respond to the following pre- defined DOS errorlevels: +-------+-------------------------------------+---------+ | VALUE | MEANING | ACTION | +-------+-------------------------------------+---------+ | 255 | an internal error generated by | recycle | | | Microsoft "C." (e.g., stack | | | | overflow | | | | | | | 4 | reserved by Opus | recycle | | | | | | 3 | extremely serious error (No FOSSIL, | halt | | | no user file, etc) | | | | | | | 2 | minor error (i/o error) | recycle | | | | | | 1 | ^C (keyboard halt request) | halt | | | | | | 0 | ??? | recycle | +-------+-------------------------------------+---------+ Sample, bare bones NERF.BAT batch file to run Opus which assumes that you are using Opus internal mail handling capabilities and oMMM to bundle Matrix messages: +----+----------------------------------------------------+ |Line| Batch file command | +----+----------------------------------------------------+ | 1 | :opus | | 2 | c: | | 3 | cd c:\opus | | 4 | Opus %1 %2 %3 %4 %5 %6 | | 5 | if ERRORLEVEL 255 goto opus | | 6 | if ERRORLEVEL 8 goto opus | | 7 | if ERRORLEVEL 7 goto bundle | | 8 | if ERRORLEVEL 3 goto end | | 9 | if ERRORLEVEL 2 goto opus | | 10 | if ERRORLEVEL 1 goto offline | | 11 | if ERRORLEVEL 0 goto opus | | 12 | :bundle | | 13 | c:\opus\oMMM | | 14 | goto start | | 15 | :offline | | 16 | | +----+----------------------------------------------------+ Page 130 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL NOTES: Line 1: Batch file label for "goto opus" Line 2: Ensure we are logged in to drive c: Line 3: Ensure we are in the Opus system directory Line 4: Runs Opus with up to six optional command line switches; you would specify these by running the batch file like this: NERF BBS which would cause the batch file to run "OPUS BBS" when it gets to this line. Line 5: The check for errorlevel 255 is not really needed here because the following line (errorlevel 8) will end up trapping 255. It is put here to stress that 255 is a possible errorlevel. Line 6: Checking for errorlevel 8 is a safety measure. It will trap any ErrorLevels above 8, too. In other words, the batch file is saying "If you get anything else just recycle." Line 7: Respond to "After Edit Exit 7". The errorlevel 7 means something in the matrix message area has changed. The only thing we need to do is put the new messages into bundles by calling oMMM. This errorlevel happens after somebody enters a message in the matrix area. Line 8: Errorlevel 3 is a reserved Opus errorlevel. The batch file should halt. Line 9: Errorlevel 2 is a reserved Opus errorlevel. The batch file should recycle. Line 10: The sysop pressed CTRL-C or ALT-Q on the keyboard to terminate Opus and return to the DOS prompt. Line 11: Errorlevel 0 is a reserved Opus errorlevel. The batch file should recycle. Line 12: The batch file bundle label used in "goto bundle". Line 13: Runs the oMMM program to bundle and/or compress any new mail to be sent to other systems. Line 14: Rerun Opus after bundling any new mail. Line 15: The batch file label used in "goto offline". Line 16: With DOS, you always have to have a blank line when the last item is a label. THE MATRIX Page 131 6.16 CHECKLIST FOR GOING ONLINE * Quadruple check to be absolutely sure that you have a "TZ" environment variable set ... and that your event manager is reacting to it well. When your system is waiting for a call, the "Ready" prompt message should show information about the next scheduled event or behaviour window. See that the time of the next event coincides with your expectations. The "TZ" environment variable can be a little tricky. See the "Setting Up Opus V1.70" section of this manual for full details. * Make sure you have an outbound holding area subdirectory; * Quadruple check to make sure that both ARCE and ARCA are on your path. This may seem silly, but some folks had trouble with it. For example, they had changed "ARCA.COM" into "AA.COM" because of a patch message archive program; * Without both ARCE and ARCE on your DOS path, you can expect problems ... tragic and/or humourous depending on your attitude. Do this: * From the DOS prompt, type ARCE and press Enter. The ARCE program should display a help screen. If it does not, do not try to run Opus outbound. ARCE must be in the Opus system directory or on your DOS path; * From the DOS prompt, type ARCA and press Enter. If ARCA does not respond with a help screen, you need to put ARCA in your Opus system directory or on your DOS path; * Put OPUS.EXE into your Opus system directory; * Customize the Opus control file, BBS.CTL, and compile it using NACL; * Compile the raw NODELIST to produce your Version 6 or Version 7 nodelist files; * Build an oMMM control file and oMMM route file; * Build a new NERF.BAT batch file. +----------------------------------------------+ | The chief cause of problems is solutions. | | | | -- Eric Sevareid | +----------------------------------------------+ Page 132 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL +--------------------------------------+ | Everything has its beauty, but not | | everyone sees it. | | -- Confucious | +--------------------------------------+ 7.0 IMPLEMENTING POINT SUPPORT Opus can function as either a "point" or in its traditional role as a fully-fledged BBS. Starting with Opus V1.70, special point support has been added to Opus to make it easy to run Opus as either a point or a "BossNode" (usually a fully-fledged Bulletin Board System which provides mail facilities points). The following sections explain how to set up Opus V1.70 as a BossNode to support a PointNet, and as a Point in a PointNet under a BossNode. Opus cannot be set up as both a BossNode and as a Point at the same time. You can, however, achieve this feat by using two Opus control files and switching from one to the other using external events to switch the resulting parameter files at the specified times. 7.1 WHAT IS A POINT? A point is the perfect solution if you are heavily into messaging and do not have the time or inclination to run and maintain a fully- fledged Bulletin Board System. A point is like a small BBS with no users other than yourself. It does not require the full time, dedicated use of a phone line and its phone number is not publicly listed in any list or the nodelist. So, what is it really? A point is a computer system which calls a fully-fledged BBS regularly to collect any new EchoMail or netmail since its last call. The new mail which is collected is then read on the point system, "off-line" from the main BBS. The mail collected is usually for one person's use only, rather than for general consumption as in the case of a fully-fledged BBS where users call into the system and read the mail on-line. A point does not have to be limited to this use only, it is just that the majority do use it this way. For example, a point could be a fully-fledged BBS which allows users to call in. The only limitation (advantage?) with a BBS point is that it is NOT included in the weekly nodelist and does not have to make its system available for other BBS calls. IMPLEMENTING POINT SUPPORT Page 133 7.2 HOW DO POINTS WORK? You leave Opus running (or to be run automatically) on your computer system at a pre-arranged time each day/night (e.g. in the early morning). At the pre-arranged time (usually when users are not allowed on the BBS), your system will phone the BBS to send all your new messages to the BBS and pick up all the new messages from the BBS. This should take 2 to 15 minutes at 2400 baud depending on how many EchoMail message conferences you wish, or are allowed, to take. Opus then sorts all the new messages out into the various EchoMail conference topics and waits for you to read them. You can come along at any time and read them, and possibly also reply to some of them. You no longer need to try calling the BBS in person to read the messages, you do not tie up the telephone lines and there are no time limits. It makes messaging very easy and leisurely. 7.3 HOW TO BECOME A FIDONET POINT A "point" system is allocated a FidoNet address. This means that a person running a point (although not listed in the nodelist) can send and receive worldwide netmail, in addition to participating in EchoMail conferences. A normal BBS FidoNet address consists of a Zone number (Australia is in Zone 3), a Network number within that Zone and a node number within that Network. For example, Sentry's full FidoNet address is 3:711/409. To get a node number in a network (and be listed in the nodelist) you need to be able to send and receive mail in the designated Zone Mail Hour and comply with the additional mail times prescribed by the particular Network in which you are a node. This means that your system must be able to be on line a considerable percentage of the day. This is where points and point operators come in. In FidoNet, points are an additional layer in the hierarchy under normal nodes. A full point address is made up of the Zone:Net/Node number of the BBS (known as the BossNode) which provides the NetMail and EchoMail service to the point plus a point number: i.e. 3:711/409.1 would be the address of point 1 under node 409 in network 711 in zone 3. The BossNode also usually needs to run special software (eg Opus) to ensure that mail from other FidoNet systems is passed on to the point to which it is addressed. It should also be noted that not every node Sysop is prepared to provide point services to someone wishing to be a point. There are many reasons for this. It does involve extra work for the Sysop of a BossNode, and it is the Sysop of the BossNode who is responsible for the behaviour or "netiquette" of the points under the node. In addition, nodes which bear a heavy mail processing burden already (for example, Network Hosts and EchoMail Hubs) will usually not be prepared to provide additional mail services to points. The bottom line is, it is a free service provided voluntarily by the Sysop of a node. It pays to ask (nicely!) the Sysops of the FidoNet nodes Page 134 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL which you frequent whether they are able or willing to support you as a point off their node. 7.4 SETTING UP AS A BOSSNODE The first step is to setup a working Opus BBS, which is explained elsewhere in the Opus documentation. Once you have the BBS working, it is just a matter of adding a line to your Opus control file. An official PointNet number may be obtained from your FidoNet Zone Coordinator, but this is not compulsory. You are free to choose whatever number your heart desires. To obtain an official PointNet number, send a netmail message to the your ZC asking to be allocated a PointNet number for your zone. The ZC will then send back to you a unique (to your zone) point net number for your use. This PointNet number needs to be added to your Opus control file in the section titled "MATRIX AND ECHOMAIL SECTION" as follows: Address 3:711/409.0 % BossNode's FidoNet address PointNet 30141 % Your PointNet number It is usually a good idea to put the PointNet option directly after your Address option in the Opus control file. The PointNet option tells Opus to check any incoming mail from the points and strip off the SEEN-BY and Origin lines and put the BossNode's Opus system's SEEN-BY and Origin lines in the message before passing it on to other systems. To send echomail to any PointNet node, is simply a matter of including that point's point address (PointNet/Point) in the SCAN line of an echomail message area definition in the Opus control file. For example (note: this area definition has been viciously edited for brevity): AREA 0002 DESQVIEW % PUBLIC MESSAGES ONLY ECHOMAIL DESQVIEW ACCESS PRIV Disgrace PATH C:\MSG\DESQVIEW\ TITLE Int'l DESQVIEW Conference [Echomail] HELP C:\OPUS\HLP\ECHOHELP.BBS SCAN 711/0 30141/1 30141/2 30141/3 END AREA Opus's support for points has certain limitations. First, you need to use Opus to process your incoming packets so that the correct addressing is placed in the point-generated mail. This leads on to the second limitation. When stripping off the SEEN-BY line inserted by the point, Opus does not save this information in the message. If the first message in any echomail message area (1.MSG) is subsequently IMPLEMENTING POINT SUPPORT Page 135 deleted and Opus re-scans messages in that area, Opus will send out second copies of the echomail messages which originated from the point to all the points in your PointNet. 7.5 SETTING UP AS A POINT To setup Opus as a point, Opus needs setting up almost as if it was going to be run as a fully-fledged BBS. This includes having a nodelist available to Opus to enable it to call its BossNode. Refer to the documentation for your favourite nodelist compiler program for details of the generation of nodelist files. Once Opus has been set up as a BBS system, adding point support is simply a matter of adding the BossNode option to the "MATRIX AND ECHOMAIL SECTION" of your Opus control file along with the Address option as follows: Address 3:30141/1.0 % Your Zone:PointNet/Point BossNode 711/409 % Your BossNode's address The address option is in the form Zone:PointNet/Point. The address is supplied by your BossNode. The BossNode is the address of the BBS which is called to pickup and send mail too. It does not include the zone, it is assumed to be the same as the zone in the address field. The address used for a point is generally for use between the point system and its boss ONLY. Some Sysops consider it to be "annoying" if the address is used to call up their system to plunder its files without first getting permission to do so. Other Sysops do not mind at all. Be warned! The point can receive netmail by using the full address of Zone:Net/Node.Point. This is 3:711/409.1 using the above examples. Your outgoing PointNet address will be translated by your BossNode to this full FidoNet address, and the address on your incoming mail will be translated from the full FidoNet address to your PointNet address. Page 136 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL +------------------------------------------+ | ... then anyone who leaves behind a | | written manual, and likewise anyone who | | receives it in the belief that such | | writing will be clear and certain, must | | be exceedingly simple-minded. | | | | -- Plato | +------------------------------------------+ 8.0 IMPLEMENTING UUCP SUPPORT While this section of the manual has no intention of providing full details on UUCP e-mail, some explanations as applicable to Opus and FidoNet are in order. UUCP is a Unix-to-Unix copy protocol -- the means by which many people on FidoNet communicate with people on other networks such as Internet and Bitnet. Several gateways operate between FidoNet and UUCP to permit such communication, and these gateways are indicated in the FidoNet nodelist by the flag "Guucp". Opus-CBCS V1.70 is the first version to incorporate UUCP awareness into a FidoNet-compatible BBS program. The Matrix section of any Opus V1.70 setup can now be configured to recognise UUCP e-mail. It must be stated, however, that this UUCP awareness merely means that Opus recognizes UUCP e-mail and can offer certain features to make its use much simpler than it has been in the past or with the other BBS programs which have netmail capabilities. This awareness does not turn an Opus setup into a UUCP gateway. 8.1 DEFINITIONS To help you understand the new Opus V1.70 UUCP features, the following is a list of definitions which are used throughout this section of the manual: Gateway -- a FidoNet system which has installed the UUCP gateway software and has registered with the FidoNet domain recognized by UUCP; From: address -- a path showing how a UUCP e-mail message made its way to the destination system; Address String -- a stand-alone line of characters containing "to:" plus address components (information on who is to receive the UUCP e-mail message plus a routing path by which that message is exported through the gateway into the proper domain); IMPLEMENTING UUCP SUPPORT Page 137 Address Tag -- a name or some alias on the UUCPlist which points to the address components Opus uses to generate an Address String; Netmail -- point-to-point mail on FidoNet; E-Mail -- point-to-point mail on Internet, Bitnet, etc; Override -- replace a parameter; Cancel -- throw away a parameter 8.2 ELEMENTARY FIDONET <--> UUCP How FidoNet interacts with UUCP depends on your perspective. The gateway has a more complicated view of the activity than does a FidoNet system served by a gateway. As the UUCP awareness now built into Opus has no impact on UseNet newsgroups (backbone echomail equivalent), the discussion in this manual concentrates on UUCP e-mail, which is the USENET equivalent to FidoNet netmail. Here are the basics: The host server (often a university) permits a FidoNet system to use UUCP for access to networks such as Internet. That FidoNet system (the gateway) has installed the software package which facilitates this access. As UUCP e-mail is imported from the host server to the gateway, the software on the gateway determines if that message is to remain "local" or be exported to another FidoNet system. If the message is destined for another FidoNet system, the appropriate zone:net/node address is applied to the message, which is then sent out as regular netmail. A non-gateway FidoNet system can take advantage of these new UUCP features built into Opus V1.70 to enter UUCP e-mail messages, reply to them, and send them via netmail to the proper gateway, even if the FidoNet system which delivered a replied-to message was not the same gateway. When a gateway receives FidoNet netmail bound for UUCP, specially installed software strips the message of FidoNet kludge lines, reads the Address String, and formats the message for use by the host server. On the next connect to the host server, the gateway delivers the UUCP e-mail. Page 138 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL If you plan to use a gateway, please notify the gateway sysop. Some gateways serve designated nets only; others serve none. But a gateway sysop might be willing to accept in-transit UUCP e-mail if prior arrangements are made. Some sysops are charged for connect time to their host servers; others are not. And remember that UUCP e-mail passing from Internet through the gateway to another FidoNet system is traveling as netmail and should be respected as such. End of an incredibly basic lesson, folks! 8.3 DIFFERENCES BETWEEN FIDONET AND UUCP When you enter a FidoNet netmail message, you respond to Matrix options prompts before entering the editor. When you enter a UUCP e- mail message, you respond to many of the same prompts, but your responses are different. In addition, some prompts have no meaning. For example, you cannot file-attach anything to a UUCP e-mail message, nor can you do file-requests. When you enter and save a UUCP e-mail message, that message typically lives out part of its life as FidoNet netmail; for the other part, it is UUCP e-mail. (If you happen to enter that message on a gateway, its netmail life span is *real* short.) Thus, you must apply both netmail and UUCP e-mail characteristics to your message. During its life as netmail, it is sent to a recipient called "UUCP." So, how do we insert the real information, such as to whom and where? With the Address String. 8.3.1 THE UUCP ADDRESS STRING A message destined for UUCP requires an Address String on line 1 of the actual message. It must stand alone on this line with no other information, for this string contains data on the person who is to receive the message and the path to reach that person. It functions like your to/destination of FidoNet netmail, and must begin with "to:" followed by address components -- the recipient/destination information. It looks something like this: to: bevvie@bricks.charm.edu or to: host!bricks.charm.edu!bevvie It is this critical string which Opus V1.70 takes into consideration when you reply to or enter UUCP e-mail. IMPLEMENTING UUCP SUPPORT Page 139 8.4 OPUS UUCP FEATURES The Opus V1.70 UUCP features work with both the full screen editor and LORE. The following is a list of these features: o Default UUCP gateway; o Default Address String; o UUCPlist; o Address String verification; o Address String handling; o Forwarding of UUCP e-mail to Matrix area. 8.4.1 SCOPE OF THE UUCP FEATURES Now that you have an overview, you are probably thinking "when are these features appropriate?" or "what can I expect?" Some of the explanations here may not be totally clear until you actually start playing with the UUCP features. 8.4.2 CONTROL FILE PARAMETERS To take full advantage of the Opus V1.70 UUCP features, certain lines of the Opus control file must be set. These lines are as follows: MATRIX AND ECHOMAIL SECTION GUUCP USES UUCPlist MESSAGE EDIT Ask UUCP USES VERSION6 OpEd and LORE EDITOR MENUS ED_UUCP GUUCP Tells Opus V1.70 the zone:net/node of the system you have assigned as your default UUCP gateway. Example: GUUCP 1:129/104.0 Page 140 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL USES UUCPlist \ Tells Opus V1.70 the location and filename of your list containing frequently contacted people and their corresponding address components. It is just like FIDOUSER.LST, a list of names and addresses. The difference is that UUCPlist is UUCP addresses, not FidoNet addresses. If this option is specified, you simply enter Netmail messages with the person's name on the address line and Opus will look them up in UUCPlist first; if that fails, then Opus tries either FIDOUSER (version 6 nodelist users) or SYSOP.NDX (version 7 nodelist users). Example: USES UUCPlist c:\opus\uucp.lst MESSAGE EDIT Ask UUCP Tells Opus 1.70 the privilege level of anyone who is permitted to cancel or override the default Address String. Any user below this privilege level will *not* be permitted to send a UUCP e-mail reply to anyone other than the individual who sent the original message. Example: MESSAGE EDIT Ask UUCP Limited ED_UUCP "" May be added to the Oped and LORE Menus. It presents the user with a display of the selected Address String and a (Y/n)? prompt to accept or cancel that string. Example: ED_UUCP Limited "Verify UUCP" USES VERSION6 This line is important for gateways because it tells Opus to use the version 6 nodelist, which is recognized by packages such as UFGATE. Gateways should uncomment it. The version 7 nodelist can be used by non-gateway systems without any impact on UUCP e-mail. 8.4.3 THE DEFAULT UUCP GATEWAY UUCP gateways are flagged in the nodelist by "Guucp." When you want to send a UUCP e-mail message, Opus will not waste time scanning the nodelist for the nearest gateway; it uses the gateway you have designated via a control file parameter. When you do any of the following, you trigger Opus to assign the gateway to that message: o Type "UUCP" on the Matrix address line; o Apply the default Address String to your message; o Apply an address from the UUCPlist to your message. IMPLEMENTING UUCP SUPPORT Page 141 Opus does NOT assign the gateway when you type "UUCP" on the "To:" line of the Matrix options. Think of "UUCP" as a recipient whose FidoNet address is your designated gateway. This gateway can be overridden by another FidoNet address. If you cancel the default Address String, the message destination becomes the originating system (which may or may not be the gateway). If you override the default Address String with an address from the UUCPlist, the message destination becomes the gateway. If you cancel the UUCPlist Address String, the message destination becomes the gateway. For details, refer to section 8.3.3 (Control File Parameters) and section 8.6 (UUCP Procedures) of this manual. 8.4.4 THE DEFAULT ADDRESS STRING This feature works only with replies to UUCP e-mail. Opus does the following to generate a default Address String: o reads the "From:" (or "From") address path of a received UUCP e-mail message; o uses that line to generate Address String components; o automatically prefaces the components with "to:" ; o inserts the Address String onto line 1 plus a blank line onto line 2 of the saved reply. Do not look for this string to appear on your message body. It is applied to the message after it has been saved. For details, refer to section 8.6 (UUCP Procedures) of this manual. 8.4.5 THE UUCPLIST The UUCPlist feature works with both replies and new messages. You create a file containing commonly used UUCP addresses. Opus does the following when you type an Address Tag from that list onto the Matrix address line: o reads the list for the tag's corresponding Address String components; o automatically prefaces the components with "to:"; o inserts the Address String onto line 1 plus a blank line on line 2 of the saved message. Do not look for this string to appear on your message body. It is applied to the message after it has been saved. Page 142 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL For details, refer to section 8.3.3 (Control File Parameters) and section 8.6 (UUCP Procedures) of this manual. 8.4.6 ADDRESS STRING VERIFICATION As you are accustomed to verifying FidoNet addresses, it is a good idea to develop the habit of verifying the Address String. Opus does NOT apply the Address String to the message until the message has been saved. Depending on how you have selected the string to use, Opus displays it in two places. It appears above the Matrix options prior to entry to the editor when all the following conditions have been met: o the message is a REPLY; o IF AND ONLY IF "Use UUCP Address" is "Yes". It appears on the Editor and Handling menus when either of the following conditions is met: o UUCPlist is used; o the default Address String is used. 8.4.7 ADDRESS STRING HANDLING Whether the Address String is defaulted or extracted from the UUCPlist, Opus permits some limited manipulation of that string in the form of a cancellation or an override. WHEN YOUR MESSAGE IS A REPLY: Prior to entering the editor, you can either cancel or override a displayed Address String via the Matrix options. After entering the editor, you can cancel, but not override, via the Editor or the Handling menus. At no time, however, can you actually modify the Address String Opus has been instructed to apply. WHEN YOUR MESSAGE IS NEW: The only feature which produces an Address String for a new message is the UUCPlist (defaults are generated from replies). This string is NOT displayed prior to entering the editor. Neither can it be canceled or overridden from the Matrix options once you have chosen to use it. But you can cancel it via the Editor Menu or the Handling Menu after you have entered the editor. At no time, however, can you actually modify the Address String Opus has been instructed to apply. For details, refer to section 8.6 (UUCP Procedures) and section 8.7 (Editor and Handling Menus) of this manual. IMPLEMENTING UUCP SUPPORT Page 143 8.4.8 FORWARDING UUCP E-MAIL TO THE MATRIX This feature works only with messages having "To: UUCP" in their headers, and does not refer to forwarding mail to another system; it refers to forwarding a particular message from one message area to the Matrix area on the same system. There may be occasions when a message destined for UUCP ends up in a message area which does not handle UUCP e-mail. In the past, when you forwarded such a message, Opus added "from/to/date" information to the top burying the Address String. Opus V1.70, however, does not. When the message contains "To: UUCP" in its header, Opus withholds adding the "from/to/date" information, thereby preserving the Address String on line 1. (Such information is added to all other messages, as usual.) 8.5 THE UUCPLIST The UUCPlist is like your own personal "UUCP nodelist". Similar in function to Fidouser.Lst, it is a simple text file which contains the addresses of individuals you frequently contact via UUCP. 8.5.1 CREATING THE UUCPLIST To create the UUCPlist, simply use a text editor and list one set of address components per Address Tag per line as follows:
An Address Tag can be any string of alpha characters: single name, first/last names, alias, some made-up name -- whatever you assign. IT CANNOT BE ALL NUMERIC. You have to create and maintain this list with a text editor. Opus does not provide an option by which you can adopt an address from some UUCP message. When you type a tag onto the Matrix address line, Opus examines the UUCPlist for a matching address. If the tag is not found, Opus assumes the tag is a name and begins a search in the Fidouser.Lst or Sysop.Ndx. If the tag is indeed a name, it might appear in both the UUCPlist and the FidoNet sysop list. To distinguish between the two, you merely customize the UUCPlist tag, ensuring that it is not identical to a name in the FidoNet nodelist. Page 144 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL == Example Of A UUCPlist == George Brown brown@fvm.info.com Boughman pitt!muswa.dialix.oz.au!wizard Pinhead saddam@bunker.blooey.gov Martha Garrity xfgt1@csvax.cal.edu Uppity Wench freed@nss.fidonet.org Digest digest+@luther.ohio.edu Vince Smith digest-request@luther.ohio.edu Vince vince@luther.ohio.edu Now . . . why "Uppity Wench"? Because "Bev Freed" is also in the FidoNet nodelist. Therefore, if you wanted to send a FidoNet netmail message to Bev Freed, you would type "Bev Freed" onto the Matrix address line. But if you wanted to send a UUCP e-mail message to Bev Freed, you would type "Uppity Wench" onto that line, because when you created the UUCPlist, you assigned "Uppity Wench" as the tag to her address components, and thereby differentiated between her FidoNet and UUCP e-mail addresses. It makes no difference to any UUCP mailer if you do not use the person's proper name on the UUCPlist. The mailer does not even know about your list. The components of the Address String are what contain the critical information. Also, notice that the last three lines on the sample list have something in common: they are all related to the same system. This ability to customize the tag is handy when you contact a person via different addresses for different reasons. In this example, Vince Smith participates on a private e-mail conference called "Digest." He is also the administrator of that conference. Plus, he has another address you can use to communicate outside the conference and outside his official capacity as conference administrator. You would use "digest" to participate in the private e-mail conference. You would use "Vince Smith" to communicate to Vince regarding Digest administrative matters. You would use "Vince" when you wanted to send personal mail that would not be placed in Vince's official administrative spool on his system. Set the multiple tags according to whatever is best for you. By the way ... there is only one legitimate entry on that sample list. If you try any of the others, you will learn "The Joy Of Bounced Mail". 8.5.2 FINDING A PROPER UUCP ADDRESS There are a few ways to determine someone's proper address: o the person tells you; o you construct an address using the From: address path; o you select the address from the person's signature line at the end of a message you have read; o you use a "reply-to" line sometimes added to UUCP e-mail. IMPLEMENTING UUCP SUPPORT Page 145 Keep in mind that a From: address should, but does not always, represent the proper path. A machine routing a message on its way to you may have discovered that another machine was down. It may have rerouted the message via a different machine at that moment. The best place to obtain a proper address is from the person with whom you wish to communicate. For more information or assistance in determining a proper address, contact your gateway sysop. 8.5.3 VIEWING THE UUCPLIST Here is a trick for keeping your UUCPlist handy for viewing even while you are in Opus. Add the following line to the Opus control file for your Editor Menu (OpEd or LORE or both): _SHOW "UUCPlist" = \ This line lets you see the entire list while you are in the message editor. To enable viewing outside the editor, I simply added that line to my Sysop Menu as well. If you maintain the list for users too, you might want to put the viewing feature elsewhere. Just keep in mind that the entire list would be available for viewing by all who had access to it. Assign it a security level at least equivalent to that for netmail access. Users cannot have separate lists. Opus looks for the filename as assigned to UUCPlist in the control file. There is one thing to say about viewing the list from the Editor Menu: it scrolls by and disappears when the screen is cleared. This does not happen when it is viewed from the Sysop Menu. To overcome this disappearing act, I added a ^A below the final entry in the list. Opus does not care that the OEC is in there. When it hits this command, it pauses, giving you a "Press Enter To Continue." Another hint: I have installed my text editor (WordStar) to run off the Sysop Menu. When, while browsing through UUCP e-mail or newsgroups, I find an address I want to add to the UUCPlist, I scribble that address down, go to the Sysop Menu, call up WS, edit the UUCPlist, save the file, then exit WS back to Opus. (In fact, I can edit on the fly many files residing on the hard drive while I am still in Opus. Comes in pretty handy when I want to see how something looks, create a quick bulletin, etc.) 8.6 UUCP PROCEDURES Now to put this information into practice. The introductory notes and feature overviews should give you an idea of what is going on when you browse through these sample procedures. Page 146 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL BLANK LINES -- Many who use UUCP e-mail are accustomed to inserting a few blank lines after posting the Address String onto line 1. Although Opus adds a blank line after applying a defaulted or UUCPlist Address String to a saved message, it is a good idea to add a blank line or two at the top of your message in case you decide to cancel the Address String and replace it with one which you manually enter. These few extra lines overcome the editor's inability to insert a blank line when any text already exists on line 1 of the message body. A blank line or two reserves that space. 8.6.1 USING NO UUCP FEATURES This procedure should be familiar to any FidoNetter who has ever used UUCP e-mail. 1. Type "E" to enter a message. 2. Type the gateway's FidoNet address on the Matrix line. 3. Type "UUCP" on the To: line. 4. Type in your subject then enter your editor. 5. Type the Address String on line 1 in the following format: to:
6. Add one or two blank lines (optional). 7. Enter then save your message. IMPLEMENTING UUCP SUPPORT Page 147 8.6.2 ASSIGNING A GATEWAY This procedure can be used when you have no default address and no entry for the message recipient in the UUCPlist. 1. Type "E" to enter a message. 2. Type "UUCP" on the Matrix line. Note: The gateway's address automatically appears, and "UUCP" appears on the To: line. 3. Type in your subject then enter your editor. 4. Type the Address String on line 1 in the following format: to:
5. Add one or two blank lines (optional). 6. Enter then save your message. 8.6.3 USING THE DEFAULT ADDRESS STRING When you reply to a UUCP e-mail message, Opus offers you a default Address String and brings up a new Matrix option special for replies: "Use UUCP address." When this option is set to "YES", the default Address String will be applied to the saved message. VERIFICATION -- The Address String may be verified as follows: o Before entering the editor -- above the Matrix options o After entering the editor -- via Editor or Handling menus Page 148 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 1. Type "R" to reply. Note: "Use UUCP Address: YES" appears as a Matrix option, and "UUCP" appears on the To: line. 2. Let the "YES" stand and move to the Matrix address line. Note: When the cursor hits the "Use UUCP Address" line, the default Address String appears on the top of the screen exactly as it will be applied to line 1 of the saved message, excluding any name in parentheses. In addition, the FidoNet address of the system which sent the message appears. (That system may or may not be the designated gateway. The saved message, however, is sent to the designated gateway.) 3. Type in your subject, then enter your editor. 4. Add one or two blank lines (optional). 5. Enter then save your message. Note: The saved message goes to the gateway. 8.6.4 OVERRIDING THE DEFAULT ADDRESS STRING Used for replies, this default can be overridden by an address from the UUCPlist, or it can be canceled to be replaced by manual entry of the Address String into line 1 of the message. When overridden by an address from the UUCPlist, the default string displayed at the top of the screen is replaced by the address from the UUCPlist, as long as "Use UUCP Address" remains set to "YES." VERIFICATION -- The Address String may be verified as follows: o Before entering the editor -- above the Matrix options o After entering the editor -- via Editor or Handling menus 1. Type "R" to reply. Note: "Use UUCP Address: YES" appears as a Matrix option, and "UUCP" appears on the To: line. 2. Move to the "Use UUCP Address" line. Note: When the cursor hits the "Use UUCP Address" line, the default Address String appears on the top of the screen exactly as it will be applied to line 1 of the saved message, excluding any name in parentheses. In addition, the FidoNet address of the system which sent the message appears. (That system may or may not be the designated gateway.) IMPLEMENTING UUCP SUPPORT Page 149 3A. To Cancel The Default Address String And Use A Manual Entry Into the Message Body, do the following: a. Type "N" at "Use UUCP Address." Note: When you set this option to "NO", the ability to override with the UUCPlist and use the designated gateway are also canceled. b. Type in the gateway's FidoNet address. 3B. To Override The Default Address String With An Address From The UUCPlist, do the following: a. Let the "YES" stand and move the cursor to the Matrix address line. b. Type the Address Tag as it appears in the UUCPlist, and hit Enter. Note: The string which will be applied to the message now appears at the top of the screen. Also, the tag is replaced by the gateway's FidoNet address. 4. Type in your subject, then enter your editor. If You Canceled The Default Address String, type the replacement Address String on line 1 in the following format: to:
5. Add one or two blank lines (optional). 6. Enter then save your message. Note: If you canceled the default string, the message goes to the originating system unless you directed the message to the gateway's FidoNet address. If you overrode the default string, the message goes to the gateway. Page 150 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 8.6.5 USING THE UUCPLIST An address from the UUCPlist can be used to apply an Address String to a new message or override the default Address String of a reply. VERIFICATION -- The Address String may be verified as follows: o Before entering the editor -- above the Matrix options IF the UUCPlist was used to override the default Address String o After entering the editor -- via Editor or Handling menus 1. Type "E" or "R" to enter a message or make a reply. 2. On the Matrix address line, type the Address Tag as it appears in the UUCPlist, and hit Enter. Note: The tag is replaced by the gateway's FidoNet address. "UUCP" appears in the To: line. If the message is a reply, the default Address String display is replaced by a display of the address from the UUCPlist. 3. Type in your subject and enter your editor. 4. Add one or two blank lines (optional). 5. Enter then save your message. Note: The message goes to the designated gateway. 8.7 EDITOR AND HANDLING MENUS Two new Opus V1.70 features let you verify Address Strings once you are in the editor. They do NOT permit editing. They permit you to cancel any default Address String or UUCPlist address. Once you cancel the address, you MUST enter the Address String manually in line 1 of the message body. For this reason, it is always a good idea to insert one or two blank lines at the top of your message body to permit such insertion and editing, in case you want to cancel the string after already starting your message text. When you cancel the default Address String, your message goes to the originating system (which may or may not be the gateway). When you cancel an Address String from the UUCPlist, your message goes to the designated gateway. IMPLEMENTING UUCP SUPPORT Page 151 8.7.1 EDITOR MENU If you have added ED_UUCP to your editor menus, Opus displays the Address String it will apply to the message. The display reads: Use
(Y/n)? If you type "N", the string is canceled. You might consider making this option available to your users, if you permit them to modify the Subject and To lines of their messages once they are in the editor. Remember: the Address String is really a "to" string. 8.7.2 HANDLING MENU A new option has been added to the Handling Menu: G)ated UUCP Address When a default Address String or a UUCPlist address is selected for application to line 1 of the saved message, this option appears on the Handling Menu, displaying the Address String that will be applied, excluding any name in parentheses. 8.8 CREDIT WHERE CREDIT IS DUE I personally want to thank Doug Boone for tackling this tremendous UUCP adventure. The folks out there who run gateways and the many, many people who use UUCP e-mail will benefit greatly from his efforts. I also want to thank Trev Roydhouse for asking me to put this section of the manual together. And of course, my dearest thanks go out to Wynn Wagner III for being Wynn. Bev Freed 1:129/104 freed@nss.fidonet.org Page 152 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL +-----------------------------------------+ | We have more useless information than | | ignorance of what is useful. | | -- Vauvenargues | +-----------------------------------------+ 9.0 ECHOMAIL An EchoMail Conference is a discussion on a particular topic which takes place on a number of FidoNet bulletin boards almost simultaneously. A message placed in an EchoMail Conference on one bulletin board is "broadcast" to all the other boards in the network which are participating in that conference. There are a number of conferences available, including international ones, which cover a wide variety of subjects. Not all conferences will necessarily be available on all FidoNet bulletin boards. What EchoMail does for you is allow you to talk to people on other FidoNet bulletin boards across the country and the world without having to know who, or where they are. You can tell an EchoMail Conference Area from the Area Name. It will say something about the echo, eg. mirrors, national conference, etc. All you have to do is enter a message in one of these areas, and it is automatically sent out to any and all FidoNet bulletin boards participating in that particular EchoMail Conference. 9.1 AN ECHOMAIL TUTORIAL Before we get down to the nitty gritty of implementing EchoMail on your system, it is worthwhile spending a few minutes learning about how to use EchoMail. What follows is an edited, and somewhat updated, version of a tutorial I grabbed from Jon Sabol's system in 1986. Jon was the original author of the tutorial. 9.1.1 ORIGIN LINES At the end of each message in an EchoMail Area there is a line called an Origin line which shows the name and FidoNet address of the board on which the message was entered. That name may or may not be a familiar to you. At the end of the origin line there are two or three numbers in parenthesis. This is the FidoNet address of the originating bulletin board, eg. EchoMail messages entered on Sentry have an origin line ending with "(3:711/401)" or "(711/401)". The "3" is the Zone number, the "711" is the network number and the "401" is the node number. You can find a listing of all the zone/net/node numbers in the entire world in a file which may be called 'NODELIST.TXT' on many FidoNet bulletin boards. If you wish to send a private FidoNet mail message (not an EchoMail ECHOMAIL Page 153 message) to a person who has entered a message in a particular conference, you can discover the person's FidoNet address by checking the origin line on the particular message which he/she entered. If you do not know how to send a FidoNet mail message, ask your friendly Sysop. 9.1.2 PRIVATE MESSAGES All the messages in each EchoMail Conference area are sent out to all the other participating bulletin boards, even if they are labelled private. Most FidoNet bulletin board software now only allows public messages in EchoMail Conference areas. Beware! If you want to send a private message to someone, you should not use an EchoMail area. You should, instead, use the FidoNet mail area (also known as the Matrix area on Opus bulletin boards). 9.1.3 PERSON-TO-PERSON MESSAGES Generally, person-to-person messages should not be entered in an EchoMail Conference. If you have a message for Bill Bloggs, and no one else is likely to be interested in it, then use FidoNet mail and not EchoMail otherwise the sysop of every bulletin board participating in that EchoMail Conference will pay to receive it. A message between two users in Sydney, received on a BBS in Perth, is not likely to win you any friends. It can be worse! If the particular EchoMail Conference is an International one, your message could end up on numerous FidoNet bulletin boards across North and South America and Europe. 9.1.4 THANK-YOU MESSAGES If you do receive a flood of replies to a question which you entered in an EchoMail Conference, it is only natural to want to thank each individual who replied. DON'T do it! Those 15 short one line messages saying "Thanks for your reply " will be echoed everywhere and are only of interest to the recipients. You have two choices: (1) send a FidoNet mail message, or (2) send a single "global" thank-you message in the EchoMail Conference (e.g. "Thanks to all those who helped with my modem problem. It is now fixed."). 9.1.5 OFF-TOPIC MESSAGES Every EchoMail conference has a subject; do not stray too far off it. Most EchoMail Conferences have a moderator who will step in and shout if the topic strays too much. Unless you have been involved in a particular conference and have a good grasp of its scope, be cautious about entering messages on new topics. Page 154 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 9.1.6 REPLIES SHOULD STAND ALONE When you reply to a message in an EchoMail conference, mention enough of the previous message so that readers can tell what you are replying to. It is maddening to see someone discussing the merits of a previous message when you cannot figure out what the previous message is about. On the other hand, it is equally maddening to see someone quote an entire message in reply only to add a short comment like "I agree" or "Me too". 9.1.7 DELAYED REPLIES Also, remember the delay inherent in an EchoMail conference. If you post a question, don't expect a response tomorrow. If you reply to a question, realise that many others may be replying at the same time, and that a flood of messages in reply may pour in over the next several days. This will be particularly so in the case of large National or International EchoMail Conferences. 9.1.8 COMMERCIAL ADVERTISEMENTS Commercial advertisements are not allowed in many of the EchoMail Conference areas. Why should the individual sysops who bear the cost of moving the messages around the country, and the world in the case of international conferences, pay for your advertising? If you do enter a commercial advertisement, you will probably be warned not to do so again and your message will be deleted. If you persist in entering commercial advertisements in an EchoMail area you can expect to have your access to the relevant bulletin board cut off by the Sysop. If you are a Sysop, your link to that particular conference may be cut. 9.1.9 COST OF ECHOMAIL EchoMail is NOT free. EchoMail messages are sent via local, long distance and international telephone calls. Unless sponsored, the Sysops involved (particularly the Sysops of "EchoMail hubs" and "host systems") bear the cost of this, and so users are NOT charged for EchoMail messages [at least in Australia]. 9.1.10 CONCLUSION Now, all you have to do to use EchoMail is read the messages in the EchoMail Conference Areas and enter or reply to them. EchoMail takes care of the rest. Please participate in EchoMail with us. We provide this as a free service, and really enjoy seeing it put to use. Enjoy! ECHOMAIL Page 155 9.1.11 ENCOUNTERS OF AN ABBREVIATED KIND In EchoMail messages you are bound to stumble over some of the abbreviations listed below. This list is far from exhaustive. It is a sample of the abbreviations noted in EchoMail over the course of a week. BTW = By The Way OTOH = On The Other Hand FWIW = For What It's Worth ROFL = Rolling On Floor Laughing IMHO = In My Humble Opinion IMNSHO = In My Not So Humble Opinion MYOB = Mind Your Own Business IMHO = In My Honest/Humble Opinion L8R = Later! ZMH = Zone Mail Hour LCD = An Opus Lower Code Dweller TNSTAAFL = There's No Such Thing As A Free Lunch 9.2 HOW ECHOMAIL STARTED Once upon a time, way back in 1985, Chuck Lawson (Dallas) and Harv Neghila (San Francisco) noticed they were spending lots of time in chat with each other ... running up their long distance phone bills. "There's got to be a better way," they concluded. "We ought to do something like netmail chat." That subject was brought up at the next notorious Dallas sysops' pizza party. All the sysops had opinions and suggestions, as is expected. Somebody noticed that Jeff Rush had quietly taken out paper and pencil. He seemed to be taking notes. The idea was forgotten -- that is, by everyone except Jeff. A month or so after the discussion, he popped up and said, "Here 'tis!" It was a couple of programs which make up the heart of the EchoMail system ... and which had no similarity to any of the designs laid out so carefully on our pepperoni conference table. He wrote a two programs: SCANMAIL, to move outbound messages from an EchoMail area into the netmail message area, and TOSSMAIL to move inbound messages from the netmail message area into the EchoMail area. We decided to try it out by starting two EchoMail message areas. One for sysops, cleverly called SYSOP... one for users called TECH. Messages bounced around (most of the time) between systems run by Chuck Lawson, Jon Sabol, and Jeff Rush. Page 156 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL The next day two other message areas were added: CHATTER and POLITICS. Two other systems were added: Wynn Wagner in Dallas and Harv Neghila in San Francisco. Chuck-to-Harv: the first backbone. They were spending their long distance money again. Now, it wasn't just for their chatting. It was for chatting from Jon and Wynn and Jeff, too... and all they users on all five systems. So it went. In short order, other sysops started getting curious and interested. The SYSOP area spread out quickly. One of the earliest battles was to keep Dallas sysops from talking about the most recent picnic or pizza party. It took quite some time for the locals to realize their little local EchoMail area was not little or local any more. [Ed: Guido's brow?] Another early problem was net hosts and region coordinators. Nobody realized that the volume of EchoMail would grow so quickly. At first, EchoMail went out like any other e-mail ... through net hosts. Those hosts quickly made it known that they were not amused by the sudden increase in their long distance bills. That seems like a reasonable attitude, and everybody agreed that EchoMail would never be "host- routed" again. "This is going to bring the network to its knees," was the cry from some quarters. So far, though, it seems to be working. The amazing thing is, EchoMail is working in spite of its lack of a firm organizational structure. The backbone is an informal coalition, and they certainly would not presume to tell you what you can or cannot do with EchoMail ... as long as you stay polite. Maybe it should be stated like this: EchoMail is working BECAUSE OF its lack of a firm organizational structure. A quotation from Wynn Wagner III (March 1991): "Jeff Rush is sometimes called the person who invented EchoMail. That is absolutely not correct. EchoMail was thought up by the sysops of Dallas. It happened at one of our pizza parties. Two sysops (Chuck/Dallas & Harv/San Francisco) were the first to draw up a design document. Jeff was the first to show up with working code. I don't want to lessen Jeff's contribution to EchoMail, but I need to make sure other toes aren't stepped on." ... and a quotation from Jeff Rush (March 1991): "In my opinion, the idea of echos was to cause all the little pockets of interesting ideas that only a few could find/dial-into to multiply into large lakes of discussion others could listen to. Specific boards should blur into the whole net, and the item of focus becomes the conference itself with its readership, and not ECHOMAIL Page 157 the BBS with its user base. This provides better dissemination of new ideas geographically. "Sort of like reaching critical mass and achieving fusion of the mind. "It means users choose their entry point into the conference based on system availability and registration requirements, and prevents a sysop from gaining a hold o ideas. "I very much object to the (seemingly) natural tendency of people to form cliques or clubs, and to withhold membership as a form of social control. I see it on the big networks and in technical support areas. People let 'friends' into special conferences and brag about how they might be able to get you in if you are up to their standards. "With echos, if the sysop is a jerk but the readership base is interesting, you go find another system that carries the echo. "Freedom of choice, we carry all flavors ... coke or pepsi or ..." You will find several national and international conferences on dozens of technical and non-technical subjects ... from Opus to C to Pascal to science fiction and genealogy. To be involved with an EchoMail conference, you first have to get a Matrix address. Although EchoMail is not affiliated with FidoNet, it would be impossible to handle EchoMail without FidoNet's Matrix structure. If you do not have an address, you need to take care of that first. 9.3 ROUTING AND COORDINATION Most EchoMail conferences have a coordinator. Someone who is supposed to help with hookups and to keep the discussion on track. Most good coordinators are quiet. That is because most EchoMail conferences rely on the goodwill and cooperation of participating sysops. Some EchoMail conferences are on what's called "the backbone". A collection of mostly mail-only systems that do very little other than process and send EchoMail. Like almost everything else that touches Opus, EchoMail is a grassroots sort of deal. It is not a commercial service that has subscriptions, and you are not a consumer. If you get involved, you can be expected to share in the expense and in the responsibility. But that is what makes it a hobby! Page 158 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL In some Zones, eg Zone 1, EchoMail is never "host-routed". --==>> It is sent directly from one system to another. In Zone 3, however, EchoMail is nearly always "host-routed" -- but +++++++++ then everything is upside down for us. IMPORTANT +++++++++ Do not attempt to send an EchoMail conference through your Net Host, Hub, Regional Coordinator or ZoneGate Operator --==>> without obtaining their approval to do so IN ADVANCE or your career in the Matrix may well be very short-lived. 9.4 GETTING STARTED WITH ECHOMAIL 1. Find an EchoMail conference you want to carry on your system. This is all fairly informal. Here are some suggestions: * Log onto another local system that carries lots of EchoMail. Leave a note to the sysop saying "Hey, can I tie into SUCH- N-SUCH on your board?" or "Where can I tie into this area?" * Check your net's newsletter or local sysop echo. Many local nets publish an up-to-date list of EchoMail conferences. * If you hear of some conference that is not available in your area, you can put yourself in charge of calling to bring it to your area. That is the way EchoMail conferences spread out! * If there simply is no conference that suits you, find another sysop who shares your interest and start your own EchoMail conference. That is precisely how conferences begin. * Do not assume you will get a helpful hand from your net host or regional coordinator. Remember that EchoMail has nothing to do with FidoNet, and some hosts/coordinators do not want anything to do with it. 3. Set up an Opus echomail message area definition in the Message Areas Section of your control file (BBS.CTL). A sample message area definition is given below: ECHOMAIL Page 159 % AREA 0030 MEADOW % Area No/Name % NAME WOC % Another Area No/Name % MENU SECTION O % Opus Section PUBLIC MESSAGES ONLY % No private messages % ALIAS % No aliases ROUTE % Private replies by netmail ECHOMAIL MEADOW % EchoMail tag ACCESS PRIV Extra % For visiting EDIT PRIV Extra % Sysops ACCESS LOCK M % but only Opus EDIT LOCK M % Sysops % PEEK PRIV % PEEK LOCK % Upload PRIV % Upload LOCK PATH C:\MSG\MEADOW\ % Message directory TITLE Int'l Meadow Conference [EchoMail] MAXLINES 60 % Three screens! % BARRICADE ADDRESS 3:711/401.0 % Who am I? ORIGIN WOCket Test Site, Sydney, Oz % Where % DOMAIN % am I? % PICTURE HELP C:\OPUS\HLP\ECHOHELP.BBS % Help! % CHARSET % PASSTHROUGH SCAN 621/201 681/854 711/907 % Where to next? % END AREA % Make sure you tell the system that the area is for ECHOMAIL and that it is to be "PUBLIC MESSAGES ONLY". (It is normally considered bad manners to send private messages in an EchoMail conference.) Refer to section 2 of the Opus Technical Reference Manual for a detailed explanation of the options in the message area definition above. 4. The Opus control file has some other EchoMail-related options which are listed below. Some of the options are designed to make EchoMail processing as automatic as possible, or to allow the use of an external EchoMail processor. A full explanation of these options may be found in section 2 of the the Opus Technical Reference Manual. Page 160 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL DOS CLOSE STANDARD FILES USES ECHOTOSS LEAVE ECHOTOSS Path BadEcho LOG Echomail SCAN Echomail ECHO Guard ECHO EconoScan ECHO NOALIAS MAXECHO AFTER Mail Exit AFTER Inbound Exit AFTER Inbound Toss Echomail AFTER Toss Exit AFTER Arcmail Exit AFTER Arcmail Extract Packets MESSAGE SHOW Ctl_A to Hidden MESSAGE SHOW Seenby to Hidden 5. Compile your BBS.CTL file with NACL to produce the BBS.PRM file which Opus needs to run. 4. In your NERF.BAT batch file that runs Opus, set things up to run oMMM from time to time, to bundle messages for transmission. Refer to the sample NERF.BAT file in Appendix A. 9.5 THE ECHOMAIL SCAN PROCESS The EchoMail scan process is triggered by one of three things: * EchoMail messages received through the Matrix. If scanning is enabled, the messages are scanned after all bundles are uncompressed and tossed. Only the areas that have new messages are scanned. * A caller entering an EchoMail message, provided you have the SCAN ECHOMAIL option in the control file uncommented. If scanning is enabled, the messages are scanned after the caller's logs off. Only the echomail areas that have new messages in them are scanned. * Selecting S)can from the M)atrix menu either while Opus is sitting at the "Ready" prompt waiting for a call or the next scheduled event or as an option off the Sysop Menu (in the latter case Opus will wait until the Sysop logs off before scanning). This will scan all EchoMail message areas which you have defined in your control file. ECHOMAIL Page 161 Bundles are created as .OUT files in the subdirectory designated as your outbound holding area. If you need other processing to take place after the scan, you can use the AFTER TOSS EXIT feature. The exit is supposed to happen after messages are scanned, whether the cause of the scan was the fact that messages came in from the Matrix or were entered by a caller. The most likely use for this EXIT will be to call oMMM to get the .OUT files into compressed mail archives. Page 162 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL +---------------------------------+ | Some folks are wise, and some | | are otherwise. | | -- Tobias Smollet | +---------------------------------+ 10.0 USING AN EXTERNAL MAILER You can configure Opus V1.70 to load an external mailer after it loads itself. The mailer will handle any matrix mail sessions. When it detects a human caller, the mailer should exit with a DOS errorlevel of baud/100. Opus will automagically trap this errorlevel, set its own baud rate and run the BBS for the caller. If the mailer exits with an errorlevel other than a valid baud rate/100, one of two things will happen: * If the errorlevel = 255, Opus will assume the mailer quit (perhaps because you want a human-only window). Opus will no longer load the external mailer but will run itself as usual. * In any other case, Opus will exit with the same errorlevel, plus the usual Z-behaviour window offset (if any). Since Opus remains in memory when the external mailer is loaded, there will be no delay between the moment Binkley, or any other compatible mailer, exits and the BBS starts. Note: With this setup, Opus runs the mailer (eg BinkleyTerm) instead of the other way around. 10.1 OPUS CONTROL FILE SETTINGS To use the external mailer option you must define the command to run the external mailer in the Opus control file. You must also tell Opus whether to use its internal mailer or the external mailer as the default mailer. You therefore have to set the MAILER COMMAND and MAILER LOAD options in the Matrix and Echomail Section of the Opus control file. For example: MAILER COMMAND BT.EXE share % Run Binkley MAILER Load 1 % 0 = Internal % 1 = Load external % 2 = Call external USING AN EXTERNAL MAILER Page 163 You should also uncomment the following line: REFUSE Inbound Traffic which will prevent the following anomalous situation from occurring: * the mailer answers the phone, decides that the caller is a human and passes control to Opus; * Opus decides the caller is a mailer and tries to do a mail session; * the caller, a human, disconnects and Opus goes back to the Ready prompt instead of taking the "after caller exit" caller and reloading the external mailer. 10.2 EXTERNAL MAILER SETTINGS A couple of notes about using External mailers like BinkleyTerm are in order. First of all, you will notice that with Binkley you must use the share command line switch to force Binkley to leave the FOSSIL driver "hot". Binkley must not deinitialize the FOSSIL driver on exit. This will probably be necessary with other mailers which use the FOSSIL driver. If you use Binkley you should also put "BBS EXIT" in your Binkley configuration file instead of using the batch or spawn method to start the BBS. This will tell Binkley to exit with the baud rate/100. You should use a similar configuration with other mailers. 10.3 OPUS MAILER EVENTS The mailer event is an event which tells Opus whether to use its own internal mailer or load an external mailer. The mailer event setting overrides the Opus control file setting. You can set Opus to use its internal mailer in the Opus control file and have a mailer event that will run your external mailer at a predetermined time. Or, you can set Opus to use an external mailer in the Opus control file and have a mailer event that will run the Opus internal mailer at a predetermined time. Whenever you have scheduled a mailer event, Opus will use either its own internal mailer or the external mailer specified in the Opus control file depending on which mailer the mailer event specifies. For example, if you have told Opus to use its internal mailer in the Opus control file, have set an external mailer command in the control file, and have a mailer event scheduled at 1:00am to run the external mailer, Opus will exit at 1.00am to the external mailer using the command line specified in the Opus control file. The external mailer will then run until you set another mailer event telling Opus to use Page 164 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL its internal mailer again and exit from the external mailer to Opus (ie the external mailer must be set to exit to Opus a minute or two after the Opus mailer event is to come into effect). Obviously if both the Opus control file and the mailer event agree on which mailer to run, nothing will happen. When they disagree, whatever mailer the mailer event specifies will override the Opus control file setting. 10.4 OPUS MAILER COMMAND LINE SWITCH You can also set an external event that would start Opus with another mailer by using the "-M" Opus command line switch. For example, you could have a FrontDoor command line set in the Opus control file for one mailer event and then start up Binkley with a command line such as: Opus BBS -M"bt.exe unattended share" The -M command line switch will override any setting in the Opus control file. Note that the mailer's command line is in quotes. This is necessary and will cause problems if it is NOT done. You should not put the external mailer's command line in quotes when it is specified in the Opus control file. Also note that there must not be a space between the -M and the first quote: Opus BBS -M "bt.exe unattended share" will NOT work properly. The -M command line switch will override both the Opus control file setting and the mailer event setting and run the specified external mailer instead. 10.5 EXTERNAL MAILER EXAMPLE In this example the following assumptions are being made: (1) the default mailer is set to the Opus internal mailer; (2) the Opus control file has the mailer command set to use Binkley; (3) an Opus Mailer event is set to start at 1:00am and use the external mailer specified in the Opus control file (Binkley); (4) an external event is set to exit Binkley with errorlevel 255 at 2:00am; (5) an Opus mailer event is set to start at 2:00am and use the Opus internal mailer; USING AN EXTERNAL MAILER Page 165 (6) Opus has an external event set to exit with errorlevel 100 at 3:00am; (7) the Opus batch file is set, using the -m Opus command line switch, to run Opus with FrontDoor as the external mailer if Opus exits with an errorlevel of 100. In the above set up, if Opus is started at midnight it will use its own internal mailer. At 1:00am, Opus will load Binkley. At 2:00am Binkley would exit to Opus and Opus would use its internal mailer. At 3:00am, Opus would exit with an errorlevel of 100 which would be trapped in the batch file to run Opus with the -M command line switch to load FrontDoor. 10.6 SCHEDULING EXTERNAL EVENTS If you have several external events which run various utilities, you will find that having those same events scheduled to be run by the external mailer and by Opus will, naturally enough, cause the events to be run twice. For example, if Binkley (as the external mailer) is active when the event is due, it will exit with the specified errorlevel, the errorlevel will be trapped, and the programs specified in the batch file will be run. Then Opus will restart, and before it loads Binkley, it will notice that it has not run the event; so it will run it (with the same errorlevel), and the event will be run twice. Now why would you do that? The answer: you want whichever of the external mailer or Opus that is active when the event should be run to run the event. If the events are not duplicated in Opus, and a caller logs on just before an external event, the caller would be able to overrun the time when the event should start. Two ways of resolving this problems are described in the following sections. Refer to the section of this manual describing the Opus Event System for further information about events or behaviour windows. 10.6.1 OPTION ONE Set up forced "dummy" external events in Opus so that Opus will know how much time is left until the next external event. The dummy events should all exit with the same errorlevel that is trapped by the batch file and simply reruns the batch file. Opus will regain control, load the external mailer, the external mailer will exit with the appropriate errorlevel (make sure it is not a valid baud rate; refer to section 10.0 above), Opus will pass the errorlevel on to the batch file, which will in turn take the appropriate action. Page 166 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL Under this setup, callers to the BBS will not be able to overrun the time when the events should occur. 10.6.2 OPTION TWO Set up the external events in Opus as usual; set up forced dummy external events to cause the external mailer to exit to Opus shortly after (1) an Opus mailer event specifying that Opus should use its internal mailer and (2) the Opus external event; set up another Opus mailer event specifying that the external mailer should be loaded after the external event has occurred. The external mailer will relinquish control to Opus which will then use its own internal mailer (ie not reload the external mailer) and will execute the external event. Opus will then execute the mailer event and reload the external mailer. Under this setup, callers to the BBS will not be able to overrun the time when the events should occur. OPUS SECURITY Page 167 +--------------------------------------------------+ | Adam was but human -- this explains it all. He | | did not want the apple for the apple's sake, he | | wanted it only because it was forbidden. | | | | Pudd'nhead Wilson | | (Mark Twain) | +--------------------------------------------------+ 11.0 OPUS SECURITY Opus-CBCS has endured as one of the most secure online systems available. Opus V1.70 maintains that heritage and adds many more features that give the sysop much improved security management flexibility. Do not feel obligated to use all the features just because they are there. It is recommended that you set up your system with moderate security features using the privilege levels at first, then take advantage of additional features as your needs demand it. The security systems for online users are both flexible and potentially complex. If you have an idea on how you wish to setup your system, but think that Opus security features will not handle it, study them some more. It is very likely that you will be able to achieve the desired end result by a careful selection and application of the various options. 11.1 ONLINE USERS Most sysops are concerned with flexibility in designing Opus CBCS security layout for online users. Opus has four primary adjuncts to achieve flexibility -- sections, privilege levels, locks, and passwords. These are described in the following section. 11.1.1 SECTIONS Each online user of a system can be allocated a "section" by the sysop at logon or can define their own section from the section menu. The ability to choose sections from the section menu can, of course, be restricted by privilege level and/or by locks. A section restricts a user's access to your Opus system. It is used to allocate message and file areas, so that a user will only be able to access those areas which are included in their allocated or chosen section. You can look at sections as being something like TBBS Sigs, except that the use of sections in Opus is optional. Page 168 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL Sections have a couple of extensions to be considered, MSG_SCAN, F_NEW, MSG_NAREA, F_LOCATE and the NextArea/PriorAreas menu commands will no longer be concerned with the high message/high file area limits. They read the section area table in the user record directly. You define the section(s) to which a message or file area belongs in the message or file area definition in the Opus control file using the SECTION option. The implementation of sections, and user defined sections, is treated in detail in the section of this manual dealing with ... sections! 11.1.2 PRIVILEGE LEVELS Each online user of a system is assigned a privilege level. This level is used by Opus to set many operating parameters. These parameters include: * Access to various Opus functions; * Total online time per day; * Total online time per session; * Lowest connect speed that can be used to access Opus; * Lowest connect speed that can be used to download files; * Total file kilobytes that may be downloaded per day. Opus has twelve privilege levels: Hidden Sysop Asstsysop Clerk Extra Favored Privil Worthy Normal Limited Disgrace Twit In order for a user to have access to a privilege protected function in Opus, he must have a privilege level equal to or greater than the function's privilege level. For example, most Opus systems will have a menu option in the MAIN menu to access the FILES section. If the FILES command has a privilege level of FAVORED, then the user must have a privilege level of FAVORED or higher to access, or even see, this command. HIDDEN is a special privilege level. You might think of it as being so high that no one can get to it. It is used for hiding a function from all users. This would be useful for hiding a menu option to a game door that you are constructing. If you set a user's privilege stored in the Opus user file to HIDDEN, it will cause Opus to hang up on them after they enter their password at logon. OPUS SECURITY Page 169 In your Opus configuration file, you set times, speeds, and file download quantities and file upload/download ratios associated with each privilege level. 11.1.3 LOCKS AND KEYS The "locks and keys" concept gives the sysop very flexible and powerful security management over a variety of functions in Opus. Locks are associated with the function and each user has a set of keys. There are 32 locks defined. They are denoted by letters and numbers as [ABCDEFGHIJKLMNOPQRSTUVWXYZ012345] for locks 1-32 respectively. If a user attempts to access a function within Opus that has locks associated with it, Opus will compare the locks that are set against the user's keys to see if there is a match. For example, suppose a user has keys A, D, and 3 enabled and wishes to access the DOWNLOAD command, which has the D lock enabled. User Keys: [A..D.........................3..] Download Locks: [...D............................] The user's key set will unlock the DOWNLOAD command, PROVIDED his privilege level is equal to or higher than the privilege assigned to the DOWNLOAD command. A simple application of locks might be to use them for certain meanings. Here is an example scheme: D Download access U Upload access E Enter Message access F File area access V Visiting sysop (use to limit access to certain functions and areas reserved for calling sysops) Y YOU - set aside certain functions that only You can access Use your imagination. Locks and keys give you great control over your system. 11.1.4 PASSWORDS AND BARRICADES Opus uses additional password protection to provide yet another level of security. Of course, every user normally must have a password to log onto your system. A second password feature is the area barricade file. Any Message/File area in Opus may have a set of passwords associated with it. These are defined in a password file associated with that area. The file is a plain text file in the following format: Password Security_Level ;comment FirstName LastName Security_Level ;comment Page 170 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL The ;comment field is optional. Opus stops reading the file after the password and security items. An example password file for an echomail message could look like this: SESAME ASSTSYSOP ; access for area moderator SHILOH PRIVIL ; access for those who can enter echomail messages GREYSTOKE NORMAL ; access for those who cannot enter messages PERFECT NORMAL ; access for those who cannot enter messages JANE TRUSTED PRIVIL ; access for Jane who will not be asked for a pwd A unique aspect of the barricade file is that it temporarily adjusts the user's privilege level to that associated with the password entered to gain access to the area. Be sure that the privilege level associated with each password in the file is sufficient to pass the access privilege level for the area and its associated menu commands. Whenever users leave a barricaded message or file area, they lose the higher or lower privilege which was conferred on them by the password file. As an added security measure, if a user logs off or otherwise disconnects while in a barricaded area, Opus always resets the last message or file area accessed, as appropriate, to area number 1 and resets their privilege level to what it was before they entered the barricaded area. Unlike Opus V1.1x, in V1.70 both message and file areas may be separately barricaded by defining a password file associated with the relevant area definition in the Opus Control File. Refer to the USES BARRICADE and BARRICADE options in section 2 of the Opus Technical Reference Manual. For further details on implementing barricaded areas, refer to the section 3 of this manual on Setting Up Opus. 11.1.5 THE USER LIST The user list may be considered to be a sensitive list on some systems. The sysop may limit the availability of the menu option to list users by using the locks and privileges described above. There is a second method to view the list that is not readily apparent. Opus has the convenience of letting you search the user list when posting a private message. This helps you to find the correct spelling of the person's name that you wish to send a message to. If the user list is to be secured, the ability to view it when posting a private message needs to be defeated. This is done in the control file by enabling the option: EDIT DISABLE USERLIST OPUS SECURITY Page 171 The user also has security options related to the user list. He can select what portions of information he allows to be displayed in the user list by going to the Change menu and turning on or off the options. These are: List User's Name List User's City List Last Time Called Once again, the sysop has ultimate control. If the sysop does not want users to have access to modifying the user list attributes, the sysop can disable the Change Menu option for selecting list attributes by using privilege levels, locks, or simple omission of the item from the menu. The Opus command line switch -NL is the same as the Opus Control File option EDIT DISABLE USERLIST and will override the control file setting. 11.1.6 OUTSIDE SECURITY The REBOOT option in the Opus Control file is a security feature which will protect your system from being left in an unknown state should you or another caller hangup or otherwise disconnect while outside of Opus. For example, if the sysop calls in and drops to DOS but loses carrier due to line noise, the next caller to the system would find themselves at the DOS prompt. Callers who find themselves at the DOS prompt have, on occasion, been known to do a lot of damage with a few strategic commands like FORMAT E:, FORMAT D:, and finally a FORMAT C:. Of course, you could recover from this disaster because you have everything currently backed up ... you do have everything backed up? Specifying REBOOT in the Opus Control File turns on the watchdog function in the fossil driver when a user selects a function that will cause Opus to exit with an errorlevel. By turning on this function, the fossil will cause a system reboot if the caller is lost while the caller is outside Opus. 11.2 APPLICATION OF ONLINE SECURITY This section is devoted to illustrating the application of online security measures. To the new Opus sysop, the security options may seem like a spaghetti bowl and very confusing. The diagram in figure 11.2-1 should help you understand the hierarchy of things. Remember there are sections, privileges, locks, and passwords. These apply in numerous places in Opus. The reason so many places exist is to provide maximum flexibility in configuration. There are some basic guidelines that you may want to follow: Page 172 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL * Use sections to restrict users' access to the various areas of your system. For example, you could use sections on a product support system so that only users with product A could access areas with section A set (ie those areas dealing with product A). * Use menu command privileges and locks to globally control access to things that will apply to the majority of your areas. * Use area specific privileges and locks to control those things in an area that are the exception to the majority of your areas. * If none of the above satisfy your needs, then your final option is to build a separate menu file for use in a specific area or sets of areas. This method carries with it more maintenance. A separate menu file gives you ultimate flexibility in configuring your system, but try to use the other Opus facilities first. OPUS SECURITY Page 173 Figure 11.2-1 Hierarchy of Opus Security Options ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º USER º º Password, Privilege & Keys º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ ³ ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º SECTIONS º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ ³ ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º MENU COMMANDS º º Privilege & Locks º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ ³ ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º BARRICADE º º Password º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ ³ ³ ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍ» ³ º MESSAGE AREA ACCESS º ³ º Privilege & Locks º ³ ÈÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÑÍÍÍͼ ³ ³ ³ ³ ³ ³ ³ ³ ³ ÚÄÄÄÄÁÄÄÄÄÂÄÄÄÄÄÁÄÄÄÄÂÄÄÄÄÄÁÄÄÄÄ¿ ³ ³EXTERNAL ³ ENTER ³ OTHER ³ ³ ³PROGRAMS ³ REPLY ³ COMMANDS ³ ³ ³ Priv ³ Priv ³ ³ ³ ³ & ³ & ³ ³ ³ ³ Locks ³ Locks ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÙ ³ ³ ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÏÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º FILE AREA ACCESS º º Privilege & Locks º ÈÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÑÍÍÍÍÍÍÍÍÍÍÑÍÍÍͼ ³ ³ ³ ³ ³ ³ ³ ³ ÚÄÄÄÄÄÁÄÄÄÄÂÄÄÄÄÁÄÄÄÄÄÂÄÄÄÄÁÄÄÄÄÄÂÄÄÄÄÁÄÄÄÄ¿ ³ EXTERNAL ³ ³ ³ OTHER ³ ³ PROGRAMS ³DOWNLOAD ³ UPLOAD ³COMMANDS ³ ³ Priv ³ Priv ³ Priv ³ ³ ³ & ³ & ³ & ³ ³ ³ Locks ³ Locks ³ Locks ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÙ Page 174 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 11.2.1 MENUS Opus menus are wonderfully flexible for security. You are only limited by the types of commands that are allowed in each major section of Opus -- MAIN, FILES, MESSAGES, SECTION, CHANGE, HISTORY, SYSOP and CUSTOM1-6. You may add and delete commands, change privileges and locks, and change the wording of the menus and even the menu prompts. The rules for building menus are explained in detail in the Opus Technical Reference Manual in section 3 (Opus Menu System). The use of privileges and locks on commands is readily apparent, but the use of multiple menu files may not quite be so obvious. Separate menu files are useful when you have one or more areas that need to be treated as "exceptions" to how your menus look for most of your areas. Suppose most of your message areas are set to use the menus shown in Figure 11.2.1-1. These menus are set in your default menu file, ENGLISH.MNU. You also have two genealogy-related conferences on your system and would like to make available a database program through the menus, when the user is accessing either of these conferences. Just define another menu called ENGLISH.001 as shown in figure 11.2.1-2 for your genealogy conferences and specify that these conferences will use menu number 1. Figure 11.2.1-1 Sample menus defined by ENGLISH.MNU ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º º º ECHO area 12 ... Communications º º Area change Enter Message Reply º º Next Prior msg Current msg º º Goodbye Kill message ?Help º º Select: º º º ÇÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ º º º ECHO area 25 ... Vietnam Veterans º º Area change Enter Message Reply º º Next Prior msg Current msg º º Goodbye Kill message ?Help º º Select: º º º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ OPUS SECURITY Page 175 Figure 11.2.1-2 Sample menus defined by ENGLISH.001 with External Program Command for Genealogy database search ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º º º ECHO area 16 ... Genealogy º º Area change Enter Message Reply º º Next Prior msg Current msg º º Goodbye Kill message DATABASE Search º º ?Help º º Select: º º º ÇÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĶ º º º ECHO area 17 ... Jewish Genealogy º º Area change Enter Message Reply º º Next Prior msg Current msg º º Goodbye Kill message DATABASE Search º º ?Help º º Select: º º º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ 11.2.2 AREAS It is quite common to have a need for security variations from area to area. The first level of security checked per area is the barricade password option, if you have it enabled. In Opus V1.70 the barricade password for an area is separately definable for each message and file section. In Opus 1.1x, the same barricade password applied to the message and file area which had the same area number. All area associated security options are now independent of each other with respect to message and file areas. In message areas, you have separately definable privilege levels and locks for each of these: * Area access; * Message creation (Enter or Reply or Upload or Upload Reply); * Every external program. In file areas, you have separately definable privilege levels and locks for each of these: * Area access; * Download command; * Download & Hangup command; * Upload command; * Every external program. Page 176 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 11.2.3 OPUS EMBEDDED COMMANDS Opus embedded commands provide the sysop with the ultimate flexibility in customizing system security. There are embedded commands to control presentation of text file segments to a user according to privilege level and key settings. These are explained in detail in the embedded codes section on customizing Opus. With embedded commands, you could do things like: * Present a note of explanation, then hangup on a user that is relegated to privilege level of TWIT. * Ask a set of questions, then automatically invoke a callback validation program. * Ask a set of questions and change a user's privilege level with an external program depending on their answers. * Ask a set of questions and add or remove a user's keys using the OECs to add and remove keys. * Present access to external program such as online games, but do so on the basis of privilege of key settings. * Lock out a mail waiting program to new users based on privilege level. Since they are new and will not have any mail waiting anyway, it prevents a useless "Check for mail". * Present an AREAINFO file (see section 5 of the Opus Technical Reference Manual -- Opus Support Files) in your "members" area where you require new users to post short biographies about themselves. After the users are validated and their privilege is raised, the AREAINFO will not display to them based on their elevated privilege level. In this way, they can go read the biographies of other users without the annoyance of having to read the file that gives new user instructions. 11.3.1 MATRIX AND ECHOMAIL SECURITY If a sysop runs matrix and EchoMail with Opus, there may be a need to use security measures to protect against unauthorized access, unauthorized routing of mail through your system, prevent hostile file upload via the matrix, prevent unauthorized pickup of mail, and even prevent the insertion of bogus EchoMail into the system. All of these things can and have happened in different networks. Opus provides a number security measures to help protect you from these attacks on your system integrity. OPUS SECURITY Page 177 11.3.1 SESSION LEVEL PASSWORDS In order to prevent a node from "impersonating" another node and picking up their mail, matrix session level passwords may be implemented. Opus supports password matrix sessions with other mailers. The password can be up to eight characters long. Opus treats upper and lower case characters in the password as the same character, i.e., "Password" is the same as "PASSWORD". You insert the passwords for the various nodes into your nodelist using your favourite nodelist compiler. Refer to the documentation for your nodelist compiler for details on implementing this option. 11.3.2 FILE REQUESTS When you set up your system to accept file requests and update file requests, you can password certain files in your file request list to prevent unauthorized access to those files. This might be useful if you are part of a software test team and you want to make new versions of the software available in a secure way to your team. See the section on file requests in the matrix mail section of this manual on how to setup passwords. 11.3.3 ECHOMAIL Unfortunately, there have been instances of EchoMail abuse wherein an errant sysop sent inflammatory or bogus messages into a conference by sending them to a node in the matrix that carried the conference. Opus has protection for this with a feature called ECHO GUARD. You simply enable this feature in the Opus control file. With this feature enabled, any message received for a conference which does not come from a passworded connection, will be tossed into the matrix area and marked as an orphan. If you have the PATH BADECHO enabled, the messages will be tossed into the bad messages directory. 11.3.4 INTRANSIT MAIL Intransit mail is mail that is sent to your system but is addressed to another system. There are legitimate and intentional reasons to do this. However, it is hardly welcome, if someone sends mail to your system that is destined for a long distance telephone call. If your system processes the mail and sends it along, guess who gets to pay the phone bill? You, yourself, you. Page 178 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL Opus has protection against intransit mail that you do not want. There are four options in the Opus control file to help protect you. They are: REFUSE All InTransit REFUSE Unpassworded InTransit REFUSE Nonlocal InTransit REFUSE Attribute InTransit The function of each of these is explained in detail in the Opus Control File Parameters section of the Opus Technical Reference Manual. 11.4 OPUS NAME FILTER Opus has its own inbuilt "bad name", "dirty word" or "trashcan" name filter for filtering out the undesirable names which some callers to your system invariably try to use for their logon name. The filter is also handy for stopping that rogue modem which wants to log on to your system using your phone number for its name! What? You do not get those calls? You will. 11.4.1 CONTROL FILE SETTINGS To use the inbuilt name filter you need to uncomment the USES NAMEFILTER option in your Opus control file (BBS.CTL). For example, USES NAMEFILTER c:\opus\misc\username.txt The precise format for the file "username.txt" is described below. There is also another control file option, USES BADNAME, which you may optionally use to deliver a custom message to the caller whose name has been rejected by the filter, just before Opus hangs up. For example: USES BADNAME c:\opus\misc\badname Note: When you define the filename for the badname message, you do not use a file extension. However, the file you define must be an OEC file with a BBS extension (ie, the file in the example would be badname.bbs). Do not forget to recompile your BBS.CTL file with NACL after making these changes! OPUS SECURITY Page 179 11.4.2 FILTER NAME FILE FORMAT The filter name file contains a sequence of lines that are interpreted in one of two ways, depending on the first character: ? ... the material that follows on this line is not to appear in any form in a caller's name EXAMPLE: ?shit ! ... the material that follows on this line is not to appear AS IS in a caller's name. This is a case sensitive filter. EXAMPLE: !Ass Remember that Opus converts all names to an uppercase character followed by lowercase characters. In the first example, the character sequence "shit" would be disallowed in any form in a caller's name. In the second example, "Ass" would be thrown out ONLY if it appears as the first Three characters of a caller's first or last name. The reason for the second (case sensitive) version is this: the characters "ass" appear in several legitimate names. One other special character is available: the hash sign or American (not English) pound sign. Opus will convert a hash/pound sign to a SPACE character. This lets you further refine your list of banned words for caller names. EXAMPLE: ?All# After all, you do not want to keep everybody named "Allison" off your system just because you are trying to keep folks from logging on as "All". 11.4.3 BEHAVIOUR OF THE FILTER Opus will go through the file defined by the USES NAMEFILTER option on a line-by-line basis after an unregistered caller types his/her name. If Opus finds a problem, it will either: (1) pretend that you run a PRIVATE system that requires pre- registration and hang up on the caller after sending the message "This is a Private system."; or (2) If you have defined a badname message file, Opus will show that file to the caller before hanging up. Problems include a match with any item in the USERNAME.TXT file ... or some DOS I/O error in reading the file. Page 180 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 11.4.4 ERRORS IN THE FILTER NAME FILE The name filter is really an idiot when it comes to error recovery. It assumes that if you are using the filter, you know how to use it. Here is an example, if a line in the name file begins with some character other than "?" or "!" then the entire line is ignored. There is no error message. In a nutshell, if you decide to use the filter you need to be sure you are using it correctly because the system's primary job is that of a filter ... not a tutorial on its usage. 11.4.5 SPECIFIC EXAMPLES OF USE Set out below are a few specific examples of how to use the inbuilt name filter. These are all taken from a working filter file that has not been modified in months, so you should not encounter any unexpected problems. Note: each item should appear by itself on its own line, starting in the far left column. The setting out in the following sections is to save space. 11.4.5.1 ONE LETTER NAMES To prevent callers from using one letter names, you need to have the following in your name filter text file: !A# !B# (all the way to) !Z# 11.4.5.2 ROGUE MODEM NAMES To prevent those rogue modems from logging on to your system, you need to have the following in your name filter text file : ?atd ?+ ?4 ?8 ?atz ?1 ?5 ?9 ?atdp ?2 ?6 ?0 ?atdt ?3 ?7 OPUS SECURITY Page 181 11.4.5.3 SHY CALLER NAMES Some callers are _very_ shy when it comes to revealing their real name(s) to Opus. Here are a few of the more common shy personalities for your name filter file: ?test ?qwer ?asdf ?visitor 11.4.5.4 DIRTY WORD NAMES You will have to supply your own, but here are a few pointers. The following entry will prevent anyone using "Xxxx" as a first name, middle name or last name: !Xxxx# 11.4.5.5 WANNABE HACKER NAMES Ever since 1986 when Fido V11w was in vogue, there have been the wannabe hackers who try to log on to a system as "All", "Anyone" and "Everyone" and then merrily proceed to go through the message areas deleting messages. Of course, with today's volume of EchoMail this may no longer be the major disaster it once was! To spoil their fun, add the following to your name filter file: !All# !Anyone# !Everyone# What about ye olde "Hacker" who calls? You may have to handle this case carefully. A quick check of the Sydney metropolitan telephone directory reveals about a dozen people listed with that surname, so it is not necessarily a good idea to lock out "Hacker" with: !Hacker# unless you are sure either that (1) you will not get any calls from legitimate Hackers, or (2) you do not want any calls from anyone with that name. Page 182 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL +-----------------------------------------+ | The greatest fool is he who thinks he | | is not one and all others are. | | | | -- Baltasar Gracian | +-----------------------------------------+ 12.0 OPUS FOLKLORE Opus has attracted its fair share of ... "Guido, put that bat down NOW!" ... 12.1 THE ELUSIVE NERF.BAT Ever wondered why the batch file commonly used to run an Opus-CBCS is named NERF.BAT ? Well, here is how it all began ... "From: Wynn Wagner III Subj: RE: Nerf.bat "DEEP BACKGROUND. "It started here at work on my first project in C. I'm an old assembly language jockey, and I was having some trouble with C. "I used to take the white "K-and-R" book on C (that's kind of the C Bible), put it on the floor, and jump up and down on it. "My manager at the time bought me a nerf HAMMER and told me to use it on the book so I didn't cause quite so much damage. She also said this: "I was going to get you a nerf bat, but I figured the hammer was more business-like." "I still have the hammer in my office. I still use it sometimes. The "K-and-R" book was worn out years ago. "NERF FOR OPUS. "I did some of the docs for Opus 0.0. [Editor's note: it was the V1.00 docs] On a lark, I stuck in "nerf bat" in the "Required Equipment" list. "I mean, it's for hobbyists. There wasn't any requirement to be businesslike, so the bat made more sense than the hammer. OPUS FOLKLORE Page 183 "The 0.0 docs were full of junk like that: quotes and leg-pulling and on and on. There's a difference between being serious and being solemn. The 0.0 docs were serious, but they weren't very solemn. "MISSING THE WHOLE POINT. "Somewhere along the way, somebody did some docs for Opus called NERF FREE. As far as I can tell, about the only thing these 'unauthorized' docs did was remove the humor. "Nowadays, the Opus ByLaws And Covert Action Committee requires humor for Opus documentation, so that kind of nonsense won't happen again." ... and the list of required hardware in the Opus V1.00 documentation read: "Required Hardware "Standard equipment for Opus consists of: AT-class computer with Award BIOS 72-Meg hard drive One each: TeleBit Trailblazer modem (9600 bps) U.S.Robotics HST modem (9600 bps) Amdek 722 EGA monitor PC DOS 3.3 Mirror sunglasses Nerf bat "That roughly describes Wynn's computer setup. It is the only one that carries any sort of assurances. It is: -={ Opus will sometimes run on Wynn's computer }=- "No other assurances are made. All other equipment is officially classified as Non-Standard." Page 184 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL ... and then there was THAT message in the MEADOW: "From: Jim Beeler To: All Subj: Nerf.bat "I have a friend at work who I am helping set up an OPUS BBS for his company located in Tokyo, Japan. Being Oriental, he possesses infinite patience and, unlike his American counterparts in the U.S., realises the importance of following instructions to the Letter. "He began installing OPUS utilising the OKITs. Soon he discovered the missing items: Mirror Shades and a NERF Bat. Realising that these must be necessary items, he pulled out his sunglasses. The nerf bat, however, was another problem. Not realising exactly what a Nerf Bat was, but none-the-less realising that if it was in the documentation it must be necessary, he searched through the .ARC files for further references to the elusive Nerf Bat. Finally, he figured it out! "He called me over to his computer to see the installation of OPUS that he had done ... from the "C:\" prompt he evoked NERF.BAT and up came OPUS. "So, for those of you that have trouble locating a Nerf Bat, take a lesson from a wise Oriental, just rename your RUNBBS.BAT to NERF.BAT. Jim." ... and now you know what, hithertofor, only some of us really grizzled Opus veterans were privy to. 12.2 IDENTIFYING THE CHICO CONNECTION You can tell someone from Chico by two words, "fir" ("I'm going fir some beer.") and "ahmund" ("We knock the 'L' out of them." You have to see the way almonds are harvested to get it.) -- From a conversation 12.3 oPOL0: OPUS POLICY, VERSION ZERO (pronounced "oh-pahl'-oh") This is the official policy statement of WOC: The Worldwide Opus Consortium. OPUS FOLKLORE Page 185 12.3.1 DRESS CODE WOC sysops must wear mirror shades. 12.3.2 ATTITUDE There is a difference between "serious" and "solemn". Any WOC sysop caught being solemn will be referred to the Enforcement Squad of the Opus ByLaws and Covert Action Committee for a solemnectomy. Any WOC sysop caught being sirius will be sent to Bob Klahn for technical support. 12.3.3 BACKBITING, SNIDE REMARKS, AND ON AND ON Any WOC sysop who backbites, or makes a snide remark to another WOC sysop, or who on-and-on's will be forced to memorize the entire set of GBS/BBS embedded commands. Note that the "snide remark" clause only refers to other WOC sysops. It's okay to snipe at non-WOC sysops. 12.3.4 MATRIX If you run netmail, you gotta run Zone Mail Hour. 12.3.5 TRANSIENTS If you accept "In Transit" messages, you can't delete or change the content unless it would be illegal for you to transmit the messages. If you do delete or change messages, your title is "editor" instead of "host." Because WOC doesn't have a title anything like "editor", deleting or changing a message is the same thing as resigning as host. The change clause does not apply to software which adds "Via" or "SeenBy" or other automated festooning for reasonable technical purposes. Page 186 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 12.3.6 RULES IN A NUTSHELL Rule #1: Don't take yourself so seriously. Rule #2: Run Zone Mail Hour. Rule #3: Don't delete or change "in transit" messages. Rule #4: Send code. 12.3.7 ENFORCEMENT Except where noted, this is a codification of Natural Law. It is not necessary to account for enforcement of such things as the National Mail Hour in the same way as it isn't necessary to enforce the Laws of Gravity. It is like there is no need to make a law that says "All bachelors must remain unmarried." That would be silly. When a bachelor gets married, he's simply not a bachelor any more. When a system doesn't run Zone Mail Hour, it isn't running net-mail. It's very simple and straight-forward. Enforcement of the Unnatural Laws, such as wearing mirror shades, is absolute. It is now a standard that any WOC software incorporate enforcement procedures. For example, when entering chatmode, WOC software will produce a brilliant flash on the monitor that could result in eye damage to anybody not wearing mirror shades. 12.3.8 DISCLAIMER Membership in WOC doesn't preclude membership in any other association. WOC is neither for or against anything or anybody, and never takes a stand on any issue (except mirror shades). OPUS FOLKLORE Page 187 12.3.9 MERIT BADGES The following merit badges are available to WOC members: * Continuous Mail... WOC AROUND THE CLOCK logon certificate * 386-based mail system... WOC DON'T RUN gbs file * WOC system carrying more than 50 echomail areas... WOC ON THE WILD SIDE ribbon * New WOC sysop... OUT OF THE SKILLET INTO THE WOC badge Penalties for improperly displaying a WOC badge or honor gbs file are too severe to even mention. Page 188 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL +-------------------------------------------------+ | It is a shameful thing to be weary of enquiry | | when what we search for is excellence. | | | | -- Cicero | +-------------------------------------------------+ 13.0 MORE INFORMATION ON OPUS There are two ways to find out more about the way Opus works and to get questions answered. If you are having problems with Opus, contact one of the InfoNodes. DO NOT CONTACT THEM if you have not carefully read the whole of the Opus Technical Reference Manual and the Opus Operations Manual. System name Phone number Location FidoNet ---------------- -------------- -------------------- --------- OPUSinfo `West' 1-404-296-9681 Atlanta, Ga 1:1/113 OPUSinfo `Under' +61-2-872-3571 Sydney NSW Australia 3:3/113 OPUSinfo `Europe' +46-46-138039 Lund, Sweden 2:200/420 OPUSinfo `East' +866-6-237-0657 Tainan, Taiwan 6:721/100 OPUSinfo `Snail' P.O. Box 16410 San Francisco Ca 94116 (send SASE) OPUSarchive 1-713-980-9671 Houston Texas 1:106/2000 (specs etc) The above nodes are for questions involving specific problems. They can give you answers to some of the most commonly asked questions. Other help nodes are: System name Phone number FidoNet Notes ----------- ------------- --------- ------------------- Sentry +61-2-428-4687 3:711/401 Technical Reference Sentry's Shadow +61-2-418-6682 3:711/501 Operations Manual Milliways BBS 1-703-491-5445 1:265/100 oMMM operation NS BBS 1-412-366-5208 1:129/104 Meadow echo area For general discussions about the usage of Opus, you should seriously consider subscribing to the Opus sysop EchoMail area, called MEADOW. Any of the distribution nodes can refer you to a tie-in point for this area. If all else fails, contact Bev Freed at 1:129/104 for information pertaining to MEADOW EchoMail connections. MEADOW carries the same copyright as Opus. You are required to act in a friendly and lawful manner if you participate. We are trying desperately to keep a casual and constructive atmosphere in the Opus area. If that is not your intent, please do not subscribe to the conference. If you wish to discuss technical aspects of the programs, you are wholeheartedly welcome to join!!! MORE INFORMATION ON OPUS Page 189 Here are the MEADOW "rules" posted by the moderator (aka the Uppity Wench ... don't ask!): From: Bev Freed To: All Subj: Meadow Rules Guess what? It's that time of the month again: MEADOW ADMINISTRIVIA! TOPIC: Meadow is for the discussion of Opus problems, the future of Opus, Opus utilities, suggestions, ideas, and support among Opus sysops. It is involved in the technical operation of Opus and responsible to the Opus Bylaws and Covert Action Committee. PARTICIPANTS: Opus sysops ONLY! Definitely UNAVAILABLE to users. While sysops of other systems are welcome to READ Meadow, they can't expect answers to QBBS, TBBS, Fido, or whateveryourerunningthisweek. That would be off-topic. RULES: In addition to general rules for any conference, Meadow rules are simple, standard, and may be bent a little, but not trashed. The Meadow "spirit" is one of cooperation. And remember: Guido is watching. 1. Keep your messages on-topic -- On occasion, the Moderator may get the feeling that message content is inappropriate or has the potential to attract a barrage of inappropriate messages. In such instances, the Moderator will post a reminder of the rules or send netmail. It's not personal. If you post an off-topic message, let it be for comic relief and the fostering of friendships. 2. Be excellent to one another and keep your sense of humor -- Personal attacks (thinly disguised or not) are prohibited. The useful exchange of information requires you to accept that people have opinions or experiences which contrast yours. The object of this conference is to learn from others, not argue with them. 3. Be helpful -- If you can help someone with a technical problem, PLEASE do, but avoid blind guesses. You'd be doing a disservice. If you're not certain of a proper response, wait a few days to see if someone out there has the definitive answer. Then everyone learns something. 4. Never use Meadow to reply to inappropriate messages -- If you feel a message is inappropriate, simply take a deep breath and ignore it. It'll go away. And if it doesn't, LET THE MODERATOR HANDLE THE PROBLEM. If you feel particularly strong about a specific posting, send the Moderator private netmail, or take your beef off-echo and flame the person directly. Leave the others out of it. The Moderator has probably already addressed the problem via netmail. Page 190 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL 5. Keep your quotes to a minimum -- People read Meadow regularly; you don't need to quote and explain the obvious. If you get a bad case of quotitis, the Moderator will come over to administer something you hated as a kid. 6. Keep your messages public and without nuisances such as encryption, encoding, or rotation -- If you have a driving need to send a private or fancy message, there's something intriguing out there called netmail. Use it. 7. Keep to a minimum BBS ads and notices on new conferences or toys-- Such advertisements and so on should be restricted to no more than ONCE per month. We hear ya, already. HANDLES: While not encouraged, "handles" or anonymous names are permitted provided they are not used with the intent to conceal the identity of a person posting malicious, annoying, or illegal messages. Please include your proper name someplace on every message. NONCOMPLIANCE: If you cannot abide by and comply with the rules, you are requested to forego posting messages to this conference. Anyone who posts inappropriate messages will be warned of the infraction. If such postings continue, you will be asked to drop the conference. If you do not drop the conference voluntarily, the system(s) uproute will be asked to disconnect your feed. This method of keeping the Meadow interesting and productive is not preferred. It is preferable that participants simply abide by the rules and "spirit" of the conference, and that they serve one another. Bev Freed -- Meadow Moderator and Uppity Wench, 1:129/104 freed@nss.fidonet.org --- Opus-CBCS 1.14 * Origin: NSS BBS - Ad Astra! (412)366-5208 *HST* (1:129/104.0) From: Bev Freed To: All Subj: Rules follow-up NOTICE ON OPUS DEVELOPMENT Opus isn't something you slam in and let 'er rip. It's an ongoing project which means it's ALWAYS under development. It's fostered by the entire Opus community -- Lower Code Dwellers (LCDs) as well as Opus sysops and grizzled veterans -- within an environment of participation, cooperation, and above all, PATIENCE. The list at the bottom of this notice changes as needed to address many of the complaints/requests in Meadow. MORE INFORMATION ON OPUS Page 191 BUG/SECURITY PROBLEMS: In the course of all human events, we encounter problems. And so it goes with Opus development. When you feel you've encountered a real nasty bug or security problem, send your reports via DIRECT netmail to 1:119/25 or 1:129/104. Otherwise, use Meadow. Someone out there has probably already solved your troubles. NEW RELEASES: Please don't ask when the next version of OPUS will be released. You'll always receive the standard answer: WHEN IT'S READY. The LCD's maintain Opus as a hobby. It isn't a full-time job for anyone. No one is making money from this. After the beta and gamma testers have had their chance to break Opus, the new(est) version will be released for everyone. Please be patient. And when it's ready, you'll hear it on Meadow first. :-) SEND CODE: If you have a suggestion, try to provide as complete an explanation/model/example/source-code as you can. Even a chunk of BASIC code is better than nothing at all. Send code to Doug Boone at 119/25. SEND DOCS: If you have a good explanation of how to handle aspects of Opus or integration of tricks and utilities, please share them. Send docs or a note that you have them on hold to Trev Roydhouse at 3:711/401 (PEP) or 3:711/501 (V32). Page 192 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL APPENDIX A: COMMENTED NERF.BAT @ECHO OFF C: CD C:\OPUS REM make sure we are where we think we are X00 B,0,19200 T=8192 R=4096 F=12 XU CAPTURE REM load the comms fossil and make sure it has REM control of the comms interrupt :MODEM SET OPUS=BBS SET TZ=UTC-10 REM set up some environment variables, especially the REM timezone (tz) so that opus can keep track of events AT COM1: s2=255s7=50s50=0s52=1s53=1s54=4q0v1 AT COM1: s0=0s9=12s51=5s58=2s66=1s68=2s90=1e0x3&w REM initialise the trailblazer OPUSDATE + NERF ** Sentry Opus Online ** >> C:\opus\opus.log REM make a log entry :OPUS CHAT120 25 OPUS BBS REM load the chat fossil and run opus using the bbs REM parameter file produced from the bbs.ctl file by nacl :TEST IF ERRORLEVEL 255 GOTO ERROR255 IF ERRORLEVEL 16 GOTO MASH IF ERRORLEVEL 12 GOTO DOS IF ERRORLEVEL 9 GOTO OPUS IF ERRORLEVEL 4 GOTO ERROR4 IF ERRORLEVEL 3 GOTO ERROR3 IF ERRORLEVEL 2 GOTO ERROR2 IF ERRORLEVEL 1 GOTO OFFLINE GOTO ERROR0 REM test for various dos errorlevels so that REM we can take the appropriate action :MASH OMMM GOTO OPUS REM run oMMM to bundle mail and then rerun opus :DOS OPUSDATE # NERF Sysop dropped to DOS >> c:\opus\opus.log REM log that sysop is heading for dos NEWBAUD C:\OPUS\LASTUS00.DAT APPENDIX A: COMMENTED NERF.BAT Page 193 IF ERRORLEVEL 96 GOTO REMOTE_DROP IF ERRORLEVEL 48 GOTO REMOTE_DROP IF ERRORLEVEL 24 GOTO REMOTE_DROP IF ERRORLEVEL 12 GOTO REMOTE_DROP IF ERRORLEVEL 3 GOTO REMOTE_DROP IF ERRORLEVEL 0 GOTO LOCAL_DROP REM newbaud reads the baud rate from lastus00.dat and exits REM with an errorlevel = baud/100 so we can check if the REM sysop logged on from the keyboard :REMOTE_DROP FSU 1 ON + CTTY COM1: ECHO ## Type EXIT to return to Opus ## ECHO ** Carrier Monitoring in effect ** REM sysop must be logged on remotely so REM turn on modem carrier watchdog and REM redirect screen and keybaord to the REM comms port :LOCAL_DROP COMMAND REM we are here either because we fell through from REM remote_drop, or the sysop logged on from the REM keyboard :RETURN C: CD C:\OPUS FSU 1 OFF - OPUSDATE # NERF Sysop returned from DOS >> c:\opus\opus.log CTTY CON REM make sure we are in the opus directory when returning REM from dos, turn off carrier watchdog, log sysop's return REM and cancel redirection of screen and keyboard OPUS BBS -O GOTO TEST REM restart opus with the relog option and loop back to REM errorlevel tests NOTE: after relog exit is set to 9 REM so that after the sysop logs off opus will exit with REM errorlevel 9 and be rerun without the -o relog switch :ERROR0 OPUSDATE ! NERF Errorlevel not detected in TEST >> c:\opus\opus.log GOTO OPUS REM log error and rerun opus :ERROR2 OPUSDATE ! NERF Opus Errorlevel 2: Recycling >> c:\opus\opus.log GOTO OPUS REM log error and rerun opus :ERROR3 OPUSDATE ! NERF Opus Errorlevel 3: Halting >> c:\opus\opus.log Page 194 OPUS-CBCS V1.70 SYSOP OPERATIONS MANUAL GOTO OFFLINE REM log error and halt :ERROR4 OPUSDATE ! NERF Opus Errorlevel 4: Recycling >> c:\opus\opus.log GOTO OPUS REM log error and rerun opus :ERROR255 OPUSDATE ! NERF MSC Stack Error: Recycling >> c:\opus\opus.log GOTO OPUS REM log error and rerun opus :OFFLINE OPUSDATE : NERF ** Sentry Taken Offline ** >> c:\opus\opus.log ECHO ON REM log system taken offline