Opus-CBCS

Opus-CBCS (Opus Computer Based Conversation System) is a bulletin board system (BBS) program that runs under MS-DOS. It was popular from the mid-1980s through the 1990s.

Overview

Opus was created by Wynn Wagner as a FidoNet-compatible BBS program, designed to be compatible with Fido (the program that originated FidoNet) so that sysops of existing Fido boards could easily switch to Opus and preserve all their content, configurations, and user records. Thus, the files used by Opus are almost entirely the same as those of Fido, though over time some of them diverged in later Opus versions (e.g., the conversion of file lists from flat text files to a database format).

Opus rapidly gained popularity by supporting everything Fido did, plus some enhanced features such as the use of color in menus (for users with terminal programs supporting one of several protocols that supported this), and some new and improved data transmission protocols which made more efficient use of modems.

Later on, though, it lost ground to other BBS software which had greater support for such things as online games and multi-user chatting. There was a long delay between the release of versions 1.20 and 1.70 (they skipped the version numbers in between) (or maybe the delay was before 1.20; the online history is a bit sketchy), with the only word on possible release dates being "When It's Ready", and many people switched away during that time, leaving a few hard-core Opus fans sticking with it.

Opus was one of the few FidoNet-capable boards that supported built-in network mail (and Echomail, the FidoNet answer to forums or newsgroups); other BBS software generally required an add-on front-end to support these features. Many Opus sysops, however, still used front-ends on their boards to do netmail/echomail, since those programs had more features in this area.

Opus has always been free software, with the author requesting that those who like it enough to want to pay for it send money to an AIDS research charity instead of to the author. Its creators (some others joined Wagner later in developing it) sometimes pointed out that it's not really "free"; it has a requirement that its users be "lawful and friendly", which they say can be more costly than mere money.

Opus has always tended to be a bit tongue-in-cheek, often aiming a spirit of frivolity at those elements of FidoNet that tended to get a bit over-serious at times. For instance, while a big political debate raged over whether to vest administrative control of FidoNet in an incorporated entity called the International FidoNet Association (IFNA), Opus introduced its own unincorporated, unorganized, leaderless group called the Worldwide Opus Consortium (WOC), encouraging sysops to use punnish references like "A WOC on the Wild Side" (which were often found in the tag-lines of BBSs inserted into echomail messages). Opus protocol elements had colorful names like "Wazoo" and "YooHoo/2U2". The FOSSIL protocol was also used (in common with many other FidoNet-related programs).

According to Wagner, Opus is not named after the cartoon penguin, but after the Latin word for "work". The plural of "opus" is "opera", but there is no apparent connection between Opus and the web browser Opera.

Control files

The standard control file is called BBS.CTL. Often it is split into multiple parts referenced in the main control file with "INCLUDE" statements; usually these parts have a .CTL extension as well. These files are ASCII-based, containing a series of configuration directives which are documented in the Opus sysop and technical manuals found in the file areas linked below. After modifying the control file, the sysop then needs to run a utility called NACL (from the chemical formula for table salt) to compile the control file into a file BBS.PRM which was used directly by Opus. Another utility CAYENNE makes the conversion in the opposite direction, generating a BBS.CTL file from the BBS.PRM file.

External file transfer protocols may create control files with a .CTL extension, and the hexadecimal task number of the Opus process invoking it as the last two characters of the filename before the dot.

USERNAME.TXT stores unacceptable user names and name portions which are rejected when a new user tries to register with them.

PASSWORD specifies passwords for barricaded areas.

SYSTEM.DEF was a system file used prior to Opus 1.70.

SYSTEM##.DAT (with numbers corresponding to area numbers) kept track of message and file areas prior to Opus 1.70.

SYSMSG.DAT and SYSFILE.DAT keep track of message and file areas respectively in Opus 1.70. They are created by NACL.

User file

USER.DAT is the user data file. In Opus 1.70, it is maintained using the OUFM utility.

USER.IDX is a user file index used prior to Opus 1.70.

USER.NDX is a user file index (B+tree based) used in Opus 1.70+. It is created with USERNDX and maintained with OUFM.

LASTUS##.DAT (with ## replaced with hexadecimal task number) temporarily holds the current user's user-file data when an external program is accessed (it is in the STATUS directory) so the other program has access to this data.

Format of user record:

2-byte word: User's baud rate (0 for local console login)

