synchro.net

home *** CD-ROM | disk | FTP | other *** search

/ synchro.net / synchro.net.tar / synchro.net / modem.madness / SMMNETML / PHV090.ZIP / PHOENIX.DOC < prev next >

Wrap

Text File | 1992-07-22 | 271.7 KB | 6,447 lines

▐▀▀▀▀▀▌ ▐▀▌ ▐▀▌ ▐▀▀▀▀▀▀▌ ▐▀▀▀▀▀▌ ▐▀▀▀▌ ▐▀▌ ▐▀▀▀▌ ▐▀▌ ▐▀▌ ▐ ▄▄▄ ▌ ▐ ▌ ▐ ▌ ▐ ▄▄▄▄ ▌ ▐ ▄▄▄▄▌ ▐ ▀▌ ▐ ▌ ▐▄ ▄▌ ▐▄▀▌▐▀▄▌ ▐ ▀▀▀ ▌ ▐ ▀▀▀ ▌ ▐ ▌ ▐ ▌ ▐ ▀▀▌ ▐ █▄ ▀▌▐ ▌ ▐ ▌ ▐▄▀▀▄▌ ▐ ▄▄▄▄▌ ▐ ▄▄▄ ▌ ▐ ▌ ▐ ▌ ▐ ▄▄▌ ▐ ▌▐▄ ▀█ ▌ ▐ ▌ ▐▀▄▄▀▌ ▐ ▌ ▐ ▌ ▐ ▌ ▐ ▀▀▀▀ ▌ ▐ ▀▀▀▀▌ ▐ ▌ ▐▄ ▌ ▐▀ ▀▌ ▐▀▄▌▐▄▀▌ ▐▄▌ ▐▄▌ ▐▄▌ ▐▄▄▄▄▄▄▌ ▐▄▄▄▄▄▌ ▐▄▌ ▐▄▄▄▌ ▐▄▄▄▌ ▐▄▌ ▐▄▌ v1.00 Copyright 1992 (c) International TeleCommunications All Rights Reserved BBS Phone No. 1 (314) 334-6359 Table of Contents i Copyright ................................................. Page 1 -- Demo Distribution Policy -- ............................ Page 1 Hardware Requirements ..................................... Page 1 License ................................................... Page 2 Tcp/Pc .................................................... Page 3 Introduction .............................................. Page 4 Addressing ................................................ Page 4 Reducing The Size Of The Nodelist ...................... Page 6 Is Tcp/Pc And Fidonet Compatible? ...................... Page 7 Multiple Domain Addresses .............................. Page 8 By Passing Levels ...................................... Page 8 Installation .............................................. Page 8 Creating Required Data Files ........................... Page 8 Phoenix.cmd ......................................... Page 8 Figure 1-A ....................................... Page 9 Your Name ........................................ Page 9 Mailer/Bbs Name .................................. Page 9 Primary Domain ................................... Page 10 Alternate Domain ................................. Page 10 Inbound Path ..................................... Page 10 Matrix Path ...................................... Page 10 Requested Files .................................. Page 10 Route Mode ....................................... Page 10 Node Number ...................................... Page 11 Implied Routing .................................. Page 11 Maximum Busy ..................................... Page 11 Secure Echomail .................................. Page 11 Maximum Calls .................................... Page 12 Desqview ......................................... Page 12 Secure Address ................................... Page 12 Outbound Calls ................................ Page 12 Inbound Calls ................................. Page 13 Time Between Dials ............................... Page 13 Carrier In Delay ................................. Page 13 Carrier Out Delay ................................ Page 13 Shell Instructions ............................... Page 14 Flow Control ..................................... Page 15 Off Hook ......................................... Page 15 Serial Port ...................................... Page 16 Lock Rate ........................................ Page 16 Fifo Size ........................................ Page 16 Maximum Baud ..................................... Page 16 Minimum Baud ..................................... Page 17 Figure 2-A ....................................... Page 17 Modem Answer ..................................... Page 18 Modem Dial ....................................... Page 18 Modem Out ........................................ Page 18 Modem In ......................................... Page 18 Modem Connect Messages And Baud Rates ............ Page 18 Fkey.dat ............................................ Page 19 Figure 4-A ....................................... Page 20 Magic ............................................... Page 20 Figure 3-A ....................................... Page 21 Summary ............................................. Page 22 Table of Contents ii Nodelist.dat And Domain.idx ......................... Page 22 Ned .............................................. Page 22 Makenl ........................................... Page 23 Network Nodelist .............................. Page 23 Merging Multiple Nodelists .................... Page 25 Personal Custom Nodelist ...................... Page 26 Including Static Data ......................... Page 30 Hash Tables ................................... Page 32 Other Files ................................... Page 33 Phone.ctl ........................................... Page 34 Summary ................................................ Page 34 Phoenix Command Keys ...................................... Page 35 Phoenix Related Keys ................................... Page 35 Esc ................................................. Page 35 Enter ............................................... Page 35 ? ................................................... Page 35 B ................................................... Page 35 Alt-M ............................................... Page 35 [Q]uit ........................................... Page 36 [S]end ........................................... Page 36 [C]rash .......................................... Page 36 [K]ill ........................................... Page 36 [R]oute .......................................... Page 37 Alt-E ............................................... Page 37 Alt-T ............................................... Page 37 Alt-B ............................................... Page 37 Alt-N ............................................... Page 37 Alt-R ............................................... Page 37 Alt-D ............................................... Page 37 Alt-F ............................................... Page 37 Alt-P ............................................... Page 37 Alt-C ............................................... Page 37 Alt-H ............................................... Page 37 Alt-W ............................................... Page 37 Alt-S ............................................... Page 37 Osiris Related Functions ............................... Page 38 Ctrl-O .............................................. Page 38 Ctrl-T .............................................. Page 38 Ctrl-E .............................................. Page 38 Ctrl-L .............................................. Page 38 Ctrl-F .............................................. Page 38 Ctrl-U .............................................. Page 38 Ctrl-S .............................................. Page 38 Routing Principles And Architecture ....................... Page 39 Types Of Routing ....................................... Page 39 Implied Routing ..................................... Page 39 Explicit Routing .................................... Page 39 How Implied Routing Works .............................. Page 40 Common Questions Concerning Routing ................. Page 41 What About Crash? ...................................... Page 43 Implied Routing Limited ................................ Page 43 Implied Routing Disabled ............................... Page 43 Table of Contents iii Explicit Routing ....................................... Page 43 Forward For {Wild-Domain Address} ................... Page 45 No Route {Verb} ..................................... Page 45 Send To {Wild-Domain Address} ....................... Page 46 Route {Wild-Domain Address} To {Domain Address} ..... Page 47 Hold {Verb} ......................................... Page 47 Forward File {Wild-Domain Address} .................. Page 47 Dial Delay {Seconds} ................................ Page 48 Busy Attempts {Number} .............................. Page 48 Maximum Connects {Number} ........................... Page 48 Poll {Domain Address} ............................... Page 48 Gate {Gateid} To {Domain Address} ................... Page 49 Examples #1 ............................................ Page 49 Example #2. ............................................ Page 50 Example #3 ............................................. Page 50 Common Mistake #1 ...................................... Page 51 Common Mistake #2 ...................................... Page 51 Tips On Speed .......................................... Page 51 Events .................................................... Page 52 Figure 7-A ............................................. Page 53 Event Lable ............................................ Page 53 Starting Time .......................................... Page 53 Ending Time ............................................ Page 54 Execute On ............................................. Page 54 Dynamic ................................................ Page 54 Warnings ............................................ Page 54 Explicit Route Ctrl File ............................... Page 55 Exit Errorlevel ........................................ Page 56 Event Batch ............................................ Page 56 Exit On Inbound Errorlevel ............................. Page 56 Bbs Allowed ............................................ Page 56 Do Pick-Up ............................................. Page 56 Maximum Request Per Session ............................ Page 57 Summary ................................................ Page 57 Request.ctl And File Requests ............................. Page 58 Password Protection .................................... Page 58 Update Requests ........................................ Page 58 Echomail.bat .............................................. Page 58 Mail Transfer Protocols ................................... Page 59 Xmodem/Modem7 .......................................... Page 59 Diet Infa .............................................. Page 59 Sealink ................................................ Page 59 Notes On Sealink .................................... Page 60 Wazoo .................................................. Page 60 Important!, Wazoo And Session Level Passwords ....... Page 61 Highspeed Mail Session ................................. Page 61 Translink ........................................... Page 62 Restart Recovery ................................. Page 62 Errors During A Transfer ......................... Page 62 How Does This Help Me? .............................. Page 63 Emsc ................................................... Page 64 Matrix Editor ............................................. Page 65 Message Movement Keys .................................. Page 65 Movement Keys, Viewing Message ......................... Page 66 Table of Contents iv Command Keys ........................................... Page 66 E - Enter Message ................................... Page 66 R - Reply To Current Message ........................ Page 68 K - Kill Current Message ............................ Page 68 L - Look-Up Address ................................. Page 68 (S)ysop Name ..................................... Page 69 (B)bs Name ....................................... Page 69 (P)attern Search ................................. Page 70 F - Forward ......................................... Page 70 C - Carbons ......................................... Page 70 V - Validate Authenticity Signature ................. Page 71 A - Edit Current Message ............................ Page 71 Dc Word(tm) ............................................ Page 71 Command Keys ........................................ Page 73 Mouse Menu ............................................. Page 77 Cut .................................................... Page 77 Paste .................................................. Page 78 Quick Jump ............................................. Page 78 Macro Keys ............................................. Page 78 Service Requests .......................................... Page 80 Programmers Notes ...................................... Page 81 Nodelist Editor ........................................... Page 82 Add .................................................... Page 83 Find ................................................... Page 83 Log File .................................................. Page 84 Errorlevels & Error Msgs .................................. Page 84 Human Callers ............................................. Page 86 Smart(tm) Packer .......................................... Page 87 Maximum Number Of Outbound Messages .................... Page 88 Alternate Domains ......................................... Page 88 Methods Of Handling Legitimate Multiple Domains ........ Page 89 Internet Address .................................... Page 89 Alternate Domain .................................... Page 90 How To Pickup Mail When Multiple Domains Are Involved .. Page 90 Busy The Modem ............................................ Page 91 Auto Detecting Osiris Bbs Software ........................ Page 92 Testing Your Setup ........................................ Page 92 Aborting .................................................. Page 93 Tic ....................................................... Page 93 Raid ...................................................... Page 93 Areafix ................................................... Page 94 Afix.bat, Tic.bat, Raid.bat, Echomail.bat .............. Page 94 .Msg Storage Format ....................................... Page 94 Comport.dat ............................................... Page 95 Figure 5-A ............................................. Page 95 Fossil .................................................... Page 96 Advanced Operations ....................................... Page 96 Nomail ................................................. Page 96 Recycle.xxx ............................................ Page 96 Sysdown.xxx ............................................ Page 97 Special Phoenix Flag Settings .......................... Page 97 Table of Contents v Netcom.exe ............................................. Page 98 Wait <Node #> ....................................... Page 98 Shutdown <Node #> ................................... Page 98 Recycle <Node #> .................................... Page 98 Free <Node #> ....................................... Page 98 Nomail <Node #> ..................................... Page 98 Copy <Node #> ....................................... Page 99 Move ................................................ Page 99 Netcom.cfg .......................................... Page 99 Netcom2.cfg ......................................... Page 99 Screen Blanker ............................................ Page 104 Consea.exe ................................................ Page 104 Robot ..................................................... Page 105 Getting A Test Drive Key .................................. Page 106 Test Drive Mode ........................................ Page 106 Bbs Front End Mode ..................................... Page 108 Price ..................................................... Page 108 Technical Support ......................................... Page 108 File Structures ........................................... Page 109 Matrix Message Header .................................. Page 109 Phoenix.cmd ............................................ Page 112 Phoenix Technical Reference Manual Page 1 Copyright Despite the method of marketing, Phoenix is not in the public domain nor is it SHAREWARE. Phoenix is a proprietary product of International TeleCommunications, protected under U.S. copyright law, International treaty provisions, and trade secret laws of general applicability. Copying, duplicating, selling or otherwise distributing this product, except as expressly permitted in the DEMO Distribution Policy is a violation of the Law. You are, however, granted the right, in fact encourage, to make and distribute copies of the DEMO version, with the following provisions. -- Demo Distribution Policy -- 1. Feel free to distribute the DEMO version as often as you like. 2. Please do not distribute the program without all of its original files. 3. You must get written permission before distributing Phoenix with any "Bundled" software packages. 4. You may NOT accept payment for the program. A copying fee of 10.00 per diskette may be charged when distributed by a non-profit user-group. 5. You may NOT alter the program or documentation in any way. 6. Individuals, groups, vendors, or other software distribution companies who market diskettes containing the DEMO or SHAREWARE programs for profit must NOTIFY us, in writing, 30 days before distribution. Hardware Requirements The following list represents the minimum configuration your system should have to maximize the potential of the program. - IBM Personal Computer (or true compatible) with 384K (minimum) RAM, 256K free for Phoenix. I suggest, although it is NOT required, 512K of AST EEMS 3.20 or LIM 4.00 RAM - PC-DOS or MS-DOS, Ver. 3.0 or later. - A Hard Disk Drive is recommended but you can use a 1.2 Meg Floppy Disk. - Asynchronous communications (serial port) adapter - RS-232 cable with the standard nine pins connected (some modem cables do not have all the pins hooked-up). Phoenix Technical Reference Manual Page 2 - Intelligent AT command set modem - Eighty column color monitor. A monochromatic monitor may be used but given the difference between manufacture, you may experience problems with screens being hard to read. - Voice-grade telephone connection for modem License 1. License Grant. International TeleCommunications grants, when registered, to you a non-exclusive license to use one copy of Phoenix on a single computer or on a single terminal connect to a single computer. Neither concurrent use on two or more computers nor use in a local area network is authorized without advanced written consent of International TeleCommunications and the payment of additional license fees. 2. International TeleCommunications' Rights. You acknowledge and agree that Phoenix is a proprietary product of International TeleCommunications, protected under U.S copyright law, international treaty provisions, and trade secret laws of general applicability. You further acknowledge and agree that all rights, title, and interest in and to Phoenix are and shall remain with International TeleCommunications. 3. Other Restrictions. You may not lease or rent Phoenix. You may not disassemble, decompile, or reverse engineer Phoenix. 4. Phoenix is licensed "AS IS," and International TeleCommunications disclaims any and all warranties, whether express or implied, including (without limitation) any implied warranties of merchantability or fitness for a particular purpose. 5. Limitation of Liability. International TeleCommunications' cumulative liability to you or any other party for any loss or damage resulting from any claims, demands, or actions arising out of or relating to this agreement shall not exceed the license fee paid to International TeleCommunications for the use of Phoenix. In no event shall International TeleCommunications be liable for any indirect, incidental, consequential, special, or exemplary damages or lost profits, even if International TeleCommunications has been advised of the possibility of such damages. Some states do not allow the limitation or exclusion of liability for incidental or consequential damages, so the above limitation or exclusion may not apply to you. Phoenix Technical Reference Manual Page 3 6. Governing Law. This license agreement shall be construed and governed in accordance with the laws of the State of Missouri. 7. Severability. Shall any term of this license agreement be declared void or unenforceable by any court of competent jurisdiction, such declaration shall have no effect on the remaining terms hereof. International TeleCommunications 555 North Spring, Suite 39 Cape Girardeau, Missouri USA 63701 Tcp/Pc InterNetwork Specifications For Personal Computers Data communication has become a fundamental part of computing. World wide networks gather information about a wide range of topics. Groups establish networks so they can exchange information of common interest. Unfortunately, most networks are independent entities, established to serve the needs of a single group. The users choose a hardware technology appropriate to their communication problems. More importantly it is impossible to build a universal network from a single hardware technology because no single network suffices for all uses. Fidonet technology was the first attempt to create a universal network protocol for PC's. The design was good, the first implementations were good, but it is falling apart because the specifications were not that well documented, although this documentation has improved. But the biggest problem is: Specifications aren't ENFORCED. Many of Fidonets original specifications are still important and relative. One of the specifications that become outdated is the addressing format. The original designer cannot be faulted with this. No one dreamed this thing would take on the scope that it has. However, Fidonet can be blamed for failing to adapt to the changing environment. The TCP/PC specifications were derived from the TCP/IP specifications for internetworking. The TCP/IP specifications were changed in areas when that implementation was not feasible for Personal Computes networked over standard phone lines. Phoenix Technical Reference Manual Page 4 TCP/IP is known by another name, Internet. In 1990, there were over 190,000 LISTED systems in Internet. It has been estimated that there are over 300,000 TOTAL systems linked into Internet. You might also be surprised to know that if you have Novell, 3com, Lantastic, or one of the other LANS you are already using Internet protocols and just didn't know it. Throughout this document, Internet will reference the TCP/IP specifications. Introduction Phoenix was designed to: 1) Be physically small and to consume as little memory and disk space as possible. 2) Be exceptional FAST in respects to mail sessions and file transfers. 3) EASY to set-up and use. 4) Have a very Sophisticated and Intellegent IMPLIED routine manager. 5) Have a very flexible and easy to use EXPLICIT routing system. 6) Intelligently handle multiple domains without operator intervention. Phoenix was NOT designed to be or do everything for everyone. Addressing Before you can INSTALL Phoenix, you have to understand the ADDRESSING system Phoenix uses. Internet uses an addressing system based on NET and HOST. Those of you that have had experience in Fidonet will notice this is similar to the Fidonet NET and Node concept. In fact they are almost identical and for the rest of this document, NET will mean the same as the Fidonet NET number. HOST will mean the same thing as the Fidonet Node number. The reason we want to use HOST rather than NODE will be explained later. Phoenix Technical Reference Manual Page 5 Fidonet uses a 16 bit unsigned integers, an integer is a non- decimal number, for the NET and a 16 bit integer for the HOST. This number can hold values ranging from 0 to 65535. Internet uses 4 different classes of NET and HOST numbers. The class differs based on the number of HOST systems within the NET. The mechanics of how this works is not important, but is fascinating if you are a programmer. An Internet address takes the form of 123.12.12.21, a period is used to break the NET and HOST into 4 8 bit chunks. This is an address that is used on the Software/Hardware level. The PERSON entering the address would not enter it in this format. They would enter something like Jones@beta.GOV and the software would translate that to the Internet address. Jones@beta.GOV is a label. It is easier to associate a person's address to a label than the Internet address. When you enter a message to Jones@beta.GOV, the software translates that label to an Internet address. You don't see or even know the translation is going on. Personal Computers generally don't have the disk space to store the information required to resolve large numbers of LABELS. That is one of the reasons most Fidonet mail programs require you to enter the NET and HOST numbers instead of a label. Internet does suffer from one major flaw. It doesn't allow for individual machine addresses. Since all the machines in Internet are hooked together in network fashion, the addressing system doesn't need to go that low. A Fidonet address is based on individual machines and the HOST number references a single machine. Although the Fidonet format does provide for a large number of systems, every HOST must keep a very large list, commonly referred to as a nodelist, of NETS. If Fidonet were to grow to the maximum number of NETS, each HOST would have to keep a minimum of 65535 entries in their nodelists. Another problem, Fidonets addressing method doesn't provide for the possibility that other, totally different, NETWORKS exist. Example: Fidonet, a GROUP of NETS bound together to format a Network of individual systems, cannot co-exist with Family Net, another Network of individual systems. Since both networks use the same NET/HOST addressing system, 100.10 in Fidonet would conflict with 100.10 in Family Net. Phoenix Technical Reference Manual Page 6 Those developing mailers for use within Fidonet have, in recent years, attempted to find ways around this by kludging the use of ZONE. E.g., ZONE.NET.HOST However, Fidonet has never OFFICIALLY adopted the use of ZONE as part of an address. They use it in their NODELIST and offer an OPTIONAL, if it is optional it might as well not be there, mail packet header that has this field, but it is not part of the official specifications. Several NETWORKS use the ZONE field to co-exist. Some within Fidonets frown on that concept and believe a ZONE should only be used to separate geographic regions. Whether it is used to separate systems by geographic location or by Network location isn't important, in fact it is just a matter of semantics. The results are identical, the ZONE number provides a GATEWAY to other geographic locations or to other NETWORKS. For the remainder of this document; GATE, GATEWAY, GATEid, and ZONE are interchangeable and reference a GATEWAY for interchanging messages between different Geographic locations or Networks. It also references the top most level in any network. Reducing The Size Of The Nodelist The only way you can reduce the size of the nodelist is to reduce the number of REQUIRED entries. One of the ways to do that is to divide the HOSTid and produce a USERid. We now have the format of; GATEid.NETid.HOSTid.USERid and this is the format TCP/PC and Phoenix uses. The entire address is called a DOMAIN, each section of the DOMAIN address is called a subdomain. The period is used to divide the different subdomains. If you are use to seeing 1:245/405.0, : / and . are not actual part of the address. They are used to divide the subdomains. It is really up to the software you're using. Phoenix follows the TCP/IP method of using the period. Do NOT forget this. ANYTIME ANY Phoenix application, Mailer/Editor/Nodelist Editor/Etc., asks for a Domain address it expects you to use a PERIOD to divide the subdomains. Phoenix Technical Reference Manual Page 7 What about @, doesn't internet use that? It does, but that references a particular PERSON on a machine. Since you are the only one using the mailer, there is no need to use that subdomain separator. The GATEid.NETid.HOSTid.USERid addressing system also means you're never likely to run out of unique address. There are so many unique addresses available, you could assign every man, women, and child on the face of this planet an address and have plenty left over. To top it off, we now have an addressing method that supports the concept that no individual systems needs to keep EVERYONE listed in their nodelist. They only HAVE to keep the system directly above them and directly below them. Again, those developing mailers for use within Fidonet have, in recent years, attempted to find ways around this same problem by kludging the use of POINT. And like the ZONE, Fidonet has never adopted any standards for the use of POINT. In fact, it is only referenced twice in Fidonet Technical Specifications and only as kludge line options in messages. If it helps you understand TCP/PC addressing, you can think of a USERid as a SUPER point system, even though a POINT is rather limited compared to a USERid system. And unlike a POINT, USERid is an integrated part of TCP/PC addressing. Is Tcp/Pc And Fidonet Compatible? In most cases, yes. Most of the newer Fidonet mailers support the concept of ZONE:NET/NODE.POINT, to some degree, and GATEid.NETid.HOSTid.USERid and ZONE:NET/NODE.POINT both use the same basic format. You may have some problems doing routing on the USERid level because Fidonet has no technical specifications for points. Phoenix Technical Reference Manual Page 8 Multiple Domain Addresses Because hierarchical routing is based on ones position within the network, no system can have more than one domain address within any given network. For instances, 1.237.50.0 is a HOSTid system. 1.237.50.0 cannot also be 1.237.0.0 (commonly referred to as an AKA). 1.237.50.0's routing, something we will get into later, is different than routing done by 1.237.0.0 and the two methods conflict. 1.237.50.0 counts on 1.237.0.0 to ROUTE messages in and OUT of the net and will attempt to route messages to 1.237.0.0. If you ARE 1.237.0.0, you are routing BACK to yourself. While Phoenix does support Alternate Domain addresses, those addresses MUST be in totally different networks. By Passing Levels The CLOSEST thing to a USERid in Fidonet is a point. While anyone in Fidonet can have a POINT net, that is not true with a four dimensional domain network (Fidonet is a two dimensional domain network, net/node). The only systems that can have POINTS or USERid systems under them are HOSTid systems. This is, again, due to the nature of four dimensional domain routing. Installation Creating Required Data Files Phoenix.cmd Phoenix.cmd contains information about your particular installation. Information such as address, directories, modem strings, serial ports, etc. and you create and maintain Phoenix.cmd with the program CONFIG.EXE. Warning, config.exe DOES REQUIRE a mouse. If you do not have a mouse installed, do NOT run this program. Phoenix Technical Reference Manual Page 9 To EDIT any field, move the mouse cursor to the field and click the LEFT mouse button. Some of the fields are TOGGLE fields, to prevent you from entering an illegal value. A TOGGLE field will CYCLE to the NEXT available setting when you CLICK on it. To select an option from one of the menus, move the mouse cursor to that option and click the LEFT mouse button. Figure 1-A ╔═════════════════════════════════════════════════════════════════════════╗ ║Your Name JOHN DOE░░░░░░░░░░░░ ║ ║Mailer/BBS Name MY BBS░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║ ║ ║Primary Domain 3.620.0.0░░░░░░░░░░░░░░ ║ ║Alternate Domain ░░░░░░░░░░░░░░░░░░░░░░░ ║ ║Alternate Domain ░░░░░░░░░░░░░░░░░░░░░░░ ║ ║Alternate Domain ░░░░░░░░░░░░░░░░░░░░░░░ ║ ║Internet Address ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║ ║ ║Inbound Directory C:\PHOENIX\░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║Matrix Directory C:\PHOENIX\MATRIX\░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║ ║ ║Requested FILES FILES.ZIP░░░ Route Mode FIDONET Node Number 1░░ ║ ║IMPLIED Routing LIMITED░ Maximum Busy 100 Secure Echomail ON░ ║ ║Maximum Calls 2░░ Desqview NO░ Secure Address ON░ ║ ║Shell Instructions OSIRIS -B*B -P*P -T*T -N1░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║Carrier Out Delay 45░ Carrier In Delay 31░ Time Between dials 31░ ║ ║ ║ ║Serial Port 3░░░ Lock Rate 19200░ Flow Ctrl CTS░░░░ ║ ║Maximum Baud 2400 Minimum Baud 1200 Fifo Size 8░░ OFF HOOK NO░ ║ ║┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ ┌────────┐ ┌────────┐ ┌────────┐ ║ ║│ Save │ │ Quit │ │ Fkeys │ │ Magic │ │ Events │ │COM IRQS│ │ Modem │ ║ ║└───────┘ └───────┘ └───────┘ └───────┘ └────────┘ └────────┘ └────────┘ ║ ╚═════════════════════════════════════════════════════════════════════════╝ Your Name This is YOUR name, generally first and last. Mailer/Bbs Name This is the NAME you have selected for your mail site. Phoenix Technical Reference Manual Page 10 Primary Domain This is your address, GATEid.NETid.HOSTid.USERid (TCP/PC format) or ZONE.NET.NODE.POINT (Fidonet format). Alternate Domain (OPTIONAL) You can define up to 3 alternate DOMAIN addresses. See section on ALTERNATE DOMAINS. Inbound Path This tells Phoenix WHERE to place incoming FILES, ECHOMAIL, PKT's (matrix messages), and other items during a mail session. Matrix Path This should point to the directory that contains your matrix messages and you SHOULD end the path with a backslash. Requested Files (OPTIONAL) This is the name of the file to send when someone file requests FILES. Phoenix will replace FILES with the name of the file you define in this field and then Phoenix will search the directories listed in REQUEST.CTL in an attempt to find it. Route Mode The IMPLIED Route Manager has TWO modes, TCP/PC and FIDONET. TCP/PC mode means Phoenix will attempt to resolve an address even if it has to go all the way to the GATEid level. However, Fidonet doesn't support routing that goes that HIGH. Switching to FIDONET mode will cause the IMPLIED route manager to STOP on the highest level Fidonet supports. Phoenix Technical Reference Manual Page 11 Node Number (OPTIONAL) Several multiple line BBS programs require a NODE number on the command line, Osiris does. If you are using the SHELL method to call the BBS and you need to pass the NODE number, Phoenix will use the number found in this field. For information on HOW to get the node number INCLUDED, read the section on SHELL INSTRUCTIONS Implied Routing This determines the TYPE of IMPLIED routing Phoenix will use and your options will vary depending on the ROUTE MODE. DEFAULT, use FULL TCP/PC Implied Routing. That includes routing FILES, ECHOMAIL, and FILE REQUESTS LIMITED, do not route anything that has a file attach. DISABLED, turns Implied routing OFF. If the ROUTE MODE is "FIDONET", your only options are LIMITED and DISABLED. If the ROUTE MODE is "TCP/PC", all three options will be made available. Maximum Busy This determines the MAXIMUM number (between 1 and 255) of busy signals you can get when calling an individual system during a specific event. Once you reach the maximum number, Phoenix will stop calling. This is reset when you change events. Secure Echomail (OPTIONAL) This prevents anyone from dropping off echomail unless their NODELIST.DAT "ECHOMAIL ALLOWED" flag is turned on. Phoenix Technical Reference Manual Page 12 This is the ONLY method of running 100 percent secure echomail. Phoenix handles this by ALLOWING them to do the physical file transfer but as soon as the transfer has finished, it will promptly delete the file if they do NOT have echomail authorization. It is recommended that you use SESSION level passwords with ANYONE that has echomail authorization. Maximum Calls This determines the MAXIMUM number (between 1 and 255) of calls to an individual system during a specific event. Once you reach the maximum number, Phoenix will stop calling. This is reset when you change events. A CALL is registered when you get a physical CONNECT to the system, mail does NOT have to be transferred. If the system is having problems, software or hardware, this will prevent you from running up a large phone bill. I would suggest that you keep this low, no more than 10. Desqview While Desqview can be detected by searching memory for a specific signature, several NETWORK programs use the same signature. To avoid confusion, we ask that you TELL us if you have or do not have Desqview installed. Secure Address (Optional) Engages secure addressing. Outbound Calls When you place an outbound call with SECURE ADDRESSING turned ON, Phoenix matches the remote systems DOMAIN address with the one that triggered the call. If they do not match, Phoenix hangs UP. Phoenix Technical Reference Manual Page 13 This prevents mail from being sent to the wrong location due to an error in the network NODELIST.xxx or an error in your PHONE.CTL file. Inbound Calls When you receive an inbound call and secure addressing is turned on, Phoenix will HANG-UP if the callers NOT in the nodelist.dat file. This prevents TERMINAL programs with WAZOO emulation systems from bypassing BBS download restrictions via file requests. Something that is starting to become a problem. Time Between Dials This determines the number of SECONDS Phoenix will wait between outbound dial attempts. Carrier In Delay This determines the NUMBER of SECONDS Phoenix will wait for an INBOUND connect once RING has been reported by the modem. SECONDS should be ONE second longer than your modems S7 register. Carrier Out Delay This determines the NUMBER of SECONDS Phoenix will wait for an OUTBOUND connect once the DIALING process has been completed. SECONDS should be ONE second longer than your modems S7 register. You should set this, and the S7 register, to at least 45 if you have a v32,v32bis,HST, PEP, or any other high-speed modem. If you are placing overseas calls, you should set this and the S7 register to at least 60. 75 if used with a high-speed modem. Phoenix Technical Reference Manual Page 14 Shell Instructions (OPTIONAL) If you would rather have Phoenix SHELL to the BBS instead of exiting with an errorlevel, use this field. If you are running Osiris, see section on AUTO-DETECT before using this option. Your COMMAND LINE should contain the NAME of the program along with any command line arguments, maximum length is 50 characters. You have several reserved character sequences that you can include to pass baud rate, lock rate, serial port number, and time to end of event. *B - Phoenix will replace this with the CONNECT baud rate. *P - Phoenix will replace this with the serial port number you're on. *L - Phoenix will replace this with the LOCKED SERIAL rate. *T - Phoenix will replace this with the time to end of event, in minutes. *N - Phoenix will replace this with the BBS Node number you defined using the "NODE NUMBER" label. SHELLING to the BBS is the preferred method for two reasons. 1. You're matrix area does not have to be rescanned. 2. It is just plain faster and easier than setting up errorlevels in a batch file. When you SHELL to the BBS, Phoenix will shift to EMS or overlay itself to DISK to give the BBS all of your machines original memory, minus 5K. Phoenix does NOT change into the BBS' directory. If you're running Phoenix in a different directory, SHELL to a batch file and have the BATCH file change into the BBS directory. Phoenix Technical Reference Manual Page 15 Phoenix will LOG the shell command line, to the Phoenix log, that it used to call the application. This gives you a way to DEBUG your SHELL command line. Phoenix will also tell you, in the Phoenix log, if NO application was executed during the SHELL. SHELL INSTRUCTIONS OSIRIS -B*B -P*P -T*T -N1 Flow Control You have TWO options; CTS hardware flow control and RTS/CTS hardware flow control. In most cases CTS is best. However, if you are running Phoenix on a Network or under Desqview, Windows, or OS/2 you may need to use RTS/CTS. If RTS/CTL is used, Phoenix will lower RTS when it opens, reads from, writes to, moves the file pointer to a new position, and closes a file. Lowering RTS lets the modem know the computer is NOT ready to receive data. The modem will store the data internally until RTS is high. RTS/CTS does slow down transfers and you can STILL get errors if RTS is held low for TOO long and the modem runs out of storage space. Off Hook This tells Phoenix how to handle your modem when you exit. If OFF HOOK is turned ON, the modem will come OFF HOOK, giving a busy signal to anyone that attempts to call. If OFF HOOK is turned OFF, Phoenix will DROP DTR. Phoenix Technical Reference Manual Page 16 Serial Port Tells Phoenix which serial port to use. Valid ports range from 1 - 8. Lock Rate (OPTIONAL) This tells Phoenix to FIX the serial port at this baud rate. When you connect with another mailer or a HUMAN calling for the BBS, Phoenix will NOT change the serial baud rate. It will simply allow the MODEM to handle adjusting the SEND/RECEIVE speeds. Phoenix will NOT pass this rate as the CONNECT baud rate. It will pass the rate the modem returns in the CONNECT message. If you LOCK the serial rate higher than 9600 baud you MUST have a 16550 Uart. Attempting to run with a LOCKED serial rate higher than 9600 will almost always generate errors when you attempt to RECEIVE very large files, generally over 50K in size). Fifo Size Phoenix will automatically detect and use a 16550 Uart. You have to tell Phoenix how many bytes to send per TX interrupt. This is a TOGGLE field and you can TOGGLE between 2, 4, 6, 8, 10, 12, and 14. If you have a slower computer, your running under Desqview-OS/2-Windows, or on a network you may need to raise this to 10 or more. I don't recommend that you attempt anything over 10 unless you have a REALLY slow computer, XT. Maximum Baud This is the maximum baud rate your modem supports and the serial port is initially opened to this rate. Phoenix Technical Reference Manual Page 17 If you have a LOCKED serial port, use 9600 in this field. A LOCKED serial port is treated differently and Phoenix will use the MAXIMUM BAUD field as an internal storage variable. Minimum Baud This is the minimum baud rate you are willing to accept on inbound calls. Phoenix will hang- up if the CONNECT is less than this value. After you have filled out all the fields on THIS screen, move your mouse cursor to the BOX labeled "MODEM" and click the LEFT mouse button. This will open another screen containing the Modem STRINGS and CONNECT messages for YOUR modem. Figure 2-A ╔════════════════════════════════════════════════════════════════════════╗╗ ║ ║║ ║ Modem Strings ║║ ║ ║║ ║ Modem In AT&F2*H0B0H0&D2&P1E0\Q3\X1%C0^M░░░░░░░░░ ║║ ║ Modem Out ATS7=45^M░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║║ ║ Modem Dial ATDT░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║║ ║ Modem Answer ~~ATA|░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║║ ║ ║║ ║ No. Modem Connect Messages Baud Rate ║║ ║ ║║ ║ 1 CONNECT FAST░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 9600░░░░ ║║ ║ 2 CONNECT░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 300░░░░░ ║║ ║ 3 CONNECT 1200░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 1200░░░░ ║║ ║ 4 CONNECT 1200/ARQ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 1200░░░░ ║║ ║ 5 CONNECT 1200/REL░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 1200░░░░ ║║ ║ 6 CONNECT 2400░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 2400░░░░ ║║ ║ 7 CONNECT 2400/ARQ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 2400░░░░ ║║ ║ 8 CONNECT 2400/REL░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 2400░░░░ ║║ ║ 9 CONNECT 4800/ARQ/HST░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 4800░░░░ ║║ ║ 10 CONNECT 4800/ARQ/V32░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 4800░░░░ ║║ ║┌───────────┐ ┌───────────┐║║ ║│ PAGE DOWN │ │ RETURN │║║ ║└───────────┘ └───────────┘║║ ╚════════════════════════════════════════════════════════════════════════╝╝ Phoenix Technical Reference Manual Page 18 Modem Answer (OPTIONAL) This is the command string you want Phoenix to send to the modem when the modem reports RING, on incoming calls. If your modem is set to AUTO-ANSWER, do NOT use this field. If you do, the modem will simply NOT answer the phone. Modem Dial This is the command string you want Phoenix to send to your modem to get it to DIAL the phone number. Generally this is ATDT or ATDP. Modem Out This is the command string that prepares the modem for an outbound call. It is sent PRIOR to the NODELIST PERDIAL STRING and the MDM DIAL string. If your modem requires a carriage return, most do but a few do not, end the string with the vertical bar, | Modem In This is the command string sent to your modem to get it ready to ANSWER incoming calls. The string should set your modem so that it returns VERBOSE response codes and does NOT echo commands. If you see something like: Huh? <ATH0E0V1> then your modem is echoing commands. Although Phoenix can handle this, it does slow things down because it will keep trying until it gets OK from the modem. If your modem requires commands to end with a carriage return, most do but a few do not, end the string with the vertical bar, | Modem Connect Messages And Baud Rates Phoenix lets you define up to 50 CONNECT messages along with the serial rate to associate with the message. Phoenix Technical Reference Manual Page 19 Each CONNECT message can be up to 50 characters long. The BAUD rate can be any legal serial rate you want Phoenix to use for that connect message. CONFIG will automatically fill in the MOST popular CONNECT messages and BAUD rates when you run it for the first time. To reach the CONNECT fields 20 - 50, click on the PAGE DOWN BOX. When you finish filling out the MODEM Strings, CONNECT messages, and baud rates click on RETURN. Fkey.dat FKEY.DAT contains information about F1 though F10 and any programs you may have defined for those keys. If FKEY.DAT is missing, CONFIG.EXE will automatically create it as soon as you ran the program. While you don't have to actually DEFINE anything at this point, we'll talk about it because it is a required file, as far as PHOENIX.EXE is concerned. To reach the F-KEY definition system, move the mouse cursor to the BOX labeled FKEYS and click the LEFT mouse button. The following screen will appear: Phoenix Technical Reference Manual Page 20 Figure 4-A ╔════════════════════════════════════════════════════════════════════╗════╗ ║ F1 CONFIG░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║ ║ F2 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║ ║ F3 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║ ║ F4 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║ ║ F5 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║ ║ F6 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║ ║ F7 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║ ║ F8 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║ ║ F9 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║ ║ F0 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║ ║ ┌────────┐ ┌────────┐ ║ ║ ║ │ SAVE │ │ RETURN │ ║ ║ ║ └────────┘ └────────┘ ║1░░ ║ ╚════════════════════════════════════════════════════════════════════╝ON░ ║ ║Maximum Calls 2░░ Desqview NO░ Secure Address ON░ ║ ║Shell Instructions OSIRIS -B*B -P*P -T*T -N1░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║Carrier Out Delay 45░ Carrier In Delay 31░ Time Between dials 31░ ║ ║ ║ ║Serial Port 3░░░ Lock Rate 19200░ Flow Ctrl CTS░░░░ ║ ║Maximum Baud 2400 Minimum Baud 1200 Fifo Size 8░░ OFF HOOK NO░ ║ ║┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ ┌────────┐ ┌────────┐ ┌────────┐ ║ ║│ Save │ │ Quit │ │ Fkeys │ │ Magic │ │ Events │ │COM IRQS│ │ Modem │ ║ ║└───────┘ └───────┘ └───────┘ └───────┘ └────────┘ └────────┘ └────────┘ ║ To define a KEY, move to the mouse cursor to the field labeled F1, F2, F3, etc. and click the LEFT mouse button. Then enter the NAME of the program along with any command line information. To SAVE, click on the BOX labeled SAVE. Clicking on RETURN will exit back to the primary CONFIG menu WITHOUT saving any changes you might have made. Magic Phoenix lets you define up to 10 MAGIC file names. A MAGIC file name is a STATIC name someone can use when they do a file request and always be assured of getting the current file. For instances, the name of the current Fidonet nodelist changes each week. If you want to set it up so that all a person has to do is file request NODELIST and get the current nodelist then you would set up a MAGIC name: Phoenix Technical Reference Manual Page 21 NODELIST NODELIST.A57 NODELIST.A57 would be THIS weeks nodelist, next week you'd have to do something like NODELIST NODELIST.A64 Phoenix will search the directories listed in REQUEST.CTL for the NEW file name. Examples: NODELIST NODELIST.A57 OSIRIS SE401?.ARJ ISIS I6*.ARJ To access the MAGIC definition system, move your MOUSE cursor to the BOX labeled "MAGIC" and click the LEFT mouse button. The following screen will appear: Figure 3-A ╔════════════════════════════╗════════════════════════════════════════════╗ ║ Magic Name New Name ║░ ║ ║ ║░░░░░░░░░░░░░░░░░ ║ ║ ░░░░░░░░░░░░ ░░░░░░░░░░░░ ║ ║ ║ ░░░░░░░░░░░░ ░░░░░░░░░░░░ ║░░░░░░░░░░░ ║ ║ ░░░░░░░░░░░░ ░░░░░░░░░░░░ ║░░░░░░░░░░░ ║ ║ ░░░░░░░░░░░░ ░░░░░░░░░░░░ ║░░░░░░░░░░░ ║ ║ ░░░░░░░░░░░░ ░░░░░░░░░░░░ ║░░░░░░░░░░░ ║ ║ ░░░░░░░░░░░░ ░░░░░░░░░░░░ ║░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║ ░░░░░░░░░░░░ ░░░░░░░░░░░░ ║ ║ ║ ░░░░░░░░░░░░ ░░░░░░░░░░░░ ║░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║ ░░░░░░░░░░░░ ░░░░░░░░░░░░ ║MATRIX\░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║ ░░░░░░░░░░░░ ░░░░░░░░░░░░ ║ ║ ║ ┌────────┐ ┌────────┐ ║░ Route Mode FIDONET Node Number 1░░ ║ ║ │ SAVE │ │ RETURN │ ║ Maximum Busy 100 Secure Echomail ON░ ║ ║ └────────┘ └────────┘ ║ Desqview NO░ Secure Address ON░ ║ ╚════════════════════════════╝B -P*P -T*T -N1░░░░░░░░░░░░░░░░░░░░░░░░░░ ║ ║Carrier Out Delay 45░ Carrier In Delay 31░ Time Between dials 31░ ║ ║ ║ ║Serial Port 3░░░ Lock Rate 19200░ Flow Ctrl CTS░░░░ ║ ║Maximum Baud 2400 Minimum Baud 1200 Fifo Size 8░░ OFF HOOK NO░ ║ ║┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ ┌────────┐ ┌────────┐ ┌────────┐ ║ ║│ Save │ │ Quit │ │ Fkeys │ │ Magic │ │ Events │ │COM IRQS│ │ Modem │ ║ ║└───────┘ └───────┘ └───────┘ └───────┘ └────────┘ └────────┘ └────────┘ ║ ╚═════════════════════════════════════════════════════════════════════════╝ Phoenix Technical Reference Manual Page 22 To define a magic name, move the mouse cursor to one of the boxes in the column labeled "MAGIC NAME" and click the LEFT mouse button then TYPE in the MAGIC name, e.g. OSIRIS. TO define the NEW name for the MAGIC name you just entered, move the mouse cursor to the corrsponding box in the column labeled NEW NAME and click the left mouse button. When you are done, click on the box labeled SAVE. Summary AFTER you have filled out the fields on screens 1-A and 2-A, click on the SAVE BOX. This is VERY important. CONFIG will NOT save your settings unless you TELL it to. If you have LEFT any REQUIRED fields EMPTY, CONFIG.EXE will not allow you to SAVE or QUIT until those fields have been filled in. The remaining options COM IRQS, and EVENTS will be covered later. Nodelist.dat And Domain.idx This is your PRIMARY nodelist, DOMAIN.IDX is the index, and you have TWO ways of creating it. Ned The FIRST and easiest method is to simply run NED.EXE. It will create NODELIST.DAT along with the DOMAIN.IDX. NED will also create SYSNAME.IDX, BBSNAME.IDX, and HMS.IDX. These are optional INDEX files and we'll explain what those files are in the next section. Use this approach if you are using Phoenix in a business environment or in an environment that doesn't provide a NODELIST.XXX text file. Phoenix Technical Reference Manual Page 23 Makenl Creating Nodelist.dat and Domain.idx with NED is easy and painless, but it isn't a viable method if you belong to a large network like Fidonet. Fidonet has a new nodelist that comes out weekly and contains more than 16,000 systems. Adding those by hand, well by the time you got them added you'd have to start over again with the new nodelist. MAKENL takes the raw nodelist.xxx file and compiles it into a Phoenix TCP/PC nodelist complete with HASH tables for Sysops name, BBS name, HMS address, and finally DOMAIN address. Network Nodelist To compile a NETWORK nodelist (Fidonet, TCP/PC, Family Net, etc. ) you call MAKENL with the command line /N<NAME OF NODELIST> E.g. MAKENL /NNODELIST.157 This, in the case of Fidonet, CAN generate a rather large NODELIST.DAT file. The size of the NODELIST.DAT file for Fidonet's NODELIST.157 is about 1.8 Meg. But, you do have options that can reduce the size without having any impact on your ability to do mail. Since Phoenix is based on TCP/PC routing and Fidonet supports a similar, although a somewhat limited version of it, you do NOT have to have a nodelist record for every system. The section on ROUTING goes into details on how this works, but for now just assume that what I'm telling you is factual. Phoenix Technical Reference Manual Page 24 You can reduce the size of the nodelist.dat file by reducing its depth. Lets assume your GATEid (if you are in TCP/PC) or your ZONE (If you are in Fidonet) is 1. If you rarely do mail with anyone outside your ZONE or GATEid, then you can let the ZONE GATE or GATEid system handle routing any messages you may send. If you do mail with only a couple of systems outside your ZONE or GATEid, you can include a PERSONAL nodelist with for those systems. If you want to do that, you can reduce the nodelist.dat file by about 800K by including the command line switch /Z1 This means, only keep systems in GATEid 1 or ZONE 1. Ignore the rest. This will have no impact on your ability to send mail except you will HAVE to route mail to those outside your ZONE or GATEid to the ZONEGATE or GATEid system in you network. You can further reduce the depth, and size, of your nodelist by including /R on the command line. /R means generate a TCP/PC routing nodelist. It is kind of hard to explain what this means, but here goes. Only specific systems are retained, those need for routing purposes. For instances, 1.247.0.0 would be retained while 1.247.456.0 would be ignored. Ignored because you could route 1.247.456.0's messages to 1.247.0.0 and he could route it to 1.247.456.0 for you. Phoenix Technical Reference Manual Page 25 This isn't something you have to do manually, Phoenix knows how to do it and can do it automatically without your help. If you were to compile the Fidonet nodelist.157 (16000+ systems were listed) using the command line: MAKENL /NNODELIST.157 /R /Z1 You would produce a NODELIST.DAT file only 37K in size and, this is important, you could STILL do mail with every system listed in NODELIST.157. Most would be routed, a few could go direct. Due to limited routing capabilities in Fidonet, you will not be able to send mail to SOME systems. You can get around that by using the Nodelist editor and ADDING those systems to your nodelist or you can create a CUSTOM nodelist for those systems and merge it with your existing nodelist.dat file. If you use /R and you have to route mail to those under you, you will need to make a CUSTOM nodelist listing the individual HOSTid (TCP/PC) and NODES (Fidonet) and merge it with the exiting NODELIST.DAT file. If you do plan on adding a CUSTOM nodelist, include -T on the command line. -T means don't build HASH tables. They wouldn't be correct if you add to NODELIST.DAT so there is no point in wasting time building them. Merging Multiple Nodelists If you plan on MERGING multiple nodelists, either CUSTOM or different NETWORK nodelists, include -M on the command line. Phoenix Technical Reference Manual Page 26 -M, -MERGE, lets MAKENL know that it should NOT overwrite the exiting nodelist.dat file (you should delete your old nodelist.dat file before starting the process of building a BRAND new one). It also tells MAKENL not to mess with building the HASH tables. Example on how to merger two nodelists and a CUSTOM nodelist. MAKENL -NNODELIST.157 -M -Z1 MAKENL -NFAMNET.166 -M MAKENL -PMYLIST.DOC You do not have to include -T, -M automatically turns BUILD HASH TABLES off. Once you have complete all MERGE operations, CUSTOM and NETWORK nodelists, you must build the HASH Tables. To build the HASH Tables, call MAKENL with -H E.g. MAKENL -H The process doesn't take very long, two or three minutes. Personal Custom Nodelist MAKENL can also take a CUSTOM nodelist, that you create, and compile it into a Phoenix TCP/PC nodelist. Each Custom Nodelist, you can have several, is a simple text file. Each line, those that do not start with a semi-colon, contains information about a single system. Each line contains 13 fields, separated by a comma. Phoenix Technical Reference Manual Page 27 Those fields are: GATEid NETid ZONEid USERid SYSOP BBS_NAME PHONE_NO CONTINUOUS MAIL MODEM TYPE SESSION LEVEL PWD MAIL SESSION ECHOMAIL PREDIAL If you are using Phoenix in Fidonet as a Fidonet mailer, you can use ZONE, NET, NODE, and POINT. They BASICALLY mean the same thing. Not really but you can play like they do. SYSOP is the name of the person that owns or operates the mailer. The maximum number of characters is 36. BBS_NAME is the name of the mailer or BBS system. The maximum number of characters is 36. PHONE_NO is the full phone number for that mailer. Although dashes are allowed, they will only slow down the modem and take up space. Since they aren't needed, you're best off leaving them out. The maximum length of this field is 15 characters. CONTINUOUS MAIL means the mailer is on-line 24 hours a day. A 1 indicates that it is, 0 means it is not. MODEM TYPE indicates the TYPE of high speed protocol, if any, this system supports. You can use V32, V32B, HST, PEP, CSP, or H96 (Hayes 9600). If you don't know or it is a type that I haven't listed, leave the field blank. Phoenix Technical Reference Manual Page 28 SESSION TYPE indicates the type of mail session to use with this system. This lets you preset the type of session so that line noise or some other freak accident doesn't let you slip to a slower protocol for a large transfer. Session Types are 1 = HMS, 2 = WAZOO, 3 = SMTP or FTS-0001, 4 = Internet, and 5 = SEAlink. If you don't know what to use or don't care, use 0. 0 means anything you can get. SESSION LEVEL PWD is the session level password this system must pass to your system before a mail transfer can take place. The maximum number of characters you can use is SIX. If you don't use a session level password, leave the field blank. ECHOMAIL is a flag switch that decides IF this system can drop off echomail. If this system is allowed to drop off echomail, use a 1 in this field. If the system is NOT allowed to drop off echomail, enter 0. PREDIAL means this system has a PREDIAL string record. A predial string is a modem command string you send to CUSTOMIZE the modem prior to placing the actual call. For instances, you may want to restrict the outbound call to 4800 baud (v32/v32bis) because of bad lines. Anything you can normal send to the modem, that it understands, is acceptable. If the system has a PREDIAL string record, enter a 1. If it does NOT, enter 0. DO NOT ENTER THE ACTUAL PREDIAL STRING! Phoenix Technical Reference Manual Page 29 LEAVING A FIELD BLANK, you do not simply omit the entire thing. MAKENL determines the field's contents by the fields POSITION. If you omit one the rest of the record will not be accurate and you may even lock-up the program. You leave a field blank by simply not placing any text between the comma's. This is a Modem Type Field with information ,V32, This is a BLANK Modem Type Field ,, BLANK SPACES inside a Field, you don't use them. If you need to place a blank space inside a field use the underscore character _ The Correct method : John_Doe The Incorrect method: John Doe The NAME of the CUSTOM nodelist, that is up to you. Any legal DOS file name will work. To Compile your CUSTOM nodelist call MAKENL with the command line /P<NAME OF NODELIST> E.g. MAKENL /PMYLIST.TXT When MAKENL compiles a CUSTOM nodelist, it does NOT add the entries to the HASH tables. It also does NOT overwrite the exiting NODELIST.DAT file. The entries from your CUSTOM nodelist are appended to the END of the NODELIST.DAT file, if it already exists. This allows you to add multiple CUSTOM nodelists, one at a time. Although there is no reason, that I can see, why you couldn't combine all of them into one file before you add the custom nodelist. Phoenix Technical Reference Manual Page 30 Once you have completed ALL operations, others are listed later on, you can have MAKENL build the HASH tables. Here are a couple of records in a CUSTOM nodelist. 1,237,504,0,Tech_Support,VETLINK_III,13143346359,1,V32BIS,MYPED,1,1,1 Example with NO password 1,237,504,0,Tech_Support,VETLINK_III,13143346359,1,V32BIS,,1,1,0 Including Static Data When you have Systems with static data: Session Level Passwords, Session TYPE, OK to Drop off Echomail, or PREDIAL strings, creating a NEW nodelist.dat file from a NETWORK list can overwrite that information. It would be a PAIN to have to edit, with the nodelist editor, the information back in by hand. You can have MAKENL update the NODELIST records to include the STATIC data for you. You create a control file similar to the CUSTOM nodelist file. Your STATIC control file is a simple text file. Each line, those that do not start with a semi-colon, contains information about a single system. One line per system, each line has GATEid NETid ZONEid USERid SESSION LEVEL PWD SESSION TYPE ECHOMAIL PREDIAL Phoenix Technical Reference Manual Page 31 If you are using Phoenix in Fidonet as a Fidonet mailer, you can use ZONE, NET, NODE, and POINT. They BASICALLY mean the same thing. Not really but you can play like they do. SESSION LEVEL PWD is the session level password this system must pass to your system before a mail transfer can take place. The maximum number of characters you can use is SIX. If you don't use a session level password, leave the field blank. SESSION TYPE indicates the type of mail session to use with this system. This lets you pre-set the type of session so that line noise or some other freak accident doesn't let you slip to a slower protocol for a large transfer. Session Types are 1 = HMS, 2 = WAZOO, 3 = SMTP or FTS-0001, 4 = Internet, and 5 = SEAlink. If you don't know what to use or don't care, use 0. 0 means anything you can get. ECHOMAIL is a flag switch that determines if this system can drop off echomail. If this system is allowed to drop off echomail, use a 1 in this field. If the system is NOT allowed to drop off echomail, enter 0. PREDIAL, this system's PREDIAL string (most modems require a CARRIAGE return, if yours does end the predial string with a vertical bar, |). The MAXIMUM number of characters is 40. If the system does NOT have a PREDIAL string, leave it blank. Phoenix Technical Reference Manual Page 32 Example of a system that has a password, uses Session type 2, is allowed to drop off echomail, and does have a predial string. 1,237,504,0,SYSPWD,2,1,ATS53=4| Example of a system that does NOT have a password, uses session type 3, is allowed to drop off ECHOMAIL, and has a predial string. 1,237,504,0,,3,1,ATS53=4| Example of a system that has a password, users session type 1, is NOT allowed to drop off echomail, and does NOT have a predial string. 1,237,504,0,SYSPWD,1,0, The NAME of the static control file is entirely up to you, as long as it is a LEGAL DOS file name. Call MAKENL with the command line /S<FILE NAME> E.g. MAKENL /SFIXNODE.CTL You should ONLY use /S after you have completed ALL other operations, including building HASH tables. MAKENL /S requires NODELIST.DAT and DOMAIN.IDX. Hash Tables Phoenix uses several compact and very fast HASH tables to find a system's nodelist record. MAKENL will create 4 different HASH Tables: DOMAIN.IDX, contains the hash code for GATEid, NETid, HOSTid, and USERid (TCP/PC format), ZONE, NET, NODE, and POINT (Fidonet Format). SYSNAME.IDX contains the hash code for the SYSOPS name. Phoenix Technical Reference Manual Page 33 BBSNAME.IDX contains the hash code for the Name of the Mailer/BBS. HMS.IDX contains the hash code for HTMS addresses. The tables are compact. If you created a HASH table for 16,500 systems, the size of the DOMAIN.IDX would be 100K. In fact the size for the SYSNAME, BBSNAME, and HMS.IDX tables would also be 100K (individually). If you had 16,500 systems listed in the nodelist.dat file, you would have four, 100K, Hash Tables with a combined size of 400K. You do NOT have to keep ALL of the Hash Tables. For instances, only the matrix editor uses the SYSNAME and BBSNAME tables so you can enter just the sysops name or the name of the BBS when you enter a message. If you don't need that, you can delete them. HMS.IDX is used by Phoenix to convert HTMS addresses to TCP/PC and/or Fidonet format. If you do not do mail with any HTMS systems, you can delete the HMS.IDX file. DOMAIN.IDX is the ONLY Hash Table you HAVE to keep. If you don't you can't do mail with anyone. In fact, Phoenix will exit with an error if DOMAIN.IDX does not exist. Other Files MAKENL does create, if you use the STATIC switch (/S), one additional file and you HAVE to keep it, PREDIAL.DAT. This contains information about the PREDIAL strings and which system has one. Phoenix Technical Reference Manual Page 34 Phone.ctl This brings us to our final REQUIRED file, Phone.ctl, the phone number translation control file. This is used to translate phone numbers into a form that can be dialed from your location. Phone.ctl contains two fields per line, WHAT TO LOOK FOR and WHAT TO REPLACE IT WITH. E.g. 1314335 335 1314334 334 The first field contains the numbers to look for and if they're found, replace those numbers with the contents of the second field. You should ALWAYS place smaller numbers at the bottom of the file. 1314335 335 1314334 334 1314 1 1814 1 Line 1 and 2 translates local phone numbers. Line 3 and 4 translates same-area-code to just a 1. Let's assume the original phone number was 13143346359. Line 1 is ignored, 1314334 does not match 1314335. It would be translated to 3346359 by line 2. Lines 3 and 4 will be ignored because the dial out number now has the first 4 digits of 3346 and doesn't match "1314" or "1814". Study this closely because it can, and will, get you if you don't. The translations do NOT stop with the first match and it is possible to translate a phone number to a NEW number that will match something else, so watch yourself. Summary This concludes the basic installation process and you should be ready to put Phoenix on-line. But before you do, read the section labeled "TEST DRIVE". Phoenix Technical Reference Manual Page 35 Phoenix Command Keys While PULL down menus, exploding windows, and snappy sound effects are nice, we decided the extra code required to product the pull down menus, exploding windows, and sound effects would not enhance the usability of this application. Since a mailer generally runs unattended, we decided to go with the faster HOTKEY approach with simplier and cleaner display screens. When you DO need to interact with the application, you don't want to have to wade though a bunch of flashy windows and menus to get anything done. The command keys are broken into three LOGICAL segments, ALT keys, REGULAR keys, and CTRL keys. ALT keys and REGULAR keys reference Phoenix functions and CTRL keys reference Osiris related functions. If you don't have Osiris, the CTRL keys will not function. Phoenix Related Keys Esc, Displays the command key help menu. If you can't remember what key does what, press ESC then enter your selection. Enter, If you don't think your modem is acting right, you can force Phoenix to CLEAR and then reinitialize the modem by pressing the ENTER key. When Phoenix CLEARS the modem, it sends the +++ command sequence to force the modem into command mode. It then drops DTR and holds it low for about 1.5 seconds. And finally, the modem is initialized. With the modem already in COMMAND MODE, the initialization process isn't likely to be ignored for any reason. ?, Opens a small window on the screen displaying the NAME of the current EVENT and the starting time for the NEXT event. B, Activates SCREEN BLANKER. Alt-M, Packet control system. When you select this option, you'll get a screen listing the packets, a packet is an individual *.MSG, 15 packets per page. You can use PgUp and PgDn to move through the packets. Phoenix Technical Reference Manual Page 36 Each line displays the packet number, who it was originally addressed to (Domain Address), who it is routed to (Domain Address), The TYPE of packet (ECHO, MSG, FILE, REQ, SRV, or TIC), and the STATUS (HOLD, SEND, or CRASH). If you use the KILL option while in the packet control system, some packets may have the STATUS of 'DEL' to indicate a deleted packet. Besides PgUp and PgDn, you have several other commands: [Q]uit takes you back to waiting for mail mode. [S]end toggles the SEND status of a particular message, if it was SEND it goes to HOLD and if it was HOLD it goes to SEND . This is a TEMPORARY change and the message reverts to its original status when you EXIT the mailer, the event changes, you do a mail session, or you TOGGLE the SEND status. When you press S, Phoenix will ASK you which packet to toggle, enter the PACKET number (displayed in the first column). [C]rash toggles the SEND/CRASH status of a particular message. If it was NOT a crash message, it becomes one. If it WAS a crash message, the crash flag is removed. This is a PHYSICAL change to the actual message. When you press C, Phoenix will ASK you which packet to toggle. Enter the PACKET number (displayed in the first column). [K]ill physically DELETES the message. If that message had a file attach and the file attach was marked KILL after sending, the file attach is also DELETED. When you press K, Phoenix will ASK you which packet to kill. Enter the PACKET number (displayed in the first column). You can mix KILL and CRASH but you may not intermix KILL with toggle SEND. When you KILL a message Phoenix will rescan the matrix area, reload the event, and redo any EXPLICIT routing instructions when you exit the packet control system. If you had TOGGLE SEND, it would be undone. Phoenix Technical Reference Manual Page 37 [R]oute, lets you alter the destination address. This is a TEMPORARY change and does NOT physically alter the message. The address will revert to its original destination address when you EXIT the mailer, the event changes, or you do a mail session. Alt-E, Load Phoenix Matrix Editor. Alt-T, Clears the TIMES CALLED counters. This is the counter used to track the number of times you call a specific system during an event. Alt-B, Clears the BUSY signal counters. This is the counter that tracks the number of BUSY signals you get when you call a specific system during an event. Alt-N, Load the NODELIST editor. Alt-R, Reload Msgs, reload event information, and reload any EXPLICIT routing instructions. Alt-D, Shell to DOS. Type EXIT to return to Phoenix. Alt-F, Displays the F-KEY definition tables. Alt-P, Poll a specific system. Phoenix will ask you for the FULL Domain Address. Keep in mind that Phoenix uses a PERIOD to separate the subdomains. If the domain address matches one of the systems listed in the nodelist, Phoenix will generate a CRASH/DIRECT poll packet. Alt-C, Configuration System. Any changes you make in your primary or any subsystem will go into effect ASAP. Alt-H, HISTORY system. This displays the current call history. Press any key to return to waiting for call mode. If you want to CLEAR the History database, press ESC. Alt-W, shows WHO you last did mail with and when. Alt-S, Lets you SEND a FILE ATTACH or FILE REQUEST to another system without entering the matrix editor. The system MUST be in your nodelist. Phoenix Technical Reference Manual Page 38 Osiris Related Functions The OSIRIS related functions will ONLY be available if you are running Osiris. If you aren't, they will not show up on the help menu (they will, but they will be in a color that is very hard to see). Ctrl-O, Run OSM. Ctrl-T, Run CAT. Ctrl-E, Run Sysop Editor (Sphinx). Ctrl-L, Local Log-on. Ctrl-F, Run FAM. Ctrl-U, Run User. Ctrl-S, BBS Statistics. This shows last caller, when they called, number of calls today, number of uploads/downloads for today, TOTAL calls to the node, and it will also tell you if the sysop has any mail waiting. This functions on nodes 1 - 8. Phoenix will switch you to the OSIRIS= directory before calling any of the OSIRIS related programs. Phoenix Technical Reference Manual Page 39 Routing Principles And Architecture When you have a LARGE number of systems, it isn't practical to keep a nodelist record of every system for several reasons. You don't do mail with every system in the network and it can take a lot of disk space. There are two methods we can use to get around the problem: Use an addressing system that doesn't require a nodelist or develop an IMPLIED routing system. Routing: to direct, send, forward mail along a specific PATH to its final destination. HTMS uses the PHONE NUMBER as the address. This method doesn't need a nodelist and doesn't require another system's cooperation. The drawback to HTMS: When you in a situation where you NEED to route, it is hard to do (from a programmers point of view) and in some cases, impossible. An extensive ROUTING system is the other method of doing the same thing. While this method does allow you to do away with large nodelists, it does have several drawbacks. It can take a little longer, a day or so, to get a message from point A to point B and it does require other systems cooperation. Types Of Routing There are TWO types of routing, IMPLIED and EXPLICIT. Implied Routing Implied routing is what Phoenix does INTERNALLY and in absents of any EXPLICIT routing instructions. In other words, without giving precise and clear instructions on HOW to send a message, you are implying that Phoenix should use four dimensional network routing to get the message to its final destination. Explicit Routing Explicit routing is just that. You are giving CLEAR and precise instructions on how to send the message. You might have used the DIRECT flag. The DIRECT flag is an EXPLICIT routing instructions. You might have used a special ROUTE control file during the event. A ROUTE control file gives EXPLICIT routing instructions. Phoenix Technical Reference Manual Page 40 Throughout this document, when we say simply ROUTING, we are referring to IMPLIED ROUTING. How Implied Routing Works Assuming that a Network has the GATEid of 1. It has 2 different NETids, 1 and 2. Each NETid has 2 HOSTid and each HOSTid has 2 USERids. 1.0.0.0 <- Gateway System to This Network. 1.1.0.0 <- NETid 1 1.2.0.0 <- NETid 2 1.1.1.0 <- NETid 1, HOSTid 1. 1.1.2.0 <- NETid 1, HOSTid 2. 1.2.1.0 <- NETid 2, HOSTid 1. 1.2.2.0 <- NETid 2, HOSTid 2. 1.1.1.1 <- NETid 1, HOSTid 1, USERid 1. 1.1.2.2 <- NETid 1, HOSTid 2, USERid 2. 1.2.1.1 <- NETid 2, HOSTid 1, USERid 1. 1.2.2.2 <- NETid 2, HOSTid 2, USERid 2. This Network contains a total of 11 systems. However, the maximum number of REQUIRED nodelist records for any system in the network is 2 and in several cases 1. Yet, every system in the network can communicate with every other system. When 1.2.2.2 sends mail to 1.1.1.1, it is routed to 1.2.2.0. The message will continue to traverse the network until it arrives at its final destination. It traverses the network in the one of two ways, depending on the depth of the nodelists used by each system. Method #1 1.2.2.2 -> 1.2.2.0 -> 1.2.0.0 -> 1.0.0.0 -> 1.1.0.0 -> 1.1.1.0 -> 1.1.1.1 Method #2 1.2.2.2 -> 1.2.2.0 -> 1.2.0.0. -> 1.1.0.0 -> 1.1.1.0 -> 1.1.1.1 When a message is routed from 1.2.0.0 directly to 1.1.0.0, it is referred to as cross level routing. Cross level because 1.2.0.0 and 1.1.0.0 are both on the same level, NETid systems. Phoenix Technical Reference Manual Page 41 Figuring out before hand HOW a message will be routed isn't difficult. Routing is based on YOUR level in the network. If you are a USERid system, a USERid system can be identified by a NONE ZERO USERid subdomain, messages are always routed UP to the HOSTid system above you. It is POSSIBLE that that your HOSTid system may QUIT the network leaving your without a HOSTid. If that happens, Phoenix will BYPASS the HOSTid level and go directly for the NETid system above you. If by some weird chance of fate, the NETid system has also quit, Phoenix would attempt to route to the GATEid (he will always be there). If you are on the HOSTid level, a HOSTid system can be identified by a NONE ZERO HOSTid subdomain and a ZERO USERid subdomain, messages are either routed UP or DOWN. UP to the NETid or DOWN to the USERid level. If the NETid above you is missing, quits the network, Phoenix will bypass the NETid and go directly to the GATEid. If you are on the NETid level, a NETid system can be identified because he has ZERO HOSTid and ZERO USERid subdomains, message are either routed UP, DOWN, or CROSS LEVEL. UP to the GATEid, DOWN to the HOSTid, or CROSS LEVEL to another NETid. If you are a GATEid system, IMPLIED routing is always DOWN, to the NETid system. Common Questions Concerning Routing Q: I'm 1.235.400.0 and I'm suppose to route mail for those in my net (235). A: No, you aren't and can't route mail for others in and OUT of your NET. At least you are not going to do that with IMPLIED routing. Q: Why? Because you're a HOSTid system and a HOSTid system can only route mail UP and DOWN. IMPLIED routing is a set of predefined instructions on how to network route mail. Those instructions are based on your position in the network and that is governed by your network address. Phoenix Technical Reference Manual Page 42 Q: Suppose someone sends a message to my system for 1.237.500.5. A: Implied routing will route it to 1.237.0.0, he is YOUR NETid. It will NOT route it to 1.237.500.0, that is the NETid's job and you are not a NETid system. Q: Why Does it work that way? A: Because 1.237.500.0 is a HOSTid system and he is NOT required to accept mail from you. You're not his NETid nor are you a USERid system under him. That is how four dimensional network routing works. And, if you belong to a four dimensional network, the odds are that 1.237.500.0 isn't even in your nodelist. Q: It doesn't work that way in Fidonet! A: Yes it does, however . . . Fidonet is a two dimensional network and routing, although similar, is a little different. And, most mailers written specifically for Fidonet very seldom follow the Fidonet specifications and generally do whatever the author feels like doing. Q: But I am 1.237.0.0, I have two addresses. A: You cannot have two addresses in the same four dimensional network. Routing is based your position in the network and that is determined by your domain address. If you had more than one address in the same network, the route manager would simply have to flip a coin to decide what to do. The odds are 1 in 4 that whatever it decides will be wrong. Unlike a two dimensional network, routing mistakes in a four dimensional network can leave messages in limbo. Q: I don't like all this routing stuff. I like the way Opus and/or ISIS does it. A: Then turn the route manager off. You have that option. Phoenix Technical Reference Manual Page 43 What About Crash? CRASH means send ASAP but do it according to the DIRECT flag. It is likely that you want your mail routed, you are at the USERid level, but you want your mail to get to the HOSTid level ASAP. That is where CRASH comes into play. The Routing architecture I've outlined above is built-in and done without any special instructions on your part. You don't have to setup any type of route control files or even WORRY about how it all works. Implied Routing Limited When you set IMPLIED ROUTING to "LIMITED", CONFIG.EXE, IMPLIED routing works a LITTLE different. LIMITED routing turns OFF routing for anything that has a FILE ATTACH. This includes TIC, ECHOMAIL, SERVICE REQUESTS, FILE REQUESTS, and any other type of FILE. This does NOT preclude using EXPLICIT Routing instructions, covered later. However, it does mean you can only send FILES to systems that HAVE nodelist records. Implied Routing Disabled When you set IMPLIED ROUTING to "DISABLED", CONFIG.EXE, IMPLIED routing is all but disabled and no attempt is made to route ANYTHING. It isn't TOTALLY disabled, it will FREEZE any messages/files, etc. to UNKNOWN systems. This does NOT preclude using EXPLICIT Routing instructions, covered later. However, it does mean every system you communicate with has to have a nodelist record. Explicit Routing There may be cases where you need EXPLICIT Routing instructions or NO routing at all. Phoenix lets you define a special EXPLICIT route control file, totally optional, for each event (events are also optional). You define the route control file when you set up an event. See section on events for details. Phoenix Technical Reference Manual Page 44 Each EXPLICIT route control file you create uses one EXPLICIT routing command per line, unlimited number of lines. Each command acts independently of the last command, TOP DOWN processing. The following EXPLICIT ROUTE Nouns are available: FORWARD FOR NO ROUTE SEND TO ROUTE {} TO {} HOLD DIAL DELAY BUSY ATTEMPTS FORWARD FILE MAXIMUM CONNECTS POLL GATE {} TO {} Each Noun is followed by ONE of the following verbs: Domain Address Wild-Domain Address FILES TIC CRASH ECHOMAIL A Domain address is a SPECIFIC 4 dimensional address. E.g. 1.242.200.0 You MUST use a PERIOD to separate the individual subdomains. A WILD-DOMAIN address is almost like the regular domain address but, you can use the DOS wildcard character '*' in place of any or all of the individual subdomains. And like the DOS '*', '*' will match anything in that position. E.g. 1.237.*.0 Would match 1.237.1.0, 1.237.2.0, 1.237.45.0, etc. Phoenix Technical Reference Manual Page 45 This is used to address systems by GROUPS rather than individually. Look closely at the TYPE of address the route noun uses. You can use a straight domain address in place of a WILD-DOMAIN address but you CANNOT use a WILD-DOMAIN address in place of a straight domain address. Forward For {Wild-Domain Address} The default is forward for anyone, required on certain levels within TCP/PC, Fidonet, and other public domain packet networks. However, if you are on the USERid level you are not required to forward for anyone. If you are on the HOSTid level and do not have any USERid systems under you, you can disable forwarding without violating network regulations. Example: FORWARD FOR 1.237.504.4 FORWARD FOR 1.*.*.* FORWARD FOR 1.237.504.* FORWARD FOR 1.237.*.* To DISABLE FORWARDING, use your OWN address. If you are 1.237.504.0, using the statment FORWARD FOR 1.237.504.0 No Route {Verb} You can override IMPLIED routing with the noun NO ROUTE followed by a single verb. The verbs are: {Wild-Domain Address}, FILES, CRASH, TIC, and ECHOMAIL. TCP/PC specifications DO provide for routing file attaches, file requests, and echomail. However not all networks allow routing files and/or echomail and some mailers do not support file routing. Phoenix Technical Reference Manual Page 46 If the network you belong to doesn't support FILE routing, you have two options: Include NO ROUTE FILES NO ROUTE TIC NO ROUTE ECHOMAIL in all of your events. Or set the IMPLIED ROUTING to LIMITED. Example: NO ROUTE 1.235.*.* NO ROUTE 1.200.10.0 NO ROUTE *.*.*.* The last one totally disables routing for everybody. Send To {Wild-Domain Address} Phoenix defaults all messages, unless marked CRASH, to HOLD. In other words, you have to tell it which systems it can call during an event. Messages marked CRASH are the only exceptions to this rule. You tell Phoenix to PLACE a call to a particular system or group of system with noun SEND TO followed by a Wild-Domain address. SEND TO 1.*.*.* SEND TO 1.237.*.0 SEND TO 1.237.*.* SEND TO 1.*.0.0 Phoenix Technical Reference Manual Page 47 Route {Wild-Domain Address} To {Domain Address} This noun lets you route mail to a specific network domain address other than the one it would NORMALLY go to. NOTE: DIRECT mail cannot be rerouted. Examples ROUTE 1.238.0.0 To 1.237.504.0 Route 1.*.*.5 To 1.100.10.10 Route *.*.*.* To 1.200.0.0 Take note of the second address, the one following the word 'TO'. It is NOT a wild-domain address. This is a standard domain address. Hold {Verb} The noun HOLD is used in conjunction with SEND TO. You can use the following verbs with HOLD: {Wild-Domain address}, FILES, TIC, and ECHOMAIL. Example HOLD 1.237.504.0 HOLD 1.234.100.* HOLD *.*.*.* HOLD FILES HOLD TIC HOLD ECHOMAIL Forward File {Wild-Domain Address} Forwarding files in TCP/PC is optional but not all mailers support file forwarding. Some NETWORKS do not support file forwarding. The default in Phoenix is to support file forwarding but this noun lets you tailor or disable file forwarding. Example. FORWARD FILE 1.237.*.* FORWARD FILE 1.235.505.* FORWARD FILE 1.237.504.10 Phoenix Technical Reference Manual Page 48 To DISABLE file forwarding, use your OWN address. E.g. If you are 1.100.10.0 then FORWARD FILE 1.100.10.0 will disable file forwarding. Dial Delay {Seconds} While this is not a ROUTING noun, it does affect the delivery of mail. You can override the default time between dial attempts during a specific event. It will revert to the default dial delay when you change to the next event. Busy Attempts {Number} Again, this is not a ROUTING noun but does affect the delivery of mail. If you are going to call a system during the event that is KNOWN to be a very busy system, you may want to override the number of busy signals a certain system is allowed to have. Maximum Connects {Number} This determines the maximum number of CONNECTS to any single system during this event. A mail transfer does NOT actual have to take place. You ONLY have to establish the physical connection. {number} can be any number between 1 and 255. Poll {Domain Address} This is the final NON-ROUTE noun. This guarantees that you will have a message that will trigger a call to a specific system during this event. Domain Address is the FULL domain address for the system you want to call. E.g., 1.235.504.9 Phoenix handles the POLL command by looking to see if you have CONNECTED to that system during this event. If you haven't, then it will generate the POLL. If you have, POLL is ignored. POLL doesn't create a PHYSICAL message. There is a flag in the packet table, this holds information about your messages, specifically for POLL. Phoenix Technical Reference Manual Page 49 A NULL PACKET is ONLY used when Phoenix builds the temporary packet, prior to placing the call, and nothing was packed. Gate {Gateid} To {Domain Address} This a very SPECIAL noun and should only be used by a gateway between two networks. {gateid} is the GATEid number (TCP/PC Network) or ZONE (Fidonet) of the "OTHER" network. {Domain Address} is the full domain address of the system in the "OTHER NETWORK". Assuming your address is 99.0.0.0 which makes you the TOP most system in TCP/PC network. Since you are the TOP system, you're required to GATE matrix between your network and Fidonet (You may, but it isn't required, also GATE files). The Fidonet systems Domain Address is 1.1.99.0 (Fidonet Gating is a little different). The statement: GATE 1 To 1.1.99.0 Would ROUTE anything and EVERYTHING, including direct, that has the GATEid of 1 to 1.1.99.0. (Examples Assume ROUTE TYPE DEFAULT) Examples #1 Lets assume that you are a USERid system with the domain of 1.237.504.2 and you do run a 24hr mailer. You want to call the HOSTid system, 1.237.504.0, once a night to pickup echomail and any matrix mail, or to drop off. Other than that, your mailer is used to front for the BBS. You'll need to set-up one special event to achieve this, see the section on events for details on how to set-up the event. Lets also assume that you defined the route control file for this event as CALLHOST.CTL. Phoenix Technical Reference Manual Page 50 The first two lines, the ONLY two lines you need, in callhost.ctl: POLL 1.237.504.0 SEND TO 1.237.504.0 The first line will make sure that there is SOMETHING to trigger a call to 1.237.504.0. The second line tells Phoenix to place a call to 1.237.504.0, if mail exits for that system. If you have an echomail bundle or outbound matrix mail going to 1.237.504.0, you HAVE to have the 2nd line or Phoenix will not make the call. Example #2. Lets assume that you are 1.237.0.0 and you are going to be routing mail to and from 1.237.x.x, since you are a NETid system this is a requirement. You'll want to do this late at night when the rates are low so you'll need to set-up an event and a route control file for this event. Lets assume the route control file is called SENDEM.CTL. SEND TO 1.0.0.0 POLL 1.0.0.0 FORWARD FILE 1.237.0.0 Example #3 Lets assume you're address is 1.237.0.0 and you want to send out all matrix mail to 1.237.x.x, EXCEPT for 1.237.500.0, and you do NOT want to send Echomail or TIC files. Those you want held for pickup. SEND TO 1.237.*.* HOLD 1.237.500.0 HOLD TIC HOLD ECHOMAIL Notice how the TOP DOWN command structure works? Ok, but what if you want the TIC files for ONE specific system, 1.237.555.0, to GO. SEND TO 1.237.*.* HOLD 1.237.500.0 HOLD TIC SEND TO 1.237.555.0 HOLD ECHOMAIL Phoenix Technical Reference Manual Page 51 You can make your customized routing files as simple as the first example, or as complex (or worse . . .MUCH worse) as the last example. Common Mistake #1 ROUTE 1.237.504.0 To 1.100.10.5 HOLD 1.237.504.0 If your intention was to HOLD the mail for 1.237.504.0, it would not work. The first line routed 1.237.504.0's mail to 1.100.10.5 and there would not BE any mail for 1.237.504.0 Common Mistake #2 HOLD 1.237.504.0 SEND TO 1.237.*.* In this example, above, you are sending mail to everyone that has the address of 1.237.x.x but 1.237.504.0 is down (hard drive blew up) and his mail is suppose to be held. The first line is executed and 1.237.504.0's mail was placed on HOLD. However, you countermanded the HOLD command with the SEND TO 1.237.*.* command. Since SEND TO 1.237.*.* was the last command executed, it is the one that is retained. Tips On Speed There are TWO things you can do that will greatly reduce processing time. While Phoenix is exceptionally fast, the IMPLIED route manager actual does an enormous amount of work when it scans the matrix area. Not only does it load the messages, but it calculates a number of possible ROUTING paths to get the message to it's final destination. To do this, it must repeatedly access the nodelist to find out if certain systems are or are not listed and this is the most time consuming part. Phoenix Technical Reference Manual Page 52 To speed-up this process, run a disk cache. If possible, use at least a 128K cache. With a 128K disk cache in place, Phoenix can scan the nodelist at the rate of 45,000 records per second (16 Mzh 386 with a 25 Mls Hard drive. Faster computers and/or faster hard drives will product much better speeds. Without a disk cache, same hardware, Phoenix could only scan at the rate of about 19,000 records per second. The second thing you can do: DON'T KEEP THE ENTIRE NETWORK NODELIST. You simply do NOT need it. Even if you are a NC (Net Coordinator) you only need the other NC's and the NODES in your net. Along with maybe a few select systems you do mail with on a regular bases. Compile the fidonet nodelist with the /R switch and use a personal nodelist control file for the NODES under you and those you do mail with regularly and let PHOENIX do its job. Not only will this save you a great deal of disk space, but the overhead processing time will be drastically reduced. Events An EVENT tells Phoenix to ACT differently during a specific time frame. Events are OPTIONAL. If there is no ACTIVE event Phoenix uses the following DEFAULTS: All mail, except CRASH, is placed on HOLD. Humans ARE allowed access to the BBS. BUSY and CONNECT restrictions are disabled. No restrictions on Number of files that can be requested during a single session. Time to Next Event is the starting time of the NEXT event or midnight if you have NO events defined. Phoenix Technical Reference Manual Page 53 To define an event, run CONFIG.EXE and move your mouse cursor to the BOX labeled "EVENTS" and click the LEFT mouse button. The following screen will appear. Figure 7-A ╔═════════════════════════════════════════════════════════════════════════╗ ║ Event 1░░ ║ ║ ║ ║ Event Label AAA░░░░░ Starting Time 00:00 Ending Time 04:00 ║ ║ ║ ║ Mon Tue Wed Thr Fri Sat Sun ║ ║ Execute On YES YES YES YES YES YES YES Dynamic NO░ ║ ║ ║ ║ EXPLICIT Route Ctrl File testing.ctl░ ║ ║ ║ ║ Exit Errorlevel 0░░ Event Batch ░░░░░░░░░░░░ ║ ║ ║ ║ Exit On Inbound Errorlevel 0░░ BBS Allowed YES ║ ║ ║ ║ Do Pick-Up YES Maximum Request Per Session 2░░ ║ ║ ║ ║ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ ║ ║ │ ───-> │ │ <───- │ │ ADD │ │DELETE │ │RETURN │ ║ ║ └───────┘ └───────┘ └───────┘ └───────┘ └───────┘ ║ ╚═════════════════════════════════════════════════════════════════════════╝ ║Maximum Baud 2400 Minimum Baud 1200 Fifo Size 8░░ OFF HOOK NO░ ║ ║┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ ┌────────┐ ┌────────┐ ┌────────┐ ║ ║│ Save │ │ Quit │ │ Fkeys │ │ Magic │ │ Events │ │COM IRQS│ │ Modem │ ║ ║└───────┘ └───────┘ └───────┘ └───────┘ └────────┘ └────────┘ └────────┘ ║ ╚═════════════════════════════════════════════════════════════════════════╝ Event Lable This is not used by Phoenix, it is display so you'll know WHICH event is running. Phoenix has its own method of identifying events. The LABEL can be any name you want to call the event, a maximum of 8 characters. The label doesn't HAVE to be unique, but I would recommend that you use a different name for each event. Starting Time This tells Phoenix what time of day this event is suppose to START. STARTING TIME is in HH:MM format, military time. Legal starting times range from 00:00 to 23:59. Phoenix Technical Reference Manual Page 54 Ending Time This tells Phoenix WHEN the event is suppose to END. ENDING TIME is in HH:MM format, military time. Legal ending times range from 00:01 to 24:00. NO event may span midnight. Execute On This tells Phoenix which DAYS the event is suppose to be active. To ACTIVATE the event for a particular day, move the mouse cursor to the BOX under the DAY and click the LEFT mouse button. If the event is ACTIVE on a particular day and you want to DEACTIVATE the event for that day move the mouse cursor to the BOX under the DAY and click the LEFT mouse button. You can have the event active on ALL days, any combination of days or NONE. NONE is considered as a PLACE holder. Dynamic This means the event is ONLY suppose to be active *IF* there is outbound mail. If there is NO outbound mail, Phoenix terminates the event, even if it has not reached the ENDING TIME. Warnings If you define an event as dynamic, do not define another event that SENDS mail or POLLS until the ENDING time of the current dynamic event has passed. If the STARTING and ENDING time of a dynamic event is 00:00 and 01:00, the next SEND or POLL event should NOT begin until AFTER 01:00. The TIMES CALLED, BUSY, and POLL databases are reset when Phoenix starts to place a call or the event label POLL is used and the CURRENT event doesn't match the event tag in the TIMES CALLED, POLL, and BUSY databases. Phoenix Technical Reference Manual Page 55 This is what can happen if you don't listen to this warning: EVENT PICKUPMAIL is dynamic, runs from 00:00 to 01:00 and has an event label POLL 1.237.504.0 The next event is NOT dynamic and runs from 00:00 to 2:00 and says SEND TO 1.100.10.0 The dynamic event runs, it POLLS 1.237.504.0 and picks up echomail. After the mail is processed, Phoenix loads the current event, PICKUPMAIL. Since you've already CALLED 1.237.504.0, POLL is ignored. There is nothing to SEND so the dynamic event terminates and the next event starts. You have echomail for 1.100.10.0 and you call. THAT CALL RESETS the busy, connect, and poll databases because that event tag doesn't match the one in the databases. After you hang up, Phoenix loads the current event. Since the DYNAMIC events ENDING time has NOT elapsed, it is STILL VALID. BUT when it checks the POLL database it finds a different EVENT tag so it CLEARS it and POLLS 1.237.504.0 You can get locked into a cycle of POLLING 1.237.504.0 to pickup echomail and CALLING 1.100.10.0 to drop off the echomail you picked up from 1.237.504.0. This is the worse case scenario, it really depends on what the next event is set to do. The best defense against anything like that, follow instructions. Explicit Route Ctrl File This is the name of a text file used to hold EXPLICIT routing instructions for this event, see section on ROUTING for information on the contents of this file. Phoenix Technical Reference Manual Page 56 Exit Errorlevel This tells Phoenix to EXIT with a specific errorlevel the first time it runs this event, it will only exit one time per event. The errorlevel can be anything you want between 31 and 199. Phoenix reserves 1 - 30 and 200 - 255 for internal use. Event Batch This is a simplified form of the "Exit Errorlevel" but without having to mess with errorlevels. The first time this event is executed, Phoenix will run the batch file you defined in this field. It will ONLY run the file one time per event. You can use "Exit Errorlevel" or "Event Batch" but NOT both. In fact, CONFIG will prevent you from defining BOTH. If you set an exit errorlevel, CONFIG will CLEAR the Event Batch field. If you select Event Batch, CONFIG will change the Exit Errorlevel to 0. Exit On Inbound Errorlevel This tells Phoenix to exit with this errorlevel after each INCOMING mail session. If you've used other mailers in the pass, you may be tempted to use this to process echomail bundles that you receive. You do NOT have to use this label to process inbound echomail. When Phoenix receives an ECHOMAIL bundle, it automatically calls the BATCH file "ECHOMAIL.BAT". You would place any echomail processing instructions in this batch file. This makes it easier for those that have a hard time working with batch errorlevels and simplifies your mailer batch file. Bbs Allowed ALLOW Humans access to your BBS. Do Pick-Up This determines whether or not phoenix will pick-up anything during an outbound call. If PICK-UP is turned off, Phoenix will drop off what every it has and then hang-up. Phoenix Technical Reference Manual Page 57 Maximum Request Per Session This sets the maximum number of files a remote mailer can file request during a single mail session. If you set this field to ZERO, you have disabled file requests during this event. Summary While almost every part of CONFIG.EXE is heavily error trapped to prevent mistakes, the event subsystem has exceptionally heavy error trapping. The event subsystem has TWO types of messages, flat out ERROR messages and WARNING messages. An ERROR message will 'FIX' the problem. The FIX may not be want you wanted, but it will be legal. If it isn't what you wanted, you'll have to edit the field again. Possible Error messages ARE: Ending Time Must Be Greater Than Starting Time. An Event Cannot Span Midnight! 1 - 30 And 200 - 255 Reserved For Phoenix. Valid Starting Times: 00:00 - 23:59. A WARNING message is use to notify you of a POSSIBLE mistake on your part. If another event is involved, the EVENT NUMBER (events are numbered starting with 1) will be displayed so you can check it out personally. Possible WARNING messages ARE: That LABLE Is Being Used By Event No. 1 THIS Starting Time Being Used By Event No. 1 That Control File Is Being Used By Event No 1 That Errorlevel Is Being Used By Event No. 1 That Batch File Is Being Used By Event No. 2 You Have DISABLED File Requests For This Event. When you EXIT the events subsystem, CONFIG will SORT your events by starting time. Phoenix does not have to have them sorted, but it will be easier on you if they are. If you access the event subsystem from WITHIN PHOENIX, i.e. Phoenix is running, any changes you make will go into effect ASAP. Phoenix Technical Reference Manual Page 58 Request.ctl And File Requests File Request: A mailer calls your mailer and sends a REQUEST file containing the names of files he would like to have. If those files are available, your mailer gives them to him. You have to tell Phoenix what directories you'll allow file requesting out of by making a text file called Request.ctl. Each line in Request.ctl contains a FULL DOS PATH ending with a backslash. Example: C:\OSIRIS\FILES\GENERAL\ C:\OSIRIS\FILES\FRONT-END\ C:\OSIRIS\FILES\CATNIP\ Password Protection To password protect a directory, add a space then the password, up to 80 characters. E.g. C:\OSIRIS\FILES\GENERAL\ C:\OSIRIS\FILES\FRONT-END\ C:\OSIRIS\FILES\CATNIP\ C:\OSIRIS\FILES\GAMMA\ ULTRA The directory "C:\OSIRIS\FILES\GAMMA\" requires the password "ULTRA". Phoenix supports the standard wazoo method of doing password requests, i.e., FILENAME !PASSWORD Phoenix also supports : FILENAME PASSWORD Update Requests Phoenix supports standard wazoo UPDATE file requests. That is like a normal file request except the sender and receiver compare the date and time the file was created and the sender, Phoenix in this case, would only send the file if it is newer. Echomail.bat When Phoenix receives an echomail bundle, during an inbound or outbound mail session, it will attempt to run "ECHOMAIL.BAT" after the connection has been terminated. Phoenix Technical Reference Manual Page 59 Phoenix will shift to EMS or overlay itself to disk if EMS is not available freeing all but 5K of memory prior to calling "ECHOMAIL.BAT". You would create echomail.bat and place any echomail processing instructions in this batch file. This simplifies processing for those that have trouble with batch errorlevels. Mail Transfer Protocols There are almost as many different mailer protocols as mailers, actually more. Phoenix supports the following Mail Transfer Protocols: Xmodem/Modem7 Fidonet FSC-0001 states that ALL mailers should support a basic Xmodem/Modem7 protocol. This protocol sends MATRIX messages first using xmodem and any file attaches using modem7. But Fidonet has never enforced its own regulations and you find a lot of mailers that do not do Xmodem/Modem7. Phoenix is fully FSC-0001 compliant. A number of mailers that do not support Xmodem/Modem7 do support several variations of the xmodem/modem7 protocol, Diet INFA and SEAlink. Diet Infa Diet INFA is a "LITTLE" faster form of the FSC001 protocol that uses Telink in place of modem7. Phoenix supports Diet INFA. Sealink SEAlink is a method that's quite a bit faster than FSC001 and Diet INFA. Phoenix supports SEALink including extended form of SEAlink known as SEAlink with OVERDRIVE. Phoenix Technical Reference Manual Page 60 Notes On Sealink Because there is a CLASH between Spoofing to Telink, known as DIET INFA, and Spoofing to SEAlink (They use the EXACT same character sequence to SPOOF), You MUST have the NODELIST SESSION type set to 5 if you want SEAlink used on an outbound call. If Phoenix were to go directly to SEAlink when the SPOOF (Don't know where that name came from) sequence was received and the mailer on the other end actually wanted Telink, 8 out 10 times the transfer will fail even though Phoenix will drop back to Telink in an attempt to recover. If Phoenix is the receiver, it doesn't matter WHAT the sender wants to use. It can slide back and forth between Xmodem, Modem7, Telink, and Sealink without skipping a beat. On an INBOUND call, assuming Wazoo/Internet/HMS wasn't asked for, Phoenix will use SEAlink ONLY if A) The caller has a nodelist record and it is set to session type 5. B) The caller uses Sealink FIRST. Wazoo Wazoo, created by Wynn Wagner III, is a popular mailer protocol and widely implemented. It isn't that much FASTER than SEAlink with Overdrive, but it does offer several advantages over SEAlink. The Wazoo/Zmodem protocol built into Phoenix is solid and fast. Although I must admit that it took several years of almost constant FINE tuning, in our other mailer, to get it to talk with all of the varies Wazoo based mailers. Wazoo file requests and Wazoo UPDATE requests are supported. So far I've listed ALL the major, and minor, mail protocols used by Fidonet mailers, but despite the advantages Wazoo has over the other mail protocols, it isn't up to snuff. The reason it isn't up to snuff is the excessive OVERHEAD wazoo, or rather zmodem, adds to a file transfer. Phoenix Technical Reference Manual Page 61 Zmodem uses an encoding system that can, and does, add additional overhead to a file. E.g., if you read 8196 bytes from the file, Zmodem may expand that to 8233 bytes and you SEND the 8233 bytes instead of the original 8196 bytes. In THEORY, Zmodem COULD double the size of the file. The largest file we've tested using Zmodem was 340K and it was expanded by a little over 8K. The amount varies depending on file type. Ironically, the type that expands the MOST is the format Fidonet uses to distribute their official files, i.e., Nodelist, Newsletter, etc. Important!, Wazoo And Session Level Passwords WARNING! Some WAZOO mailers will actual LOG any session level password the other system sends. This effectively does away with any security linked with session level passwords. This lets you repeatedly place calls to a specific system using different addresses and SUCK OFF every session level password that may be associated with anyone that system does mail with. Phoenix can prevent that from happening on an inbound WAZOO session, but the password may not be safe on the system YOU are using it with. You're advised NOT to use session level passwords with ANY system that does wazoo unless the system is a Phoenix or ISIS mailer. Highspeed Mail Session While WAZOO does offer a faster "HANDSHAKE" than FSC- 0001 mail sessions, it is still fairly slow and often fails if it runs into line noise or delays induced by satellite links. We have developed, and used for several years, our own proprietary highspeed mail session, simply called HMS, that is about 30 times faster when it comes to establishing a handshake between the two mailers. It is also considerably more reliable and handles noisy lines and satellite links hundreds of times better than Wazoo. Phoenix Technical Reference Manual Page 62 Translink Having developed a better HANDSHAKING system, the thought of having to use something like Zmodem with its excessive overhead and sensitivity to satellites just didn't make sense. So in 1988 we become development and testing on a protocol called Translink. This protocol was designed to run with less than 1/2 of one percent overhead, handle satellite links, networks, multitaskers, and other items that induce time delays. Since 1988, Translink has surpassed our wildest expectations. Not only does it handle satellite lines, networks, and ARQ resends without batting an eye, it turned out to be the faster protocol in the world. Translink is about 5 percent faster than Zmodem at 2400 baud, 10/15 percent faster at 14.4, and nearly 20 percent faster when used with v.FAST (proposed v.FAST standard. v.FAST hasn't been finalized yet) Restart Recovery Yes, full Restart Recovery on interrupted transfers. You'll find that restarts are almost instantly done from the word GO. Errors During A Transfer Most protocols do not know WHEN or even IF the transmitter has received a resend request. Even the most popular protocols, Zmodem, suffer from this ailment. Zmodem may actually be the worst one since it can actually go quite some time before it figures out that the sender did not see the resend request. Translink does NOT suffer from this. The Transmitter is always sampling the reverse stream in an attempt to detect resend requests. If it does detect a resend request, it immediately notifies the receiver that it has detected the error. Phoenix Technical Reference Manual Page 63 At this point, both receiver and transmitter agree to exactly where they SHOULD be, with the receiver having the final say in the matter. Once the line has settled, the transmitter will resume transmission at the correct spot. How Does This Help Me? If you are doing mail with local systems, then using HMS and Translink will only give your BBS callers more time on-line. However, if you are making long distance calls, it can reduce your phone bill by as much as 50 percent, nothing to sneeze at. The TYPICAL wazoo mail session to drop off a couple of messages, drop off a small echomail bundle and then pick-up one generally takes about 1.5 minutes (14.4 Connect). Of course, this is a TYPICAL HOST level wazoo session. Echo hubs generally transfer larger amounts. If you use HMS and Translink you could get in and out in less than 50 seconds and that keeps you from being BILLED for a 2 minute phone call. Of course the amount of money HMS and Translink can save you will vary from system to system. The BEST way to optimize for HMS and Translink is to simply monitor your mail sessions to a particular system for a couple of weeks. Look at your connect times and then for a couple of weeks cut the number of calls in half. I.E., if you are calling once a day, call one ever TWO days. Then compare the CONNECT times. You will more than likely find that you can save money by cutting the number of calls with HMS and TRANLINK because you can transfer nearly twice as much data in that first minute. Of course, if you use a long distance service that bills in 10 second blocks (some SPRINT LD services offer this option), you'll find that you'll save even more. Phoenix Technical Reference Manual Page 64 When can you use the HMS and Translink? Phoenix to Phoenix TNT To Phoenix ISIS To Phoenix Emsc No, Phoenix does not and isn't likely to support EMSC. After studying the specifications for EMSC, we could find no useful features and several reasons not to support it. The primary reasons we decided against EMSC: 1. It is painfully slow. 2. It passes a lot of redundant information, most of the information you already have. 3. It has serious security problems. One Alpha tester said "AKA but it passes those?". It does and that is a waste of time. But how does a system pickup echomail from you when that system picks up under two different addresses? Does he have to call twice? No he does not have to call twice. You already have all the information you need, you always did, to do it with a single call. 9.999.10.0 belongs to XYZ net and to Fidonet 1.237.504.0. If you use something like other than Phoenix, that software may require a different subdomain separator, : and /. They may not support the fourth subdomain field or the first subdomain field. You'd just have to follow your mailer's manual on what to use. Phoenix Technical Reference Manual Page 65 Anyway, just add the following line to your event: ROUTE 9.999.10.0 To 1.237.504.0 When 1.237.504.0 calls to pickup Fidonet echomail, he'll also get any XYZ echomail going to 9.999.10.0 Same thing applies if you call to drop off his echomail. When you call, you'll drop off the echomail for both addresses. Works with ANY protocol: Wazoo, HIGHSPEED MAIL SESSIONS, FSC001, SMTP, SEALINK, Janus, etc. It doesn't pass redundant information and it is VERY fast, it's all done BEFORE the call is ever placed or received. The mailers don't have to attempt to get it all together while the phone companies billing meters ticking away, like they would under EMSC. ROUTE TO is not something new, it has been around for YEARS and supported by nearly every mailer out there. Matrix Editor The Phoenix matrix editor is PED.EXE. You can call it from within Phoenix by pressing ALT-E, E for EDITOR. The matrix editor is responsible for keeping the matrix area contingent, i.e. 1.MSG 2.MSG 3.MSG 4.MSG etc. When you first run PED, you'll get a "Please Stand by" message, PED is renumbering the messages. The primary PED display screen isn't THAT fancy, although it is pleasant to look at and informative. We decided to go with the LARGEST text display window, the body of the message is displayed here, we could get: 16 lines by 80 columns. Message Movement Keys Left and Right arrow, moves you backwards and forwards (respectively). HOME, takes you to the FIRST message. END, takes you to the LAST message. Phoenix Technical Reference Manual Page 66 Movement Keys, Viewing Message When you are reading a message you have the following movement keys: PgUp - Self Explanatory PgDn - Self Explanatory Up Arrow - Scroll UP a line. Dn Arrow - Scroll DN a line. CTRL-PgUp - TOP of message. CTRL-PgDn - BOTTOM of message. Command Keys V - Validate Authenticity Signature A - Edit CURRENT Message E - Enter A Message F - Forward CURRENT Message C - Carbon Copies R - Reply To CURRENT Message K - Kill Current Message Z - Clear Look-Up Table L - Do an Address LOOK-UP ESC - Exit PED E - Enter Message When you enter a message, you have to tell PED what TYPE of message you're going to enter. [M]sg - This is just a PLAIN message. [F]ile - This is a Message that will have a FILE ATTACH. [R]eq - This is going to be a FILE REQUEST. [S]rv - This is going to be a SERVICE REQUEST. If you press ENTER, [M]sg will be used. The next step is ATTRIBUTES (How Phoenix is suppose to TREAT the message). You have FOUR options: [C]rash [D]irect [K]ill [H]old Press the FIRST letter to select an attribute, press ENTER when you are done. Phoenix Technical Reference Manual Page 67 PED will TRAP mistakes during this selection process and will not allow you to select an attribute that doesn't fit the TYPE of message or an attribute that conflicts with another ATTRIBUTE. For instances, it will not allow you to use [C]rash and [H]old together. It will not allow you to use [K]ill with a FILE REQUEST or SERVICE REQUEST (Those TYPES are automatically flagged as KILL). Once you have selected the message TYPE and message ATTRIBUTES, PED will ask you for the NAME of the person the message is addressed to. If the LOOK-UP table is active, PED will fill in that name for you. If you want to keep the name, press ENTER. If you don't, press ESC to clear the field and then type in the name you want to use. If the LOOK-UP table is NOT active and you are NOT replying to a message PED will attempt to FIND a nodelist record that come close to or matches the name in the TO field. If it finds a record, it will display the record and ask you if it is the CORRECT record. The next step is the DESTINATION domain address, if the look-up table is active, PED will fill that in for you. If you want to keep it, press ENTER. If you don't, press ESC and fill in the destination domain address. PED, unless you use the LOOK-UP table address, will then attempt to validate the address. If it can't, it will ask you if you want to continue. There are a few valid reasons WHY Ped may not be able to validate the address: 1. You are using a TCP/PC ROUTING nodelist. 2. You may be sending it to a USERid system. 3. You may be sending it to a different NETWORK. The next step is the FROM name field. PED will place the name of the person who OWNS the mailer, defined in your phoenix.ini, in this field. If you want to keep it, press ENTER. If you don't, press ESC and type in the name. Phoenix Technical Reference Manual Page 68 The final step is the subject. If it is a file attach, enter the full drive, path, and file name. If it is just a plain message, enter a short subject. If you are sending a file request, type in the name of the file you want to request and press ENTER. The subject line will clear and you can continue to type in the names of files you want to request. When you are done, press ENTER without entering anything. If you are doing an UPDATE request, be sure to include the full drive, path, and file name to the file on YOUR system. If you are doing a file request and already HAVE a REQUEST going to that system, PED will NOT create a NEW one. It will append to the exiting REQUEST file. R - Reply To Current Message Reply works a lot like Enter with a few minor exceptions. The look-up table, if active, is ignored. The text TO and Destination DOMAIN are field according to the TO and ORIGIN DOMAIN of the message you are replying TO. You do have the option of editing both fields. The SUBJECT of the message you're replying to is copied to the REPLY message, you have the option of editing. K - Kill Current Message This deletes the CURRENT message. If that message had a file attach and that attach was marked as KILL, the attached file will be deleted as well. After deleting the message, PED will renumber the messages to fill in the HOLE. L - Look-Up Address If you don't KNOW the domain address of a particular person, let PED SCAN the nodelist to find it FOR you. If it finds what you're looking for, it is placed in a look-up table and will automatically be recalled when you E)nter a message. Of course, using it would be optional. Phoenix Technical Reference Manual Page 69 Selecting L presents you with three options: (S)ysop Name, (B)BS Name, and (P)attern Search. (S)ysop Name You type in the Sysops Name, as it would appear in the nodelist, and PED will scan for it. If it is found, a nodelist window will open showing the Name, BBS Name, Domain Address, CM (Yes/No), and the modem TYPE. PED will then ask you if this is the correct record, Yes or No. If you answer Yes, the sysops NAME and the DOMAIN address will be stored in the LOOK-UP Table and when you enter the message, PED will fill in the TO and DESTINATION DOMAIN fields from the LOOK-UP table. If you answer N)o, the search will terminate with a failure message. (B)bs Name You type in the name of the BBS, as it would appear in the nodelist, and PED will scan for it. If it is found, a nodelist window will open showing the Name, BBS Name, Domain Address, CM (Yes/No), and the modem TYPE. PED will then ask you if this is the correct record, Yes or No. If you answer Yes, the sysops NAME and the DOMAIN address will be stored in the LOOK-UP Table and when you enter the message, PED will fill in the TO and DESTINATION DOMAIN fields from the LOOK-UP table. Although the name of the BBS may appear in the nodelist.dat file in more than one place, the HASH system will only find the first occurrence. That is why the search will terminate if you answer N)o to "Is This The Correct Record" question. Phoenix Technical Reference Manual Page 70 (P)attern Search With the pattern search, you can enter either PART of the sysops name or PART of the BBS name. The "PART" has to be the FIRST part. For instances, the Sysops name is JOHN DOE. You could enter JOHN D, JOHN, JOH, or JO but you could NOT use DOE, OHN, HN, or OHN DOE. Unlike (S) and (B), the pattern search does NOT use the HASH tables and is a great deal slower, can take 30 to 60 seconds on a LARGE nodelist because it does a record by record search of the entire nodelist until it finds a match. If you answer N)o to the "Is This The Correct Record" questions, PED will continue to search until it reaches the END of the nodelist. F - Forward This lets you FORWARD the CURRENT message to another individual. You will be asked to fill in the TO and Destination Domain Address. The forwarded message retains the original message's Date, Subject, and Attribute fields. Your name and Domain address will be used as the SENDER. C - Carbons Carbon lets you send CARBON copies of the current message to other individuals. The CARBON function uses a TEXT Control file that should contain the ADDRESSES of the people you want to send CARBONS to. The Format of the control file is: GATEid.NETid.HOSTid.USERid GATEid.NETid.HOSTid.USERid etc. A full domain address, one per line. There is no limit on the number of lines in the control file. Phoenix Technical Reference Manual Page 71 To use CARBONS, enter the FIRST message to someone listed in the control file. After you save the message, move to it and press 'C'. A window will open and you'll be asked to supply the name of the control file that containing the address list. A CARBON of the message will be sent to everyone, except the person you used for the original message, listed in the control file. You MUST have a nodelist record for each individual listed in this control file. V - Validate Authenticity Signature If the person that SENT you the message has a REGISTERED copy of Phoenix, his message will contain an authenticity signature. If you press V, the matrix editor will tell you if the message has a VALID authenticity signature. A - Edit Current Message Lets you edit the BODY of the current message. You may NOT change any of the message HEADER fields. If you EDIT a message, you will destroy the AUTHENTICITY signature. Dc Word(tm) DC Word(tm) isn't actual an individual program, it's a module for Message entry. DC Word(tm) was designed specifically for message entry systems found in CBIS, BBS, Mailers, etc. It has many, if not more, options found in most popular word processors. DC Word(tm) has a default left margin of one and a right margin of 75. The margins may not be changed. When entering test, I'll automatically wrap when you exceed the 75th column. If you press <CR> then you'll move to the next line, if one is available, and the line you where on will be flagged as ENDING with a HARD CARRIAGE RETURN. Phoenix Technical Reference Manual Page 72 You should ONLY use <CR> to format columns of data or to signal paragraph changes. (REST OF PAGE INTENTIONALLY LEFT BLANK) Phoenix Technical Reference Manual Page 73 DC Word(tm) allows up to 161 lines of text, seven pages or about 13K. There are other systems that cannot handle messages exceeding 10K. At the bottom of the screen you'll find a status bar. It shows the current row, col., page, and the number of lines left, excluding the current line. There are several command keys available and pressing ALT-H will display a help screen listing them. Command Keys Items beginning with (*) designate wordstar compatibility. (*) Up Arrow Key or ^E - Move up a line. (*) Dn Arrow Key or ^X - Move down a line (cannot go pass last line of text). (*) Left Arrow Key or ^S - Move one CHARACTER to the left. (*) Right Arrow Key or ^D - Move one CHARACTER to the right. (*) Ctrl - Left Arrow Key or ^A - Move one WORD to the left. (*) Ctrl - Right Arrow Key or ^F - Move one WORD to the right. (*) HOME or ^Qs - Move to the start of the current line. (*) END or ^Qd - Move to the end of the current line. (*) Ctrl-HOME or ^Qr - Move to the first line, first column of the message. (*) Ctrl-END or ^Qc - Move to the Last line, first column of the message. Ins - Toggles Insert Mode on/off. Cursor becomes a BLOCK when in insert Mode. (*) DEL or ^G - Delete the character under the cursor, move rest of line back to fill hole. Phoenix Technical Reference Manual Page 74 If you are at the end of the line, I'll look at the line below your current position and if I can move text from that line to your current line, I will. (*) PgUp or ^R - Move up a page or to Top of document, which every comes first. (*) PgDn or ^C - Move down a page or to Bottom of document, which every comes first. (*) Ctrl-N - Split the line at the current cursor position. (*) Ctrl-Y - Delete the current line, move all text up a line. (*) Ctrl-I - Tab (*) BS - Backspace delete. ESC - Done editing, exit DC Word(tm). (*) Ctrl-B - Reformat document. ALT-D - Engage Dictionary. ALT-J - Jump to DOS. ALT-I - Import Text file. ALT-X - Delete from current position to end of line. ALT-S - Cursive Signature. ALT-R - Redraw Screen. (*) ^KB - Start Block Mark. (*) ^KK - End Block Mark. (*) ^KC - Copy Marked text to line below current location. (*) ^KY - Delete Marked text. (*) ^KH - Dissolve Block Marks (HIDE). (*) ^KW - Write Marked text to a file. Marked Text will be highlighted in reverse video. This is to illustrate what has been marked. Phoenix Technical Reference Manual Page 75 (*) ^U - Undelete last line deleted with ^Y, Delete buffer will hold the last 36 lines of text deleted with ^Y. Individually deleted characters will NOT be saved in the un-delete buffer. (*) ^T - Delete word. DC Word(tm) will start at the current cursor position and delete an entire word. The end of the word is denoted by either end of the line, a white space, or a punctuation mark is found. If you are at the END of the line to start with, WORDS that will fit in the remaining space on the next line will be pulled up to the current line. ^V - Insert Blank line below current position. ALT-C - Access Cut section of CUT/PASTE. Requires Mouse. ALT-P - Access Paste section of CUT/PASTE. Requires Mouse. <- Del Key - Moves the cursor back a character and deletes the character at the new cursor position. If you're at the start of the line, I'll move you to the end of the line above you and pull as many WORDS up to the line that will fit. Left Mouse Button - Active Mouse Menu. Requires Mouse. Right Mouse Button - Active Quick Jump. Requires Mouse. All functions will prevent you from going pass the last available line. Should you attempt it, the system will BEEP at you. Alt-D Dictionary ALT-D, gives you access to the Osage dictionary. You should have Osage.dic and Osage.idx in the same directory. Alt-J Jump To Dos. This uses VMS to free up all available memory. The current screen and cursor positions will be saved and restored when you return. If I can't allocate a buffer to store the video screen, you'll get an error message and the Jump to DOS will be aborted. Phoenix Technical Reference Manual Page 76 Ctrl-B Reformat. After a heavy editing session, your text could look choppy. This really doesn't hurt anything, but it's there if you want to use it. Alt-I Import File. Allows you to import text files. The only restrictions placed on this function is the size of the file. It must fit within the space you've got left. I'll make sure of that and when you run out of space, I'll quit importing the text. Although it's not a restriction, the length of the lines in the file should be discussed. I'm allowing only 78 character per line before either wrapping or requiring a HARD CARRIAGE return. Should the file contains lines that will not meet this requirement, I'll force it by placing HARD CARRIAGE returns in as needed. This means a file may not look like you though it would. If you're importing files that have lines LONGER than 66 characters, I suggest that you attempt to shorten them so they'll display correctly. When IMPORT is selected, you'll be asked for the file name. You can enter the full drive, path, and file name, wild card characters are allowed. I'll scan that directory and show you a list of files matching the file name pattern you typed in. Move to the one you want and press return. When I start importing a file, I'll always check to see if you're on a BLANK line. If not, I'll start INSERTING the text following the line you're on. I'll NEVER over write any existing line of text. Alt-S, Cursive Signature. Press ALT-S, enter the signature, and it will be converted to the new FONT format and you may place it anywhere in the message by pressing the ALT-P for paste. You can also block mark the signature, once it has been displayed with ALT-P, and write it to a MACRO file. Phoenix Technical Reference Manual Page 77 Mouse Menu Pressing the left mouse button will activate the mouse menu. This is slower than using the keyboard commands but does lower the learning curve for new sysops. Once the mouse menu is open, move to the option you want or the sub-topic and press the left mouse button. If it is an option (jump to dos) then it will be activated. If it is a sub-topic (BLOCK) a pull down menu will appear. Move to the selection you want and press the left mouse button. The RIGHT mouse button can be used to back up. Cut Allows you to mark text on the screen and places it in a buffer. Cut does NOT remove or delete the marked text. It cuts out a section of the screen and store it for PASTE recall. Once this option has been selected, your mouse cursor will be placed in the middle of the screen. Move to the upper right hand corner of the section you want to cut and press the LEFT mouse button. This will drop the first anchor. Once the first anchor has been dropped you may not go pass it, horizontally or vertically. As you move, the text will be highlighted. Once you have selected all that you wanted to CUT, press the RIGHT mouse button. You can CUT as little as one character or the entire screen. If you cut multiple screen lines, then each line will end with a hard carriage return. The text will remain in the cut buffer until you select to CUT more text. Phoenix Technical Reference Manual Page 78 Paste Paste may be selected from the mouse menu or by pressing ALT-P. If you have CUT text, selecting the PASTE option will begin placing the text in your message at your current location. If you are NOT in insert mode and you aren't at the end of the message then the text that's already there will be over written. You can paste CUT text as many times as you like. The same text will be available until you CUT more. Quick Jump Quick Jump is activated by pressing the RIGHT mouse button. This allows you to QUICKLY jump to different spots in your message, limited to locations on the CURRENT screen. When you press the RIGHT mouse button, the mouse cursor will be placed in the middle of the screen. Move to the location you want to jump to and press the LEFT mouse button. You can't move pass the last line of text or the last column on a particular line. Attempts to move pass the LAST line of text will place you ON the last line. Attempts to move pass the last column on a particular line will place you at the LAST column position for that line. Macro Keys You have 9 scrap MACRO keys that can be programmed to do all most anything you can do manually. Each MACRO can be triggered by pressing ALT-1 - ALT-9. Providing the MACRO file for that key exists, it will be executed. Each MACRO has its own specific command file, MACx with x being the MACRO key in question. i.e. MACRO ALT-1 uses the file name MAC1 To create a MACRO file, use any text editor and enter what you want. Normal text, not DC Word(tm) commands, will simply be imported into your message as TEXT. Phoenix Technical Reference Manual Page 79 All DC Word(tm) normal key functions, Ctrl-I type keys, can be triggered by entering them in character format. In other words, use some type of program, like Char.exe, to generate the character representation of the ASCII value for the command. Certain DC Word(tm) commands do not use ASCII characters but use IBM Extended Keyboard Scan codes. e.g. The Left, Right, Up, and Down Arrow keys. Using these commands requires a TWO character sequence. Each command is prefixed with the ASCII character 238 which would look like n Following the ASCII 238, enter the character representation for the key. Below is a chart listing each command and its ASCII value, keeping in mind that you don't enter the ASCII value but the ASCII character for that value. 01 - Pause for 1 second 02 - Wait for a key press 32 - Active Dictionary 45 - ALT-X, Clear to EOL 19 - ALT-R, Redraw Screen 35 - ALT-H, Show Help 36 - ALT-J, Jump to DOS 23 - ALT-I, Import Text File 82 - Toggle Insert on/off 83 - DEL, Black hole delete 77 - Right Arrow key, move right one character. 75 - Left Arrow Key, move left one character. 115 - Ctrl-Left Arrow Key, move left a word. 116 - Ctrl-Right Arrow Key, move right a word. 73 - PgUp 81 - PgDn 119 - Top of Document 117 - End of Document 72 - Up Arrow 80 - Dn Arrow 79 - Goto End of Line 71 - Goto Start of Line There's no limit to the size of the MACRO file. Since there's no size restriction on a MACRO, there is NO need to allow MACRO chaining. Phoenix Technical Reference Manual Page 80 Service Requests A service request is an external process not directly related to the mailer. To do a service request, just build a text file and use the filename: SERVICE.SRV NOTE: In this file, replace all occurrence of "SERVICE" when used as part of a filename with the ACTUAL name of the service. The contents of this file will vary depending on the service you're requesting. File attach the *.SRV file to that system. Make SURE you use a file attach and NOT a file request. When I receive one of these files, I'll take the first eight characters of the filename, or until I hit a period, and look in your root directory for a file called SERVICE.DEF. I'll read that file for a matching name and if I find the service name listed, I'll signal the other end that a service request is about to take place and to extend the timeout period to 5 minutes instead of the normal 30 seconds. I'll call that program and passing the full drive/path and filename of the *.SRV file on the command line. What the program or batch file does, well that's up to you. After you exit the service program or batch file, I'll look for a file called "SERVICE.RPT," replace the SERVICE part of the name with the actual name of the service, in your Phoenix root directory. If it exits, I'll send the file back to the caller. The contents of the file is up to the service you've requested. It can contain text, be an archive, or an executable program. Lets say I setup a service on my system, at work, called "NEWNODE." The actual NEWNODE service program is a batch file that takes my current FIDOLIST.DAT file and places it in an archive called "NEWNODE.RPT." The actual batch file to do this . . . copy con NEWNODE.BAT <RETURN> pkzip -a newnode.rpt FIDOLIST.DAT ^Z Phoenix Technical Reference Manual Page 81 Now, if I'm at home and I want the latest compiled FIDOLIST.DAT file, all I have to do is make a text file called "NEWNODE.SRV" and file attach it to my system at work. When the system at work receives the NEWNODE.SRV, it'll execute the newnode.bat file, which makes the newnode.rpt archive containing the compiled FIDOLIST.DAT file, and send it back to me. Phoenix would pass the command line "C:\INBOUND\NEWNODE.SRV" to the batch file, but since it's a batch and I don't need that information, newnode.bat will ignore it. It COULD be processed with the %1 if you wanted to do that. Service requests will during HIGH SPEED MAIL SESSIONS. To add services to your system, just create or edit a text file called "SERVICE.DEF." Enter the name of the service, up to 8 characters, one service per line. There is no limit on the number of services you can have and no limit placed on what the service can do, within reason. Since there is an open file, Phoenix.log, I would reframe from triggering any disk compression programs or chkdsk /F type programs. Programmers Notes If you're going to be writing external service programs, you can require any type of data or information in the SERVICE.SRV file. I'll pass the location and filename of the *.SRV to your program. It's up to you to process the contents, if any, of this file. The contents of the SERVICE.SRV file can be structured binary, text line formatted, or anything else you might be comfortable working with. If you're going to use a structured file, you'll need to provide a program capable of creating the *.SRV file. If you want your program to send anything back to the caller, you must use the filename SERVICE.RPT. Keep this in mind, I'll ONLY wait 5 minutes for the completion of the service. If you take longer than that, I'll disconnect. If you have an HST, make sure the you've set the S19 register to at least 7 so the modem will not timeout during a service request. Multiple Mailers Phoenix Technical Reference Manual Page 82 Nodelist Editor The PHOENIX nodelist editor, NED, lets you View, Search, Edit, and ADD nodelist records. NED does REQUIRE a mouse to EDIT but not to VIEW or SEARCH. You can access NED from within Phoenix by pressing ALT-N. If you want to access NED from DOS, just type NED from the DOS prompt. When NED comes up it checks for NODELIST.DAT, DOMAIN.IDX, SYSNAME.IDX, BBSNAME.IDX, HMS.IDX, and finally PREDIAL.DAT. If any of the files are missing, NED will create the file. The only exception is DOMAIN.IDX. If NODELIST.DAT exists but DOMAIN.IDX does NOT, NED cannot continue. If NODELIST.DAT does NOT exist, NED will create NODELIST.DAT and all IDX files. The FIRST record will be YOUR record, based on the contents of your PHOENIX.CMD file. If PHOENIX.CMD doesn't exist, NED will exit. There is a MOUSE CLICK menu that runs across the bottom of the screen containing: -----> <----- FIRST LAST ADD FIND EXIT To select, move the mouse cursor to the BOX and click LEFT mouse button. The mouse menu options also have HOTKEYS. MOUSE HOTKEY ------> RIGHT ARROW KEY <------ LEFT ARROW KEY FIRST HOME KEY (Key pad) LAST END KEY (Key pad) ADD A FIND F EXIT ESC To EDIT a field, move mouse cursor to the field and click LEFT mouse button. Phoenix Technical Reference Manual Page 83 The fields: Modem Type, Echomail, CM, and Session Type are CYCLE fields. In other words, they CYCLE to the NEXT selection when you click on them. Continue to CLICK until the field contains the data you want. Certain fields are REQUIRED. If you edit one of those fields but leave it blank, the ORIGINAL contents will be restored. All HASH INDICES are automatically updated if you change an INDEX field. The PREDIAL.DAT file is automatically updated when you add, edit, or CLEAR a system's PREDIAL string. If you CLEAR a predial, the PREDIAL.DAT record for that system is BLANKED. REASON: It cannot be totally removed because everything is POSITION sensitive and the ENTIRE nodelist.dat file would have to be REINDEXED (could be very time consuming). While we're on the subject of position sensitive, you'll notice there is no DELETE option. Since the HASH indices are all based on the NODELIST.DAT record POSITION for each entry, deleting a record from NODELIST.DAT would throw all the HASH indices off and they would have to be rebuild from scratch. It would be to time consuming to PACK a 1.8 Meg Nodelist and then rebuild all 4 HASH indices. It would also create a lot of disk fragmentation. Add When you ADD a record, you'll be required to fill out the following fields: GATEid, NETid, HOSTid, USERid, SYSOPS NAME, BBS NAME, and the PHONE. NED takes care of making SURE you fill out those fields and once you have, the record will be added to NODELIST.DAT and the INDICES updated. You can customize the remaining fields by pressing END to reach the NEW record and then select the fields you want to edit with the mouse. Find You can quickly locate an individual record with the Find option. When you select Find, you'll be asked HOW you want the search done. You have: (D)omain, (S)ysop Name, (B)bs Name, and (P)attern Matching. Phoenix Technical Reference Manual Page 84 Once you have made your selection (D, S, B, or P), NED will ask you for the KEY. This is the information it uses during the search. If you select D, enter the DOMAIN address. If S, enter the SYSOPS NAME, etc. D, S, and B make use of the HASH Indices to find the record so you have to be specific and enter the KEY just like it would appear in the nodelist record. E.g. You want to find 1.237.504.0 Select Find, press D, then enter 1.237.504.0 If the KEY can be found, the search is VERY fast, you'll be placed on the record. P, pattern matching, searches the SYSOP NAME and BBS NAME fields. Since this is a RECORD by RECORD string search, it can take a little time. When each match is made, NED will ask (after displaying the record) if this is the one you want. If it is press Y, other wise press N. To terminate the search, press Y to except the current record. The remaining Mouse Menu options are self explanatory. Log File Phoenix keeps a VERY extensive log detailing almost everything that it does. If you have a problem, CHECK THE LOG. The LOG file name is PHOENIX.LOG. Errorlevels & Error Msgs Phoenix uses several errorlevel when it needs to EXIT to your batch file. Below is a list of the errorlevels Phoenix uses. Errorlevel Reason 1 You Requested The Exit. 2 Internal Error. 3 Received TNT Mail Packet. 4 Received TNT Upload. 5 Received TNT Msg Center Attach. 255 Human Caller. Phoenix Technical Reference Manual Page 85 With errorlevels 1,3,4, and 5. The following text will appear in your log. Operator Requested ShutDown, Exiting Errorlevel 1 Received TNT Mail, Exiting Errorlevel 3 Received TNT File Attach, Exiting Errorlevel 4 Received TNT Msg Center Attach, Exiting Errorlevel 5 With errorlevel 2, internal Error, the following will appear in your log to explain the problem. COMPORT.DAT Is Missing. Could Not Allocate Ring Buffers. Could Not Install Serial Driver. PHOENIX.CMD Is Missing. Modem Not Responding. NODELIST.DAT Is Missing. DOMAIN.IDX Is Missing. FKEY.DAT Is Missing. MAGIC Is Missing. Unknown Error, CODE XX If you ever get the last one, let us know along with the CODE number so that we can trace down our mistake. You may also see several other error messages in your Phoenix log and on the screen. These error messages do not cause Phoenix to exit. Here are some of the error messages (the text of the message may vary a little bit) you're most likely to see, there are others but they are pretty self explanatory and we don't want to waste a lot space here. "Error, no program was executed during Spawn!" This message would appear when you SHELL to the BBS or execute an EVENT batch file and NOTHING was executed during the spawn. "Route File For This Event Is MISSING!" This message would appear when you have an active event and you defined a route file and PHoenix couldn't find the file you defined. "Route Cmd 'xxxxxxxxxxx'?" This would appear when you have defined a route file for a specific event and Phoenix found a command that it did not understand. 'xxxxxxxx' would be replaced with the command it didn't understand. Phoenix Technical Reference Manual Page 86 Human Callers There are two methods of passing HUMANS to your BBS. The first and preferred method is the SHELL option. When you SHELL to the BBS, Phoenix will shift to EMS or overlay itself to DISK to give the BBS all of your machines original memory, minus 5K. The advantages are three fold: If you are using a DISK CACHE, it makes the cache that more effective by not disturbing the information it has already cached. You don't have to mess with errorlevels and batch files. And finally your matrix messages, events, and routing doesn't have to be redone. If you use the SHELL method, Phoenix will LOG the SHELL command line to your Phoenix.log and to the display screen. This can be useful if you need to debug your SHELL Command line. If for some reason no application was executed during the SHELL, Phoenix calls it a SPAWN, that information will also be displayed on the screen and added to the Phoenix.log. The second method is EXITING with ERRORLEVEL 255. Although I can see no reason WHY you would HAVE or WANT to use this method, it is available. When a Human calls, Phoenix will create a batch file called RUNBBSn.BAT file, n is the serial port you're on. If you're using COM 2, the name of the file would be RUNBBS2.BAT and the contents of the RUNBBS2.BAT file: HUMAN2 <Connect Rate> <Serial Port #> <Time To Next Event> (It is up to YOU to create HUMAN2.BAT. This is the BATCH file that ACTUAL calls the BBS). After creating RUNBBS2.BAT, Phoenix will exit with errorlevel 255. It is up to you to trap that errorlevel and call RUNBBS2.BAT file. RUNBBS2.BAT will, in turn, call HUMAN2.BAT which is your actual CBIS batch file. Keep in mind the 2 is ONLY used if you are using COM 2. If you are using COM 1 then it would be RUNBBS1.BAT and HUMAN1.BAT. Phoenix Technical Reference Manual Page 87 Smart(tm) Packer Phoenix has its own internal packing system that places messages in PKT format. You don't need an external packer like OMMM or PACKER.EXE. The internal packer is a SMART packer. It can tell the difference between a FILE REQUEST, a SERVICE REQUEST, an ECHOMAIL BUNDLE, and a regular FILE. With a regular file you would want to send the message header so the other system can, if it's an ISIS or Phoenix mailer, automatically ROUTE the file on to its final destination. But with the FREQ, SRV, and ECHO messages the message header would just clutter up the other systems matrix area. The SMART packer will SKIP those messages when it packs for a particular system. If NO message headers were packed, no matrix mail or regular file attaches, the SMART packer will create a NULL PACKET. A NULL Packet is a 58 byte PACKET HEADER with no messages. It gives the receiver a way of figuring out WHO is calling, if the receiver uses that method (Binkley does even if you do a WAZOO session.) without cluttering his matrix area with useless messages. The SMART packer will ignore any file request and service requests if they are for a system that is calling YOU. The SMART packer doesn't PREPACK the messages. Messages are only PACKED into PKT format when Phoenix needs to actual SEND them. The only time messages are PREPACK is right before placing an outbound call. Since it has to SEARCH to see if anything is going out, it creates a TEMPORARY PKT as it finds the messages. It is something that would have to be done anyway and this does away with a little redundant processing. What happens if a message has been routed to a different domain address and the system it was originally FOR calls? E.g. Messages for 1.237.504.0 were routed to 1.237.0.0 and 1.237.504.0 calls with a file request. Phoenix would give him his messages. It KNOWS who they were originally for and will simply route them BACK to him. Phoenix Technical Reference Manual Page 88 Maximum Number Of Outbound Messages The maximum number of outbound messages Phoenix can handle at once is 256. This limit can be raised if the need arises, but 256 seems like plenty. Alternate Domains It is common practice among Fidonet sysops to belong to multiple networks. However, TCP/PC only allow a specific individual to hold multiple Domain addresses under one of the following conditions: An ECHOMAIL GATEWAY will need to hold a Domain address in BOTH networks. There can only be ONE Echomail gateway per DOMAIN. The reason there can only be one gateway per domain is simple, but hasn't been explained to too many people. When ECHOMAIL crosses from one DOMAIN to another, the seen by lines and path statements are stripped. Example: FIDONET -> {SEEN-BYS/PATHS STRIPPED} -> FAMILY NET FAMILY NET -> {SEEN-BYS/PATHS STRIPPED} -> FIDONET As you may, or you may not, know . . . echomail software uses the SEEN-BY lines to determine WHO gets an ECHOMAIL message and who doesn't. When you STRIP the SEEN-BY lines, the echomail software can't determine whether a system HAS or HASN'T 'SEEN' the message. Therefore it sends the message to everyone in the Echomail control file. If someone in FAMILY NET were to ECHO the message BACK into Fidonet, other than the official gate who WOULDN'T do that, the FAMILY NET seen bys and paths are stripped. The message is BACK in Fidonet but WITHOUT the fidonet seen- by lines and without the Family Net seen-by lines. Now you have DUPLICATES floating around Fidonet, and sooner or later, FAMILY NET. Phoenix Technical Reference Manual Page 89 Duplicate because it has already been THROUGH Fidonet. If it is a SMALL echo area, one with little traffic, it can sooner or later be stopped. However, if the area has a high volume of traffic it may NEVER be stopped and can get into a never ending cycle of going from Fidonet -> Family Net -> Fidonet - > Family Net -> etc. Some network allow anyone and everyone to hold multiple domain addresses. That is dangerous and a bit foolish, but if your network is one of those then I guess you can do anything you want. The MATRIX GATEWAY will need to hold a Domain address in both networks. There can only be one MATRIX gateway per Domain. The reason is routing. The route manager built into any mailer must be assured that it can safely ROUTE inter-domain mail using a preset algorithm. That algorithm is: NET = YOUR ZONE NODE = THEIR ZONE While acting as an unofficial matrix gate is not as dangerous as gating echomail, it should be avoided. There are no problems associated with a single system holding multiple domain addresses if the other domain is internet. The technology between the two networks is so different they don't clash or pose any type of ROUTING or ECHOMAIL problems. Methods Of Handling Legitimate Multiple Domains Phoenix provides three methods of handling LEGITIMATE multiple domains. Internet Address In CONFIG.EXE you'll find a field labeled "INTERNET ADDRESS". If you hold an INTERNET domain address, you enter it there. Phoenix Technical Reference Manual Page 90 Alternate Domain If you are the GATEid( MATRIX GATE) or an ECHOMAIL GATE you'll find, in config.exe, several fields labeled ALTERNATE DOMAIN. You can define up to THREE ALTERNATE DOMAIN ADDRESSES. Phoenix NEEDS to know about the alternate domains to prevent it from PACKING mail to YOUR OWN ADDRESS. Although it would never be sent, it takes up space in the packet table and it takes time to load and attempt to ROUTE. If a mailer calls and their GATEid is one of YOUR alternate Domain GATEid's, Phoenix will switch to the ALTERNATE domain address for that GATEid and your HMS or WAZOO header will show the ALTERNATE domain address instead of the default DOMAIN address. If Phoenix has to pack any messages for the calling system to PICKUP, the packet HEADER (not the messages themselves, they are not touched) will show your ALTERNATE domain address as the PACKING system. How To Pickup Mail When Multiple Domains Are Involved The first method would be used if you pickup mail going to more than one network domain at a single location. Assuming you were the ECHOMAIL gate to Fidonet and Family. Your Fidonet domain might be 1.237.504.0, your Family Net domain might be 10.200.10.0 and your TCP/PC domain would be 99.234.1.0 and your feed for Fidonet and FamilyNet is the same PHYSICAL system and his primary Fidonet address is 1.134.500.0. (THAT is a mouth full!) 1.134.500.0 also has the FamilyNet address of 10.100.9.0. You would have 1.134.500.0 route ALL mail going to 1.237.504.0 AND 10.200.10.0 to 99.234.1.0, your primary DOMAIN address. And, you would route all 10.100.9.0 and 1.134.500.0 mail to 1.134.500.0 When you call 1.134.500.0 using your TCP/PC domain (99.234.1.0), you would be able to pick-up all mail original addressed to 1.237.504.0, 99.234.1.0, and 10.200.10.0. That would include any echomail bundles, file attaches, and standard MATRIX mail. Phoenix Technical Reference Manual Page 91 Because this is all done PRIOR to the physically connect between the two systems, it is very DATA secure and fast. (NOTE: Some mailers have rather limited routing capabilities and cannot handle routing echomail and file attaches. Avoid doing mail with those system if multiple networks are involved unless it is a local call.) Picking up when only ONE ALTERNATE domain address is involved: Phoenix will switch to the ALTERNATE Domain Address prior to placing the call. Lets assume you defined an ALTERNATE DOMAIN of 1.237.504.0 and 1.100.10.0 is the system in the other DOMAIN. You primary domain is 99.99.1.0. Prior to PLACING the call, Phoenix will simply switch your primary domain address to 1.237.504.0. After the call, Phoenix will switch your PRIMARY domain address BACK to 99.99.1.0. Busy The Modem Phoenix will BUSY the modem, bring it OFF-HOOK or lower DTR depending on your CONFIG.EXE setting, when it does any of the following. 1. Scans the matrix area for mail. 2. Performs IMPLIED routing. 3. Reads and executes any EXPLICIT routing instructions. 4. Executes any EVENT batch file. 5. Exits with an errorlevel. 6. Unbundles matrix mail. 7. Executes ECHOMAIL.BAT. Phoenix Technical Reference Manual Page 92 Auto Detecting Osiris Bbs Software When Phoenix loads it does a QUICK search for the ENVIRONMENT variable "OSIRIS=". If it finds that variable, it automatically engages the SHELL to BBS using the default command line "OSIRIS -B*B -P*P -N*N -T*T". It will also change INTO the Osiris directory before calling the BBS. While this default SHELL command line will be enough for 99 percent of the Osiris sysops, some of you may need or want to tailor the command line. To tailor the command line use the Config.exe field labeled SHELL INSTRUCTIONS. Example SHELL INSTRUCTIONS OSIRIS -B*B -P*P -N2 -T*T -E: -S384 -O384 If you define shell instructions, your instructions will supersede "OSIRIS -B*B -P*P -N*N -T*T". Testing Your Setup When you first install Phoenix or rather your events, you will need a quick and easy way to TEST exit with a errorlevel (and how you BATCH file executes that errorlevel) or if you elect to use the event BATCH file you'll need to test that. Since Phoenix will only exit with the errorlevel or execute the event batch file once, you certainly don't want to wait a day at a time to test any modifications. While Phoenix is running, press ALT-Z (Z for ZAP). This wipes out all information pertaining to which event was run and when. This is basically what happens when your system clock goes from 23.59 to 00.00 each night. This can also be used to test modifications to a custom route control file. Keep in mind that Phoenix will NOT execute events who's ENDING time has already passed so you can only test your setup on the CURRENT event. To test events that have already passed or events that are yet to come, change your system TIME so that event will be active. Phoenix Technical Reference Manual Page 93 Aborting You can abort ALMOST everything by pressing ESC. In a few places, where TIMING is critical, the keyboard is not checked and pressing ESC will have no effect. In a few places where TIMING is NOT critical but where ESC might leave the other system HANGING with its mouth open, ESC will be buffered until it can be safely processed. Tic TIC is a method of automatically ECHOING files from system to system the same way you would echo messages. We produce a TIC compatible processor called OTC that works with Phoenix and our BBS program, Osiris. The TIC processor you use would depend on the BBS software you're using. If Phoenix detects a TIC control file, they have a file extension of .TIC, it will execute a BATCH file called "TIC.BAT" You can place any TIC processing instructions in this batch file. Raid Raid is a TIC utility that allows remote systems to ADD, REMOVE, or get a list of the TIC areas they have access to. When Phoenix scans the matrix area, building the matrix tables, and it DETECTS a message addressed to RAID, it will call the batch file "RAID.BAT". Phoenix Technical Reference Manual Page 94 You should place any PROCESSING instructions for YOUR raid program in this file. If your RAID utility is actual named "RAID.EXE or RAID.COM", you will need to RENAME it to keep it from conflicting with the RAID.BAT file. Areafix Areafix is a program that allows systems picking up echomail from you to automate the process of adding, removing, or getting lists of their areas and available areas. When Phoenix scans the matrix area, building the matrix tables, and it DETECTS a message addressed to AREAFIX, it will call the batch file "AFIX.BAT". You should place any PROCESSING instructions for YOUR areafix program in this file. Afix.bat, Tic.bat, Raid.bat, Echomail.bat Ok, no one builds TIC and RAID into their mailer so we're one up. But, several mailers build Areafix and Echomail programs directly into the mailer, why do we call batch files? While that can be 'NICE', it is a rather limited feature because not all BBS' use the same type of message base structures or the same type of ECHO control files. This method doesn't FORCE you to use any particular type of BBS and lets YOU pick the Echomail, TIC, RAID, or AREAfix programs that YOU like. .Msg Storage Format Do not make the mistake of thinking that you can use ANY application that stores messages with the file extension of *.MSG *.MSG is simply a file extension used to denote a MATRIX message and the FORMAT for that file will vary from mailer to mailer. If the application does not specifically say that it supports the PHOENIX matrix format, you cannot use it. We have made special provisions for ECHOMAIL processors, see section on CONSEA. Any software author wishing to SUPPORT the Phoenix Matrix format will find the MSG format along with instructions on how to use several fields at the end of this document. Phoenix Technical Reference Manual Page 95 Comport.dat Phoenix gets information about your SERIAL port from the COMPORT.DAT file. This file contains information about the BASE address, IRQ Mask and the Interrupt Vector. You should be VERY careful about changing ANYTHING in this file. To edit or view COMPORT.DAT, run CONFIG.EXE and move your mouse cursor to the BOX labeled "COM IRQS" and click the left mouse button. The following screen will be displayed: Figure 5-A ╔══════════════════════════════════════════════════════════╗══════════════╗ ║ Base Address IRQMask Interrupt Vector ║ ║ ║ ║ ║ ║ COM1 03F8 10 0C ║ ║ ║ COM2 02F8 08 0B ║ ║ ║ COM3 03E8 10 0C ║ ║ ║ COM4 02E8 08 0B ║ ║ ║ COM5 0000 00 00 ║ ║ ║ COM6 0000 00 00 ║░░░░░░░░░░ ║ ║ COM7 0000 00 00 ║ ║ ║ COM8 0000 00 00 ║░░░░░░░░░░ ║ ║ ║░░░░░░░░░░ ║ ║ All values are in HEX notation. ║ ║ ║ ┌──────┐ ┌──────┐ ║umber 1░░ ║ ║ │ SAVE │ │CANCEL│ ║ Echomail ON░ ║ ║ └──────┘ └──────┘ ║ Address ON░ ║ ╚══════════════════════════════════════════════════════════╝░░░░░░░░░░░ ║ ║Carrier Out Delay 45░ Carrier In Delay 31░ Time Between dials 31░ ║ ║ ║ ║Serial Port 3░░░ Lock Rate 19200░ Flow Ctrl CTS░░░░ ║ ║Maximum Baud 2400 Minimum Baud 1200 Fifo Size 8░░ OFF HOOK NO░ ║ ║┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐ ┌────────┐ ┌────────┐ ┌────────┐ ║ ║│ Save │ │ Quit │ │ Fkeys │ │ Magic │ │ Events │ │COM IRQS│ │ Modem │ ║ ║└───────┘ └───────┘ └───────┘ └───────┘ └────────┘ └────────┘ └────────┘ ║ ╚═════════════════════════════════════════════════════════════════════════╝ To change a field, move the mouse cursor to that field and click the LEFT mouse button and then enter the new data. You MUST enter the data in BASE 16. To SAVE your changes, move to the BOX labeled "SAVE" and click the LEFT mouse button. Clicking on CANCEL will take you back to the main screen without saving any changes you may have made. Phoenix Technical Reference Manual Page 96 Fossil Phoenix has an internal serial driver and does not use a fossil. If you have a fossil loaded for your BBS, make sure it is deactivated prior to calling Phoenix. Most BBS programs will deactivate the fossil when they are finished so that should pose no problems. Advanced Operations Phoenix has several features specifically for the advanced system operator. Unless you KNOW what you are doing, we do not recommend that you mess with these features. Nomail If the file "NOMAIL" exists in the Phoenix directory, Phoenix will not attempt to place any outbound call nor will it accept an INBOUND call. Only ONE line may actual PROCESS inbound mail and build outbound messages for ALL the other lines. By creating a NOMAIL file, the contents of the file isn't important, the line that IS processing the mail can prevent the OTHER lines from interfering with that processing by accepting inbound calls or trying to deliver echomail bundles that you MAY be in the process of updating. See the section on NETCOM.EXE for further details. Recycle.xxx Recycle.xxx, xxx would be replaced with the 3 digit (padded with ZEROS) BBS Node number defined in CONFIG.EXE, is used by an external application to FORCE phoenix to rescan the matrix area and reroute the messages. Assuming that you have two mailers, one running on NODE 1 and one running on NODE 2. NODE 1 does ALL the mail processing (unpacking PKTS, processing inbound Echomail, TICS, etc.) and it just imported and exported echomail. You would want NODE 2 to rescan the matrix area to PICKUP those new echomail bundles and you want it done now. Using NETCOM, see section on netcom.exe for details, you would create the file RECYCLE.002 Phoenix Technical Reference Manual Page 97 When NODE 2 SEES that file, it will rescan the matrix area and find the new messages. Phoenix ONLY scans for the RECYCLE.xxx file once every 60 seconds so there may be a slight delay before anything happens. Sysdown.xxx Sysdown.xxx, xxx would be replaced with the 3 digit (padded with ZEROS) BBS Node number defined in CONFIG.EXE, is used by an external application to FORCE Phoenix to EXIT with errorlevel 6. Sysdown could be used when you have BBS maintenance events on multiple line systems. You want ALL lines down during message area PACKING (removing delete message), USER record maintenance (deleting old user records), and other operations that would simply not work if you had callers on-line. Phoenix ONLY scans for the SYSDOWN.xxx file once every 60 seconds so there may be a slight delay before anything happens. See the section on NETCOM.EXE for further details. Special Phoenix Flag Settings You'll find an option, config.exe, on the main menu called MORE. This takes to you another CONFIGURATION screen with the following settings: ECHOMAIL.BAT YES/NO TIC.BAT YES/NO AFIX.BAT YES/NO RAID YES/NO UNBUNDLE MAIL YES/NO If you are running more than one mailer, you can only have ONE of them actual do the inbound processing for Echomail, TIC, RAID, AREAFIX, and Unbundling matrix mail. By TOGGLING these options to NO, you can select WHICH mailer will do the actual inbound processing. Phoenix Technical Reference Manual Page 98 Netcom.exe NETCOM is an application you can use to run multiple copies of Phoenix and allow all LINES to handle inbound and outbound mail. NETCOM requires two command line arguments, one if MOVE is used. The first argument is the COMMAND; WAIT, SHUTDOWN, RECYCLE, FREE, NOMAIL, COPY, or MOVE. The second argument, with the exception of MOVE, is the NODE number you defined for the Mailer who's batch file you are currently in. That is a little bit confusing but it will become clear later on. The only command that doesn't require the node number is MOVE. Wait <Node #> Wait until the NODE that called for the SHUTDOWN says it's ok to go back on-line. Shutdown <Node #> Tells the OTHER mailers that <NODE #> said to SHUTDOWN and exit with ERRORLEVEL 6. Recycle <Node #> Tells the OTHER mailers that <NODE #> said to RESCAN their matrix areas. Free <Node #> Tells the OTHER mailers that <NODE #> said it was OK to go back ON-LINE or that it is OK to accept and place mail calls. This should ONLY be used by the NODE that CALLED for the SHUTDOWN or the freeze on MAIL sessions. Nomail <Node #> Tells the OTHER mailers that <NODE #> said NOT to accept or place mail calls. Phoenix Technical Reference Manual Page 99 Copy <Node #> Move all the files in the OTHER mailer's inbound directory to <NODE #>'s inbound directory. Move Move MATRIX messages to specific individual from the PRIMARY matrix area to the matrix area for the mailers those individual are assigned to. NETCOM.EXE requires a control file, NETCOM.CFG, and if MOVE is used, NETCOM2.CFG. Netcom.cfg NETCOM.CFG contains information (node number, path to system files, and path to the inbound area) about each mailer you have on-line. The format: <NODE #> <SYSTEM PATH> <INBOUND PATH> You can define UPTO 8 Nodes, 1-8. Example: 1 c:\mailer1 c:\mailer1\in 2 c:\mailer2 c:\mailer2\in Netcom2.cfg This file contains the path to the PRIMARY matrix area (this is the matrix area for the mailer that does the inbound processing), the DOMAIN address of individual systems, and the path to the MATRIX area they are assigned to. If NETCOM finds a message addressed to one of those addresses, it moves it to the correct matrix area. If the address isn't listed in NETCOM2.CFG, we assume it is already IN the correct matrix area. Example: c:\mailer1\matrix 1.237.504.0 c:\mailer3\matrix 1.100.10.0 c:\mailer2\matrix You can list a MAXIMUM of 50 systems. Phoenix Technical Reference Manual Page 100 When NETCOM issues a NOMAIL or SHUTDOWN command, it requires all nodes to RSVP the command. NETCOM will LOOP until all nodes reply with their own RSVP'S. That allows nodes that are already BUSY doing something to finish whatever it is they are doing. Here are a couple of examples that you can use as a guideline for this program. You are running TWO mailers and the first mailer is NODE 1 and the second mailer is NODE 2. The first mailer is in the directory c:\mail1 and the second mailer is located in the directory c:\mail2. If you run multiple mailers, they have to be in different directories. The first mailer uses C:\MAIL1\INBOUND for its inbound directory and the second mailer uses C:\MAIL2\INBOUND as its inbound directory. If you run multiple mailers and you are allowing SERVICE requests or file request, you HAVE to use different inbound directories. If you do NOT allow service requests or file requests, they can all use the same inbound directory. The first mailer uses c:\mail1\matrix for its matrix directory and the second mailer uses c:\mail2\matrix for its matrix area. You HAVE to use different matrix areas for each mailer. To run multiple mailers, you have to decide which of the mailers is going to do the inbound processing. Inbound processing means unbundling matrix mail, echomail, processing TIC/RAID/AREAFIX requests. Only ONE mailer can do that, the rest must ignore the presents of PKT's, ECHO ARCHIVES, TICS, etc. Lets say the first mailer is going to be the one that does the inbound processing. Log into the directory that contains the 2nd mailer and run CONFIG.EXE. Select the MORE box and when the second screen comes up, set ECHOMAIL.BAT, TIC.BAT, AFIX.BAT, RAID, and UNBUNDLE MAIL to NO. This will cause the 2nd mailer to ignore the presents of TIC, RAID REQUESTS, AREAFIX REQUESTS, ECHOMAIL, and PKTS. Phoenix Technical Reference Manual Page 101 Next you have to decide WHO'S mail is going to be held for pickup by which mailer. While it WOULD be nice to allow them to use EITHER, that just isn't possible without a lot of extra code. Since this is not going to be something a lot of people do, we don't want to do that. Lets say 1.100.10.0 will get his mail from the first mailer and 1.200.5.0 will get his mail from the second mailer. Create a text file called NETCOM2.CFG and enter the following: C:\MAIL1\MATRIX 1.200.5.0 C:\MAIL2\MATRIX <EOF> The first line points to the matrix area belonging to the mailer that will be processing inbound mail. In this case, that would be the 1st mailer. The second line contains the domain address followed by the path to the Mailer's matrix area HE will be calling. In this case, the 2nd mailer. <EOF> means end of file and you don't enter that. If you had more than one, you would list each person, one to a line, a maximum of 50 lines. E.g. C:\MAIL1\MATRIX 1.200.5.1 C:\MAIL2\MATRIX 1.200.5.2 C:\MAIL2\MATRIX 1.200.5.3 C:\MAIL2\MATRIX <EOF> If you had THREE mailers C:\MAIL1\MATRIX 1.200.5.1 C:\MAIL2\MATRIX 1.200.5.2 C:\MAIL3\MATRIX 1.200.5.3 C:\MAIL2\MATRIX <EOF> Notice that NONE of the paths end with a \ ? You must use a LEGAL DOS PATH. The next step would be to create file called NETCOM.CFG. Phoenix Technical Reference Manual Page 102 This file contains; The Mailers Node number, the path to the mailer's directory, and the path to that mailer's inbound area. E.g. 1 C:\MAIL1 C:\MAIL1\INBOUND 2 C:\MAIL2 C:\MAIL2\INBOUND Notice that NONE of the paths end with a \ ? You must use a LEGAL DOS PATH. Ok, lets put all this to get so that the 1st mailer can process echomail for both lines. Eg. the ECHOMAIL.BAT file for the first mailer. NETCOM NOMAIL 1 NETCOM COPY 1 * * * Process Echomail and whatever else. * * NETCOM MOVE NETCOM RECYCLE 1 NETCOM FREE 1 <EOF ECHOMAIL.BAT> The first line, "NETCOM NOMAIL 1" tells all the other mailers that NODE 1 says NOT to process any mail, in or out. The second line, "NETCOM COPY 1" copies all the files in the inbound directories for the OTHER mailers, in this case the 2nd mailer, to the inbound directory for NODE 1. This copy does NOT overwrite existing files. If the file already exists in NODE 1's inbound directory, the copy will be skipped. This allows NODE 1 to process anything that came in on the other nodes. The lines beginning with '*' would be where you'd place your normal echomail processing instructions. The 8th line, "NETCOM MOVE" scans the matrix area, the one that was defined (first line) in NETCOM2.CFG, and moves any message addressed to anyone listed in the NETCOM2.CFG file to the matrix area on the node they are assigned to. Phoenix Technical Reference Manual Page 103 The 9th line, "NETCOM RECYCLE 1" tells all the other mailers that NODE 1 wants them to RESCAN their matrix areas to pickup any messages that "NETCOM MOVE" might have placed there. The 10th and final line, "NETCOM FREE 1" tells all the other mailers that NODE 1 said it was OK to process mail again. You would do the exact same thing for TIC, AREAFIX, and RAID requests. What about Midnight maintenance type events? With those types of events, you can't have the other lines running. Well that is where the SHUTDOWN and WAIT commands come into play. Again, only one mailer should know anything about the maintenance event. Lets say the 1st mailer, mailer was defined (config.exe) as NODE 1, will also handle external maintenance events and your event is set to exit errorlevel 50. Phoenix If errorlevel 50 goto maint * * * :MAINT NETCOM SHUTDOWN 1 * * * * NETCOM FREE 1 The First line, "NETCOM SHUTDOWN 1" tells all the other nodes that NODE 1 said to SHUT DOWN ASAP. When NETCOM issues a SHUTDOWN command, it will pause for 65 seconds to give the other nodes time to comply. The last line, "NETCOM FREE 1" tells the other nodes it is OK to go back on-line. Phoenix Technical Reference Manual Page 104 The BATCH files for the OTHER mailers would look something like THIS: :TOP PHOENIX IF ERRORLEVEL 6 goto WAIT * * :WAIT NETCOM WAIT 2 GOTO TOP When a NETCOM SHUTDOWN is received, Phoenix always exits with errorlevel 6. Trap that and jump to the label WAIT The line "NETCOM WAIT 2" instructs NETCOM to cycle until until the NODE that called for the SHUTDOWN says it is OK to go back on-line. The 2 is the NODE number you defined in CONFIG.EXE for THAT mailer. Screen Blanker Phoenix has an internal screen blanker that will blank the screen when 5 minutes has elapsed without serial port or keyboard activity. Pressing a key, any serial activity, or placing an OUTBOUND call with automatically reactivate the screen. To FORCE the screen to BLANK, press B. Consea.exe Most echomail processors support SEAdog messages, commonly referred to as MSG format. If your echomail processor supports the SEAdog .MSG format but does not support the Phoenix .MSG format you'll need to use the CONSEA.EXE program to convert the SEAdog .MSG to the Phoenix .MSG format. This should be considered as a STOP GAP approach and you should contact the author of that program and ask that he add support for the Phoenix .MSG format. To use CONSEA, create a subdirectory in your PHOENIX matrix directory called SEADOG. E.g. If your matrix directory is C:\PHOENIX\MATRIX then create the directory C:\PHOENIX\MATRIX\SEADOG Have your ECHOMAIL processor place all outbound FILE ATTACH messages in C:\PHOENIX\MATRIX\SEADOG Phoenix Technical Reference Manual Page 105 In your batch file, the one you use to process INBOUND/OUTBOUND echomail, do something like this: CONSEA * * PROCESS ECHOMAIL IN/OUT * * CONSEA You want to run CONSEA twice, once BEFORE you process echomail so that it can DELETE any SEAdog .MSG's that have already been sent. Run it AFTER you process echomail to CONVERT the new SEAdog Be forewarned. This utility is specifically FOR echomail and it WILL delete the attached file after it has been sent. Keep that in mind if you use it on SEAdog .MSG file attaches OTHER than Echomail attaches. WARNING! Do NOT under any circumstances EVER renumber the SEADOG .MSG directory. CONSEA tracks the linked messages by MESSAGE NUMBER and if you renumber, CONSEA will delete the WRONG messages. Robot ROBOT.EXE is a small program that automates the sending of files with the same name that change on a weekly or daily bases, NODEDIFS, NEWSLETTERS, REPORTS, DATABASE FILES, SPREADSHEETS, etc. ROBOT handles this by tracking the date and time stamps of each file it sends in a small database (ROBOT.DAT). Prior to SENDING the file, it checks the files date/time stamp against the one in the data base and if it is different, the file is sent. ROBOT will flag the messages as NORMAL, DIRECT, FILE ATTACH and will also tell Phoenix it is a TIC file. By telling Phoenix that it is a TIC file, you can use the special route verbs like HOLD TIC. ROBOT will also tell Phoenix not to send the MESSAGE HEADER, only the file. Phoenix Technical Reference Manual Page 106 Robot needs to know WHO to send the file(s) to and you supply that information in a control file, the name is up to you. Each line in the control file contains a single DOMAIN address. E.g. 1.200.10.0 1.300.10.0 1.400.33.2 To SEND a file, use the command line ROBOT /S <File name> <Ctrl File Name> <FILE NAME> is the name of the file to send. You can use a full path, e.g. C:\PHOENIX\WORKSHEET.SPL You can also include DOS wildcard characters, e.g. C:\PHOENIX\WORKSHEET.* ROBOT also supports two additional command line arguments, /I and /R <File Name> /I Clears the DATE/TIME stamps for every file in the database. /R <File Name> clears the DATE/TIME stamp for <File Name>. This lets you resend the same file even if the date/time stamp on that file has not changed. Getting A Test Drive Key Phoenix has THREE modes; Registered, Test Drive, and BBS Front End. Test Drive Mode In this mode, Phoenix is FULL function for a period of 31 days. At the END of the 31 day period, you must either purchase the product or stop using it. While it would be NICE to just take everyone's word that they WILL comply with the above, life just isn't that simple. To GET Phoenix to run in TEST Drive mode, you must obtain a special TEST drive key. Phoenix Technical Reference Manual Page 107 In the Phoenix package, you'll find a program called TDKEY.EXE. Move this program to your Phoenix directory and RUN it. TDKEY.EXE will generate a special SERVICE request file along with a CRASH/DIRECT file attach message to our main system. You will need to ADD a nodelist record for this system. Run NED and click on ADD. For the Address enter 99.0.0.0, the PHONE # is 1-314- 334-6359. If you do not live in North America, be sure your PHONE.CTL is set to translate the dial out phone number to the correct format. Set the SESSION type to HMS. This is important, service requests ONLY work if the session type is HMS. The contents of the other fields is not that important and you can enter anything that suits you. After you are SURE there is a nodelist record, run Phoenix and press the SPACE bar to force an immediate call. If NO call was placed, check the MATRIX area to see if the .MSG was created. If not, check your configuration, the MATRIX path is not correct. If the .MSG is there, you do not have a nodelist record for 99.0.0.0 or you did not enter the address correctly IN the nodelist record. Correct the mistakes and retry. If you just FLAT can't get it to go out, don't think anything about it. It isn't uncommon for people to have a few installation problems with new programs. If you want, you can call our BBS at the same number and get a TEST DRIVE key by typing /PDEMO at the main menu. Assuming the call was placed, you will receive a file called DEMO.RPT Despite the file extension, this IS a ZIP archive. Use the command line "PKUNZIP DEMO.RPT" to unpack the archive. Phoenix Technical Reference Manual Page 108 Inside the archive is a file called DEMO.KEY. Rename this to PHOENIX.KEY and move it to the directory you have PHOENIX set-up in. That is basically all there is to it. You'll be able to TEST drive Phoenix for 31 days. Bbs Front End Mode If you do NOT have a REGISTERED Phoenix or Your TEST Drive key has expired, Phoenix will operate in FRONT END mode. In FRONT END mode, Phoenix will not accept an inbound mail session. However, it WILL pass HUMANS to your BBS. If you do not intend to use Phoenix as a mailer, but simply to PASS HUMANS to your BBS, you are not obligated to purchase the program and may use it as long as you like. Price The introductory price for Phoenix v1.00 is 89.95. This includes all bug fixes and maintenance release. A bug fix can be identified by the last digit in the version number. A maintenance release can be identified by the second to the last digit in the version number. Major Bug Fix Digit. Revision v Digit -> X.YY ^ Maintenance Digit. Upgrading to new MAJOR revisions, $45.00. Major revisions come out every 12 to 16 months. Technical Support If you have problems, you can leave a message to the sysop on 1-314-334-6359, either Email or on the BBS. If Email, you will have to POLL for the reply. In either case, allow 36 to 48 hours (Not counting WEEKENDS or HOLIDAYS) for a reply. You may also call the voice number, 1-314-335-5384, between 10 AM and 4 PM CST (Mon-Fri). To give you the BEST help possible, our programmers pull double duty and also answer technical questions. However, there may be times when they are not available to answer the phone. If that is the case, try calling later or use the BBS. Phoenix Technical Reference Manual Page 109 File Structures Matrix Message Header struct _matrix_msg { char date[20]; char to[37]; char from[37]; char subject[72]; unsigned dgate; unsigned dnet; unsigned dhost; unsigned duser; unsigned ogate; unsigned onet; unsigned ohost; unsigned ouser; unsigned attr; /* BIT FLAG FIELDS: Determines 95 percent the messages behavior. 0x0001 DIRECT, NO ROUTING! 0x0002 HAS FILE ATTACHED 0x0004 KILL THE FILE ATTACH AFTER SENDING 0x0008 CRASH, GO ASAP 0x0010 HOLD 0x0020 ORPHAN, NEVER LOAD THIS! 0x0040 DO NOT SEND MESSAGE, ONLY THE FILE */ char reserved; unsigned type; /* BIT FLAG FIELDS: Determines the remaining 5 percent of the messages behavior and used to quickly identify the TYPE of message Phoenix is dealing with. 0x0001 JUST A FILE 0x0002 FILE REQUEST 0x0004 ECHOMAIL BUNDLE 0x0008 SERVICE REQUEST 0x0010 TIC */ char filler[126]; }; Phoenix Technical Reference Manual Page 110 Applications MUST make use of both the .attr and the TYPE bit flag settings. In other words, you MUST identify the TYPE of message. Phoenix uses the TYPE field in the Packet control system, the ROUTE manager, and the PACKER. If NO .type bit flags are set, it is understood to be just a simple message. The .attr flag 0x0040 gives you a way of telling Phoenix NOT to send the actual message. It is understood that you would only use this flag setting with FILE ATTACHES. Our TIC program, OTC, uses the .attr flag 0x0040 to keep Phoenix from sending the file attach message for the actual file being TIC'ED to the other system. Only the file attach message containing the *.TIC control file is sent. That reduces the number of do nothing messages the receiver has to content with. You do NOT have to use the 0x0040 .attr flag with the following .type flags. 0x0002 FILE REQUEST 0x0004 ECHOMAIL BUNDLE 0x0008 SERVICE REQUEST Phoenix will not send the message used to attach these TYPES of messages. If it has to, it will create and send a NULL bundle. Programmers should KEEP IN MIND that the .attr crash flag, 0x0008, does NOT bypass routing. If you do not want the message routed, you MUST use the .attr flag 0x0001. Phoenix automatically deletes the *.MSG after it has been sent. You do not have to CHECK any type of SENT flags, they aren't needed. Phoenix Technical Reference Manual Page 111 To maintain compatible with Fidonet, you must ALWAYS include the INTL, FMPT, and TOPT matrix kludges. INTL Kludge is used when Destination zone is different than Origin zone. FMPT Kludge is used when the Origin POINT is NONE ZERO. TOPT Kludge is used when the Destination point is NONE ZERO. Format for each Kludge: D=Destination, O=Origin, H=HEX 01HINTL<SPACE><DZone>:<DNet>/<DNode><SPACE><OZone>:<ONet/Onode>0DH 01HFMPT<SPACE><OPOINT>0DH 01HTOPT<SPACE><DPOINT>0DH Be sure that EACH kludge line begins with 01H and ends with 0DH. ALso make sure that you only use ONE kludge per line and that is the ONLY thing on the line. Position in the message generally isn't important, at least it isn't for any of our mailers (ISIS or Phoenix). But just to play it safe, you might want to place them BEFORE any text. Phoenix Technical Reference Manual Page 112 Phoenix.cmd struct _config { char mailer[30]; char sysop[20]; unsigned GATEid; unsigned NETid; unsigned HOSTid; unsigned USERid; int port; long baud; long lock_rate; char matrix_path[51]; char inbound_path[51]; char shell_line[51]; char use_rts_flow; int min_baud; long delay_in; long delay_out; long dial_delay; char m_in[41]; char m_out[41]; char m_dial[41]; char m_answer[41]; char offhook; int max_calls; int uart_size; char connect_strings[51][31]; long serial_rate[51]; int max_busy; long inbound_time_out; char internet[81]; char files[13]; char echomail; char fidonet; char routing_type; unsigned aka_gate[4]; unsigned aka_net[4]; unsigned aka_host[4]; unsigned aka_user[4]; char secure_addressing; unsigned char bbsnode; unsigned flag1; unsigned flag2; int unused1; int unused2; long unused3; long unused4; char unused5; char unused6; }; Phoenix Technical Reference Manual Page 113 All PATH fields will end with the trailing backslash, reduces internal processing. E.g. C:\PHOENIX\MATRIX\ If you want to use one of the "unusedX" fields for any product you plan on releasing to the general public, please contact us to make sure it isn't being used by something else. If it isn't, we will reserve that field for your application.