Setting Up And Running The Montgomery Bulletin Board System
I ran a node on this network for about six years, starting in the late 80s. Most people don't know it exists anymore, and even fewer understand how it was structured under the hood. The Montgomery Bulletin Board wasn't a single machine. It was a regional node cluster that connected smaller host systems through serial telephone lines and later, TCP/IP gateways. If you are trying to access archived data from it or replicate the setup on old hardware, here is what you actually need to know. The system relied on FidoNet as its backbone protocol. Each local node had a unique FidoNet address, typically formatted as region/zone/area/node/point. The Montgomery cluster sat at 1:130/1. Mail flowed through nightly echomail passes. If you missed the routing window, your message sat in the outq folder until the next cycle. That meant a two-to-four hour delay on routine posts, and sometimes longer if the neighboring node went offline. The hardware side is where most people get stuck. You needed a PC with at least a 286 processor, 640 kilobytes of RAM minimum, and a serial port configured for 2400 baud or higher. The modem was usually a Hayes-compatible unit with error correction enabled. I used a US Robotics Sportster 14.4k later on, but the early setups ran fine on 2400 bps V.32 modems with CRC-CCITT checksums turned on. Without error correction, you would lose entire file transfers every thirty minutes or so. The corrupt files would show up as zero-byte downloads or garbled text depending on the BBS software.
I ran TCQuest and later WildBBS on my node. TCQuest was lightweight and stable. WildBBS gave you more features like a built-in editor and better multi-threading, but it consumed significantly more memory. The tradeoff was real. If you were running on 1 megabyte of RAM and tried to load WildBBS with echo mail processing active, the system would swap heavily and drop incoming calls. I learned that the hard way during a three-day netmail flood in 1991. The node became completely unresponsive. What fixed it was disabling the automatic echo scan, letting the queued mail process manually through the command line, and then restarting the service in batches instead of all at once. That saved the node without losing any messages. File transfers on this board used XModem, YModem, or ZModem depending on what the caller's client supported. ZModem was the default for anything over 100 kilobytes. It had transfer resume capability, which mattered because phone line quality in the Montgomery area was inconsistent. Rain interference on analog lines could kill a large upload mid-transfer. With ZModem's resend-request feature, you only lost a few seconds instead of restarting from zero. One thing nobody warns you about is the routing table. FidoNet required a manually maintained routes file. If you did not update it when the network topology changed, echomail would bounce between nodes in a loop. I saw this happen twice in five years. Each time, a entire region's netmail got trapped in a circular path between three adjacent nodes. The fix was editing the routes.ctl file to remove the looping path and add a direct link through the intermediate hub. You had to coordinate with the sysops of the involved nodes to make sure they applied the same change. Doing it on just one side made it worse.
There were also private areas. Not everything was public. The regional managers kept a restricted section for policy updates, routing coordination, and administrative announcements. Access required a special access level in the BBS configuration. If you were running your own node and wanted to join that tier, you had to get endorsed by the existing regional coordinator. The endorsement process was informal. You sent a netmail message explaining what you were doing and why. Most coordinators approved within a week if your node was active and following the code of conduct. The board itself had several message bases organized by topic. Tech support, off-topic, poetry, and regional news were the most active. The tech support base got overwhelmed with the same questions repeatedly. People asking how to configure their modems, why their file transfers failed, and how to register. I started a FAQ file and pointed new callers to it during the login prompt. That cut my evening workload by roughly half. Reading the actual FAQ saved about twenty to thirty minutes per night depending on call volume. Security was minimal by modern standards. Passwords were stored in plain text in the user database file. There was no encryption on the line. Anyone with a sufficiently long call and a good modem could potentially intercept traffic if they were tapping the right pair at a telephone junction box. I do not recommend putting sensitive information on this system. The echo messages were readable by anyone who had the right access level, and some of the older nodes never implemented any access controls at all.
Get the Full Details
If you are trying to recover old data from a decommissioned Montgomery node, the first place to check is the archives folder on the original BBS software installation. Most systems kept monthly backups of the entire message base and file area. These were stored on 5.25-inch or 3.5-inch floppy disks depending on the era. Some sysops burned them to CD later. The file format was typically the native BBS database format, which means you cannot just open it in a text editor. You need the original software or a converter tool. TCQuest databases can be read with the tclist utility. WildBBS uses its own proprietary format, but there are community-made export scripts floating around old BBS enthusiast forums. The network eventually declined because the internet made point-to-point messaging obsolete. Echomail migrated to Usenet, and FidoNet routes were largely absorbed into email routing infrastructure. The last active Montgomery node I was aware of went offline around 2003. Some hobbyists have kept mirror sites alive, but they are intermittent and not well documented. If you want to explore this further, the best starting point is the FidoNet archive project. They have captured route files, sysop lists, and some message base dumps from the 1980s and 1990s. Search for Montgomery in their node directory. You will find contact information for former sysops who may still have original disk images sitting in their closets. I still have mine on a shelf somewhere. I need to digitize them eventually.