2-byte word: Current port number

2-byte word: Active task number

2-byte word: Minutes remaining

2-byte word: Message area user is in

2-byte word: File area user is in

Long: Unix time of latest time user is on until (in UTC)

MS-C time structure of above time (in local timezone)

25 character string: Last call date as ASCIIZ string

Menu, help, and other displayable text files

Menu files

The menus are generated from the system control file and compiled by NACL into .MNU files named by language, e.g., "ENGLISH.MNU". If there are area-specific menus they are saved with .001, .002, etc., extensions by the area number.

System and user prompts

Language-specific system and user prompts are compiled by NACL from the system control file into .SYL and .USL files named after the languages used, e.g., ENGLISH.SYL.

BBS/GBS files (OEC)

Various files with a .BBS extension are displayed in different situations. There can also be corresponding files with a .GBS extension which include ANSI graphic codes and are displayed in place of the .BBS files for users whose terminals support such codes. However, by the time of Opus 1.70, Avatar commands were supported in the .BBS file (converted automatically to ANSI when that is what the user supports, or stripped if no special codes are supported), so there really isn't much need for the .GBS files. Both .BBS and .GBS files can include any of a set of Opus Embedded Commands/Codes (OECs), many of which are composed of control characters. The Opus Technical Manual (in one of the file areas below) documents these commands. Some of them were later standardized as the AVATAR control codes for general BBS use (in competition with ANSI).

See article: Opus Embedded Commands

Some of these filenames (and the paths in which they are located) can be changed through lines in the configuration file.

AREAINFO.BBS, in a message-area directory, is displayed to the user when they enter the area, and can be used to describe the area, give rules for its use, etc.

BADNAME.BBS is displayed to a user who has tried to register with a username that is unacceptable according to the "blocked" usernames or username parts in USERNAME.TXT.

BAD_PWD.BBS is displayed when a user fails to type the correct password after five tries.

BARRICAD.BBS is displayed to a user attempting to get into a barricaded area.

BYEBYE.BBS is displayed to a user when they log off.

C.BBS is the help file for the C (Change) menu.

CONFHELP.BBS Shown to new users (in Opus 1.70) to ask them how to configure their accounts. Replaced SHADES.BBS.

CONTENTS.BBS is the help file for the archive contents command in a file area.

DAYLIMIT.BBS is the message shown when a user attempts to log in after exceeding their daily time limit.

DIR.BBS was used in older versions to identify a message/file area; obsolete as of version 1.70.

EDITOR.BBS is the help file for the line-oriented editor (LORE) shown to new users.

EDITHELP.BBS is the help file available from the LORE editor menu.

F1.BBS through F10.BBS is displayed/executed when the sysop presses the corresponding function key while a user is online. (If no user is online, the function keys cause a batch file from F1.BAT through F10.BAT to be executed instead.)

FILEAREA.BBS is displayed when user requests a listing of file areas.

FILEHELP.BBS is the help file for file areas.

FILES.BBS is an obsolete (as of version 1.70) listing of files in a file area.

HISTORY.BBS is the help file for the history menu.

INTERLIN.BBS is the help file for Interline chat.

INQUIRE.BBS is the help file for the Inquire command in message areas.

LEAVING.BBS is displayed/executed when user leaves BBS to enter an external "door" program.

LOCATE.BBS is the help file for the Locate command in file areas.

LOGO.BBS is displayed on initial connect before login. ASCII text only, limit 1K.

MACRO.BBS is displayed to users when they are creating macros. (Opus 1.70)

MAIN.BBS is the help file from the main menu.

MAKE.BBS is displayed when users start to make their own user-defined sections. (Opus 1.70)

MAYBENEW.BBS is displayed when Opus can't find a user name and is going to prompt to register as a new user.

MSG.BBS is the help file from the message menu.

MSGAREA.BBS is displayed when user requests a menu of message areas.

MYQUEST.BBS displays a question upon user login, and stores the answer in the user data file.

NEWUSER1.BBS is displayed to new users immediately after signup, before they choose their password.

NEWUSER2.BBS is displayed to new users after they choose their password.

OPED.BBS is the help file for the OpEd full screen editor.

QUOTES.BBS Quotable quotes used for OEC commands to embed quotes (in round-robin order) in text displayed to users.

REP_EDIT.BBS is displayed when the Edit command of the LORE (line oriented) editor is used, to explain how to edit a line.

RETURN.BBS is displayed on return from an outside DOS program (unless EXIT command is used).

ROOKIE.BBS is displayed on a user's 2nd and 3rd calls.

RULES.BBS (RULES~.BBS, with a language code in place of the ~, for multi-language systems) is found in message areas and causes the rules of that area to be displayed on the menu.

SHADES.BBS was used prior to Opus 1.70 to ask configuration questions of new users. It was replaced with CONFHELP.BBS in 1.70.

SPANN#.BBS (where # is a number from 1 to 5) is a special announcement file, displayed to users a number of times set up in the user data fiile.

SYSHELP.BBS is the help file displayed for the sysop in the !) menu.

TIMEWARN.BBS warns the user of an impending event that will limit their time online.

TOOSLOW.BBS is displayed to users with a baud rate too low to access the board according to its configuration.

WELCOME.BBS is shown immediately after login.

WHY_ANSI.BBS is the help file about ANSI graphics for new users (when they're asked if they support them).

WHY_FB.BBS is the help file for the logoff question asking if user wants to leave feedback.

WHY_HU.BBS is the help file for the logoff (hangup) confirmation question. (Note: To get off quickly from an Opus session, just type GYN; it has nothing to do with gynecology, but sends the commands Goodbye, Yes (to the are-you-sure question), and No (to the leave-feedback question).

WHY_IBM.BBS is the help file for the new-user IBM-PC-character support question.

WHY_LOG.BBS is the help file for the "register as new user" question (Opus 1.70).

WHY_OPED.BBS is the help file for the new-user OpEd editor question.

WHY_PVT.BBS is the help file for the private-message entry question.

WHY_SHAD.BBS was used prior to Opus 1.70 as the help file connected with SHADES.BBS.

XDATGONE.BBS is displayed when a user has reached their account expiration date.

XDATWARN.BBS is displayed when a user is nearing their expiration date (number of days is set in config file with EXPIRE DAYS option).

XFERBAUD.BBS is displayed when user's baud rate is too low to download a file as set in the configuration.

XTIMGONE.BBS is displayed when a user's session time has ended.

XTIMWARN.BBS is displayed when a user is nearing their session time (within number of minutes set in config file under EXPIRE MINUTES option).

YELL.BBS is displayed to a user who tries the Yell command but it is disabled or the sysop does not answer.

#.BBS, where # is a (multi-digit) number, is a special welcome file for the user whose user number is the filename, displayed to them on login.

Message files

Continuing the structure used in the Fido BBS, message areas are stored in one directory per area, with each message in a separate file named with the .MSG extension and a name that represents the number of the message within the area (e.g., 123.MSG for message #123). There were some utilities for renumbering message areas when some of the messages in an area were deleted, since gaps in the numbering would slow down access.

A message file consisted of a 190-byte binary header followed by the plain text of the message body. There was no way of indicating Character Encoding, but messages were generally in ASCII; perhaps non-ASCII characters from an IBM PC code page might be encountered, but such use wouldn't be reliable since BBS users might be using non-PC systems or PCs with different internationalized code pages. Lines starting with Ctrl-A (01) were control lines, e.g. with routing information used in FidoNet transfer, and were intended not to be displayed in normal BBS use.

Mesage header

The binary header is similar to the one used in FidoNet message packets, but not exactly the same.

It consists of elements in this order:

36 bytes containing the 'from' name (null-terminated string). In this and other null-terminated strings, the bytes after the null character might contain arbitrary content, perhaps left over from other data used by programs processing the message; this was ignored.

36 bytes containing the 'to' name (null-terminated string).

72 bytes containing the subject line (null-terminated string).

20 bytes containing the date/time of the message in a human-readable ASCII string. In an Opus source-code header file (found in one of the file sets linked below), this is indicated as "obsolete/unused", but it still seems to have a correct date string in it (at least in some versions of Opus).

2-byte unsigned integer (word) containing the number of times the message has been read. (Words/integers are little-endian.)

2-byte integer with the destination node number (the 'node' part of a FidoNet address of the form zone:net/node.point).

2-byte integer with the origination node number.

2-byte word with unit cost (in cents) charged to send the message (intended for boards that required accounts with balances, whether paid with real money or 'funny money', to send messages; remember, in those days there were real long-distance phone costs involved in sending remote messages).

2-byte integer with the origination network number (the 'net' part of the FidoNet address). Note that the nodes are stored destination first then origination while the nets were quirkily in the opposite order.

2-byte integer with the destination network number.

The next 4 bytes consist of the timestamp of when the message was written, used by Opus in place of the ASCII timestamp above. In Fido, these bytes were unused and were set to null (00). Now, the format of this gets a bit tangled. The header file has a comment claiming them to be a Unix timestamp, but it isn't; the same header proceeds to define the format instead as two words representing the date and time in turn. No indication is given about how these date/time words translate to actual dates and times, but some detective work on sample files reveals that they are segmented bitwise as follows:

The first 2 bytes (date) are taken as a little-endian unsigned integer, then its bits are grouped starting with the highest-order bit (which, given the little-endian format, is actually in the second byte):

First 7 bits represent the year minus 1980, so that 1980=0, 1981=1, and so on. This will work for years up to 2107.

Next 4 bits represent the month (1=Jan...12=Dec)

Final 5 bits represent the day (1-31)

The last 2 bytes (time) are grouped like this:

First 5 bits represent the hour (0-23)

Next 6 bits represent the minute (0-59; or perhaps 60 during a leap second?)

Final 5 bits represent the second divided by 2 (as a rounded integer) (0-30)

The next 4 bytes contain the timestamp of when the message arrived online, in the same format as above.

The next 2 bytes are a word containing the message number this one is a reply to.

The next 2 bytes are a word with attribute flags. Starting with the low-order bit:

Bit 0: Private

Bit 1: Crash / Squirtmail

Bit 2: Received

Bit 3: Sent

Bit 4: File Attached

Bit 5: In Transit

Bit 6: Orphan

Bit 7: Kill when sent

Bit 8: Local

Bit 9: Hold for pickup

Bit 10: unused

Bit 11: File Request

Bit 12: Return Receipt Request

Bit 13: Is Return Receipt

Bit 14: Audit Request

Bit 15: File Update Request

The final 2 bytes are the number of the next message in the thread.

Other files in message area

AREAINFO.BBS, in a message-area directory, is displayed to the user when they enter the area, and can be used to describe the area, give rules for its use, etc. AREAINF~.BBS (with ~ replaced with a hex digit representing a language) is used in multi-language systems.

RULES.BBS (RULES~.BBS, with a language code in place of the ~, for multi-language systems) is found in message areas and causes the rules of that area to be displayed on the menu.

KILLDUPE.DAT is duplicate-message information in an Echomail area.

LASTREAD is created in each area when the sysop uses an external message editor, to keep track of the last-read pointer.

MSGTMP.MSG is a temporary file created when an external message editor is used.

MSGNAME.DAT was used prior to Opus 1.70 to hold the name of a message area.

LREAD.DAT tracks last-read messages of users in Opus 1.70+.

ORIGIN was used prior to Opus 1.70 to track the origin of a message area.

File areas

DIR.BBS was used in older versions to identify a message/file area; obsolete as of version 1.70.

FILES.BBS is an obsolete (as of version 1.70) listing of files in a file area.

FILESBBS.ADX, FILESBBS.DAT, and FILESBBS.NDX are the files making up the file area database in versions 1.70 and later, created using CONFILE and maintained with OFARE and OPUS-FAM.

ABOUT_ME.TXT is sent to remote systems doing file requests for a file that is not found, or when they request this filename specifically; it is a standard name for a file giving a brief description of the system.

FILELIST.* (where extension represents the compression type used, e.g., ARC or ZIP) is a file listing (in text, after decompression) the files available for file-request from remote systems.

FILENAME.DAT, prior to version 1.70, specified the file area name; this was changed to an entry in the configuration file.

NAME.FDX, NAME.MDX, NUMBER.FDX, and NUMBER.MDX are (in Opus 1.70+) the database files storing file area names and numbers, created by NACL.

LFILE.DAT (Opus 1.70+) holds the date a file area was last accessed. Stored in the file area.

Network transfers

NODELIST.DAT and NODELIST.IDX are compiled Version 6 FidoNet nodelists, and FIDOUSER.LST is a sysop list used for looking up names.

NODEX.DAT, NODEX.NDX (?), and SYSOP.NDX are the Version 7 versions, with SYSOP.NDX being the equivalent of the older FIDOUSER.LST.

*.OUT, *.CUT, *.DUT, *.HUT, *.CRT, *.DRT, *.HRT, *.ORT are outbound mail packets. .OUT is the normal type, and the others indicate special characteristics: the R in the middle letter indicates there is a file request in the packet (requesting the sending of a remote file); C as the first letter means to send it now regardless of cost (instead of waiting for a lower rate later); D means to send it directly to the destination without routing; and H means to hold for pickup.

*.$$N, BAD_BNDL.*, BAD*.*, BADWAZOO.*, OPUSXFER.*, *.TMP, and *.Z are filenames used to store invalid, aborted, or failed network transfers.

INMAIL*.* files are temporary files used while network mail is being processed.

UUCPLIST.TXT has UUCP hosts and network addresses.

ECHO.CTL was used in older Opus versions for controlling echomail areas (obsolete in 1.70).

AREAS.BBS is a global configuration giving the path and name of the Echomail areas (probably also obsolete with 1.70). The first line has a name/tagline of your BBS, and the remaining lines consist of the file path of an area (e.g., d:\message\meadow), then a space and the Echomail area name (e.g., MEADOW), then another space and the net/node number of the system messages are sent to in order to propagate the Echomail.

ECHO.MDX is an index used in Opus 1.70 for echomail areas.

ECHOTOSS.LOG is created by Opus to signal that a message has been entered by a user in an echomail area; it is used by the mail scanner.

OKFILE.LST is a list of requestable files and remote-executable procedures.

Log files

Activity on the BBS is logged to a file with a name/path set by the control file, usually OPUS.LOG. Sample format:

Regular user call, with downloads:

+ 25 Nov 22:26:59 OPUS Begin, 911125  v1.71, Task=1
+ 25 Nov 22:33:06 OPUS John Doe calling
= 25 Nov 22:37:51 OPUS DL-Z 14 C:\FILE\GRAPHICS\ONEBULA.GIF 140288
! 25 Nov 22:38:09 OPUS Z-InitErr: Can
= 25 Nov 22:38:50 OPUS DL-X 14 C:\FILE\GRAPHICS\ONEBULA.GIF 140288
= 25 Nov 22:49:57 OPUS DL-S 14 C:\FILE\GRAPHICS\SATURN.GIF 130048
+ 25 Nov 22:54:44 OPUS John Doe off-line. Calls=23, Len=21 Today=21

FidoNet mail call from another system:

* 25 Nov 22:10:38 OPUS Some BBS (333) 555-9999 Somewhere, USA 12345 (1:234/56.0)
* 25 Nov 22:10:43 OPUS Received: diddleysquat
= 25 Nov 22:10:51 OPUS DL-Z C:\Opus\Outbound\0117ff47.SA1 3871
= 25 Nov 22:11:03 OPUS DL-Z C:\Opus\Outbound\0117ff47.SU1 17156
* 25 Nov 22:11:04 OPUS Connect: 0:22 (1:234/56.0)

External file transfer protocols may create log files with a .LOG extension, and the hexadecimal task number of the Opus process invoking it as the last two characters of the filename before the dot.

DOWN.LOG optionally logs all user downloads.

UP.LOG optionally logs all user uploads.

Event scheduler

SCHED.DAT is the event schedule file used to schedule events and behavior windows for Opus. It is created and maintained by a utility called OEVENT.

Other files

Traditionally, the batch file to invoke Opus is named NERF.BAT, apparently the result of an inside joke to do with the bats used on Nerf balls.

ACTIVE##.DAT, with ## replaced with the two-digit hexadecimal task number of the currently-running Opus task, is a zero-length file that is created as a flag indicating that a user is online or the sysop is logged in at the console for that Opus task.

MAILBAT.BAT is created by Opus 1.70 to launch an external mailer.

NULL.DMP is written during a system crash to help in debugging by the developers. ("No sysop serviceable parts inside.")

CHAT##. (where ## is a number) stores inter-line chat text for multiline BBSs until they are read. The number is the line number the message is going to.

COMMON.DAT stores total callers and quote file pointer for multi-line systems.

See also

• Opus Embedded Commands
• AVATAR

Sample files

• Sample message file

Software and documentation

• Opus 1.73 files
• Opus 1.79 files
• Various Opus files

Other links and references

• History of Opus-CBCS
• Wikipedia article
• Fundamentals of FOSSIL implementation and use