Beijing Paradise BBS Backup

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

/ Beijing Paradise BBS Backup / PARADISE.ISO / software / BBSDOORW / TUBS10E.ZIP / TUBS.DOC < prev next >

Wrap

Text File | 1992-10-05 | 82.0 KB | 1,912 lines

The Ultimate Byte System version 1.0 August 1992 Index Page Page Description Annual Accounts Annual Resetting of Accounts Auto TPA Update Auto Update (TPA) BBS Name Change Beta Test Sites Bytes Downloaded Today Byte Radio Bytes Left in Account Changing of Board Name Change of Name (Owner Name) Context Sensitive Help Daily Accounts Daily Bytes Daily Resetting of Accounts Editor - Security File Editor - User Account Environment Variables (Error Levels) Error Level Upon Exit Exit (Error Level) Expiration Date Expired Security Level F1 Key F2 Key Features File Ratio Future Ideas Future Updates General Description Initial Bytes Initial Bytes (Users Account) Installation Help Screens Key Functions Key File Information Last Reset Date Licence Licensing Information Lock Out Monthly Accounts Monthly Resetting of Accounts Name Change Name PWRD file PCBSetup (hints and tips) Registration of Product Resetting Accounts Reset Date (Last Reset) Resetting Field Data (Ctrl-U) Reset Flag in Users File Reset Periods Saving Data (F10) Security File Security Level Selling Key Files Serial Number Session Bytes Support BBS Information the System Manager Third Party Installation Total Bytes Downloaded Total Bytes Uploaded Total Files Downloaded Total Files Uploaded TPA Transfers of Ownership Upgrade Policies Upload Processing User Info at LOGIN User Number Version Naming Convention Weekly Accounts Weekly Resetting of Accounts Yearly Accounts Yearly Resetting of Accounts Foreword Neither this documentation nor the programs are out of beta yet, so you can expect some rough edges. Most of them will be in this documentation though, the code we have put much effort into to make as flawless as possible. This documentation was compiled quickly to allow the product to reach you in a timely manner. Please excuse this documentation release, as it will improve! I would like to take time to thank my wife and family for all the patience shown over the past months as we laboured faithfully on this project. They are a patient lot, which I am thankful for as we are going to try their patience over the next few months on other projects we are going to provide you with! I would also like to thank Fred Clark as if it were not for his work, then PCBoard would not be here today. David Terry and all the staff at CDC also have condolences coming, as they were instrumental in creating PCBoard v14.5 and beyond. You will have to forgive me for the documentation, I am used to writing technical reports, and documents. I will attempt to refrain from a too technically oriented document, while at the same time providing all the details necessary to quickly install our products. I will also attempt to provide you an easy access to all the necessary details to configure all the specific details that are important to the proper operation of this product. I would also like to take time to thank you for reviewing our product, and considering it as an option for distribution of bytes to your users. Please be so kind as to provide us with feedback as to what you think of the documentation, our product in general and its features. We consider providing you with a quality product that meets your needs of utmost importance. If this product fails to meet your needs, please let us know where we failed, what we could have done to make the product better, or why you chose not to use our product. We appreciate your time and effort in reading our documentation, and in trying our products. Please take time to read this file, and pay close attention to the operation of this system, especially in regards to the PWRD file. The improper use of PWRD file and this system can cause you some unexpected results. The PWRD settings will take control, and TUBS will NOT allot bytes to the user ! Introduction What is an Ultimate Byte System you ask ? Good question, and one that has as many answers as those who ask the question. We have attempted to meet as many of those needs as varied as possible, while still maintaining a fast, flexible and reliable method of controlling bytes for your users. We have also gone to great lengths to integrate TUBS into PCBoard as closely as possible. This includes, but is not limited to, using screen formats and displays as closely matched in layout and color as possible to the normal PCBoard displays. We will NOT display at any point to your users any form of advertisement, nor mention of our product. All of our products support the PCBoard @ color and naming conventions, and allow sysop generation of many user display screens. We have written the system completely in Borland C to obtain as much speed as possible. The system has been tested in Networking environments, and under DOS 3.3, 3.31 and 5.0. The system has been written to work correctly under DesqView, however extensive testing has not been done in this environment. We are looking for some reliable beta testers for future projects if you are interested, please fill out the enclosed form and mail it to us. We do have online beta distribution doors, allowing instant access to our latest beta code at all times. The Ultimate Byte System (called TUBS from here on) allows you to have as many different byte configurations as you have security levels. While this in itself is not unique, the fact that you can have file ratios, byte ratios, file/byte ratios, daily limits (as PCB does now), session limits (amount allowed each logon), weekly limits, monthly limits or annual limits to name a few of the combinations gives you a flexibility never before available to PCBoard Sysops. While the flexibility is only limited by your imagination, you can give a user a weekly limit for example, and let them use it at their convenience. A non pay system can have upload ratios as well as daily, weekly, monthly or yearly bytes distributed to their users. A pay board can now sell bytes, and have byte accounts to allow a better control over file leaches. At least if a file leach wants files they will have to pay for the bytes. A board can use both account bytes and upload/download ratios at the same time. Allowing a user a limited number of bytes free each month for example, (ie: give a user 4 meg per month, when it is finished the remainder of the month period will run on ratio alone or wait until the start of the next month period) The system is flexible enough that only your imagination can hold you back on the bytes configuration and account configurations available to you. All this is accomplished using absolutely NO events, this ensures that your users will get their bytes accurately all the time and every time. Users bytes will adjust upon expiration level as defined by the SysOp, each user is completely configurable by the SysOp! Now YOU have total and complete control over who gets bytes, how many, and when. There are a few items worth noting though, if a user downloads files which abort transfer, and it is not counted by the system as a successful transfer, then TUBS will NOT take these bytes away from the user, which is only logical. As the system does not use events, we had more flexibility, and as a result, have chosen to have the accounts reset upon actual week, month, and year lengths rather than calendar weeks, months and days. This means if a user starts using the system on August 6th 1992, which will be a Thursday, then their week will reset on Thursdays, their month will fall on the 6th of the month, and the year end will fall 12 months later or on August 6th, 1993. Overall, we felt this led to better control of accounts, and more flexibility on the part of the sysop. Not to mention a more fair distribution of bytes to your users. While every attempt at accuracy has been made, this manual may have some details that may not reflect exactly what you see in your current version of TUBS. This is because the documentation is written after the programming and debugging phases, and usually will be a short period of time behind the actual release of any code. We will include update files, and history files with future releases to identify any changes to the current release that may not be included or may be different that as described in the documentation. TUBS is not freeware nor is it public domain software, but is commercial software. All documentation, source code, programs and file structures are copyrighted and remain property of Platinum Software. File Version Convention While not difficult I will mention how our file name is set up. A typical Beta version # may look like. The Ultimate Byte System System Manager Version 1.0ß3.7 This would be a Beta release of version 1.0. The numerals prior to the beta (ß) symbol are the actual code version number, and will not change during the release of this code version. The numbers after the beta (ß) symbol are the actual beta release version. Beta release versions have minor and major numerals such as the 3.7 in above sample. Every change to the working code will render a new beta number, every bug fix, addition or deletion will increase the minor number by one. Additions to the codes features will usually be a major beta version increase. This will allow you during the beta cycle to accurately track our current version that is being released, and to keep the latest code online. Once the code is released into production, then the beta symbol and beta numerals will be removed from the code. Planned production release is early October of this year. Disclaimer Ok, lets get through the legal stuff up front. Platinum Software, or any of its associates are not liable for any damages suffered as a result of use of this software, either by proper use or improper use. We assume no liability for any losses incurred, either financial or otherwise as a result of use of this software. We hold no responsibility for your inability to use this software due to your hardware configurations, software configurations, or any other reason not mentioned in this document. This software has been tested at our sites, and is being distributed in a beta format. You agree to assume full responsibility for any consequences incurred as a result of use or misuse of this software. Features o Allows Daily Accounts (similar to PCBoard accounts using PWRD file) o Corrects problem with midnight rollover and loss of bytes o Allows Monthly Account Bytes User has preset byte limit for month rather than day o Allows Annual Account Bytes User has preset byte limit for year rather than day o File Ratio Accounts with definable ratios o Byte Ratio Accounts with definable ratios o File and Byte Ratio together with definable ratios o Upload credits allowable to non ratio users. This will credit user with uploads who are not on ratio accounts, but on Monthly or Annual accounts. o Lock Out of specific users o Default settings of Session Bytes, Daily Bytes are security specific. o Individual users can be set different than their specific security level. o Base Baud rate and Factoring allows flexible control on bytes allocated based upon current session baud rate. o Allows greater control over Display User Info at Login o If user is found in PWRD, TUBS will honor PWRD setting. o Byte ratio can be calculated on Session Bytes or Actual Ratios o No need for DEPOSIT doors on Monthly or Annual Accounts for byte storage. o Runs automatically and is completely maintenance and event free. o Demo File will allow 60 days free usage o Demo Key does not need to be downloaded from support board ! o SysOp definable display screens o Complete integration into PCBoard, transparent to user o Can run with some user on TUBS and others on PCBoard's PWRD or other file control system. o Automatic control over accounts upon user expiration o Automatic Update possible for sysop changes in Security file This allows one change to the Security file, and all users of that specific level will change. (User switch to disable this on user basis) o Small Code, allows shelling to TUBS. Executes very fast, making it appear invisible to users. o Daily Limits can be enforced by security level, or can be disabled, relying on session limits only. o Session Limits, allow control on per session limit, while allowing Daily limits to be higher. (for monthly or annual accounts you may wish to disable daily limits) o Maintains full PCBoard security on files. o Allows PCBoard to have full control over FREE files via the normal FSEC file. Description A system allowing maximum flexibility in the distribution of bytes possible. Byte accounts are limited only by SysOps imagination ! The most flexible byte distribution system on the market today. We have been running this code for several months on both single node and multi-node (PCBoard /U) systems, with no user complaints, nor loss of bytes to any users. We feel the safeguarding of users bytes is sacred, and have taken every precaution to ensure your users neither loose bytes, nor are given wrong amounts of bytes. There are very few reasons the bytes will not be allotted to the user, and all are system failures on the part of PCBoard or hardware, or are SysOp configuration errors. If a user for whatever reason looses download information and PCBoard does not count the download as successful, then we will not subtract the bytes. All byte removal and additions are controlled by PCBoard's calculations. Quick Installation For quick installation see the installation section in this document file, or enclosed file QUICK.DOC. Key Functions The following table list key functions available in the System Manager. F1 Help (Context sensitive - not in Beta release) F2 Help (Generic Help) Up Arrow Up to next field above current location Dn Arrow Shift TAB Moves to previous field TAB Moves to next field ENTER Moves to next field ESC Discard any changes made in current session. You will be challenged when pressing ESC key. Will return to previous menu, or abort program depending upon level. PgUp Move between screens (Up) Will NOT write to file with Security File editor. TPA editor will write changes to file. PgDn Move between screens (Down) Will NOT write to file with Security File editor. TPA editor will write changes to file. F10 Will save current record, and exit to menu Ctrl Home First field on screen Ctrl END Last field on screen Ctrl U Undo Key - will undo the current field Ctrl - U will work on any field on current screen, however after using PgUp or PgDn, the Ctrl-U will not undo information automatically on screen. Insert Toggles between Insert and Overtype mode. Cursor will be underline in overtype and block in insert mode. Home Beginning of current field END End of text in current field Right Arrow Right one character in current field to end of field. Will NOT move to next field upon reaching end. Left Arrow Left one character in current field to beginning of field. Will NOT move to previous field upon reaching beginning of field. Ctrl Right Moves right one word in current field Ctrl Left Moves left one word in current field Backspace Backspaces one character Delete Deletes current character Ctrl Y Deletes from current position to end of field Ctrl T Deletes word to right (or from current position to end of current word) Ctrl Backspace Deletes word left. (or from current position to beginning of current word) Alt Rt Arrow Moves right one field, will roll around at end of screen. Alt Lft Arrow Moves Left one field, will roll around at beginning of screen. Resetting Data to Default Value If you wish to reset one or any number of fields while in a single screen, move the cursor to the field to be reset. While in the field to be reset, press CTRL-U, the original value will be returned to the field. This can be done as many times as you wish as long as you stay within the one security screen display. If you have changed screens (PGUP or PGDN) then the values are semi-permanent, and will have to be reset manually, or the changes can be aborted prior to save. Saving Data Upon moving from one screen to the other, the data will be saved in a temporary buffer area, however will not be saved to disk until you press F10 to save. Upon pressing ESC to exit, you will be warned of a possible loss of data, and asked if you wish to proceed. ╔══════════════════════════[ Security File Editor ]═══════════════════════════╗ ║ ║ ║ Base Fac File Byte R U R D ║ ║ Usr Initial Session Daily Baud 1/ Ratio Ratio T L s s ║ ║ Lvl Bytes Bytes Bytes Rate 100 ?:1 ?:1 P t p ║ ║ ║ ║ 1 0 0 0 0 0 0 0 N N N N ║ ║ 2 0 0 0 0 0 0 0 N N N N ║ ║ 3 ┌─[ Abort ]─────────────────────────┐0 0 0 N N N N ║ ║ 4 │ Are you sure you want to abort? N │0 0 0 N N N N ║ ║ 5 └───────────────────────────────────┘0 0 0 N N N N ║ ║ 6 0 0 0 0 0 0 0 N N N N ║ ║ 7 0 0 0 0 0 0 0 N N N N ║ ║ 8 0 0 0 0 0 0 0 N N N N ║ ║ 9 0 0 0 0 0 0 0 N N N N ║ ║ 10 0 0 0 0 0 0 0 N N N N ║ ║ 11 2000000 500000 800000 2400 100 1 1 N Y N N ║ ║ 12 0 0 0 0 0 0 0 N N N N ║ ║ 13 0 0 0 0 0 0 0 N N N N ║ ║ 14 0 0 0 0 0 0 0 N N N N ║ ║ 15 0 0 0 0 0 0 0 N N N N ║ ║ 16 0 0 0 0 0 0 0 N N N N ║ ║ ║ ╚════════════════════[ The Ultimate Byte System V1.0ß3.7 ]════════════════════╝ Figure 1 Acceptable key inputs are ASCII characters from 32 to 254 except where fields are prompting for specific input. Bytes System Manager Utility to control security specific information. Session Bytes, Daily Limits, Base Baud Rate, Ratio Information, etc. Also, allows control over individual user information, account bytes, etc. We have considerable amounts of information on the screen in the Security Editor, and are open to suggestions on what a better implementation may be. We will listen to all suggestions, and will decide ourselves what the best suggestion is, and may be implemented. System Manager Introduction The Bytes System Manager open screen provides you with one of three options. You can move between the options by using the arrow keys to move up or down, or by simply pressing the first letter in the desired menu option. The highlighted option will be selected by pressing the <ENTER> key. See Figure 2 for an example of the System Manager Screen. The Ultimate Byte System System Manager Version 1.0ß3.7 ╔═════════════════════════════╗ ║ Main Menu ║ ║─────────────────────────────║ ║ ║ ║ Security File Editor ║ ║ TPA Editor ║ ║ Exit T.U.B.S. SM ║ ║ ║ ║ ║ ╚═════════════════════════════╝ Platinum Software Development Copyright (C) 1992, All Rights Reserved Figure 2 ╓─────────────────────────────────────────────────────────────────────────────╖ ║ Security File Editor ║ ║ This option will allow editing of the Security file data, ║ ║ which includes items such as Security Level, Initial Bytes, ║ ║ Session Bytes, Daily Bytes, Base Baud Rate, File Ratio, ║ ║ Byte Ratio, etc. ║ ║ ║ ║ See the section on Security File Editor below. ║ ╟─────────────────────────────────────────────────────────────────────────────╢ ║ TPA Editor ║ ║ This option will allow editing of individual user accounts, ║ ║ locking individual users out of the door, etc. ║ ║ ║ ║ See the section on User File editing below. ║ ╟─────────────────────────────────────────────────────────────────────────────╢ ║ Exit T.U.B.S. SM ║ ║ Exit the system manager to DOS, this function is the same ║ ║ as pressing the ESC key. ║ ╙─────────────────────────────────────────────────────────────────────────────╜ Security File The security file is edited using BYTESM.EXE, and contains all of the non user specific control information. The fields going from left to right are : Serial Number of Row: This serves no purpose other than to let you know where you are in the security table. This does not correlate in any way to the security levels, nor do the security levels need to be in ascending order, or any specific order at all. Updating Security File Figure 3 is an example of the Security File Editor Screen with one security level filled in. ╔══════════════════════════[ Security File Editor ]═══════════════════════════╗ ║ ║ ║ Base Fac File Byte R U R D ║ ║ Usr Initial Session Daily Baud 1/ Ratio Ratio T L s s ║ ║ Lvl Bytes Bytes Bytes Rate 100 ?:1 ?:1 P t p ║ ║ ║ ║ 1 0 0 0 0 0 0 0 N N N N ║ ║ 2 0 0 0 0 0 0 0 N N N N ║ ║ 3 0 0 0 0 0 0 0 N N N N ║ ║ 4 0 0 0 0 0 0 0 N N N N ║ ║ 5 0 0 0 0 0 0 0 N N N N ║ ║ 6 0 0 0 0 0 0 0 N N N N ║ ║ 7 0 0 0 0 0 0 0 N N N N ║ ║ 8 0 0 0 0 0 0 0 N N N N ║ ║ 9 0 0 0 0 0 0 0 N N N N ║ ║ 10 0 0 0 0 0 0 0 N N N N ║ ║ 11 2000000 500000 800000 2400 100 1 1 N Y N N ║ ║ 12 0 0 0 0 0 0 0 N N N N ║ ║ 13 0 0 0 0 0 0 0 N N N N ║ ║ 14 0 0 0 0 0 0 0 N N N N ║ ║ 15 0 0 0 0 0 0 0 N N N N ║ ║ 16 0 0 0 0 0 0 0 N N N N ║ ║ ║ ╚════════════════════[ The Ultimate Byte System V1.0ß3.7 ]════════════════════╝ Figure 3 Security Level of User (Usr Lvl) Current Security Level of user, when user security level matches, the fields associated with this level will be applied. Initialization Bytes (Initial Bytes) Bytes Account will be initialized with. Session Bytes (Session Bytes) This value is the default amount of bytes given to a user limited by some conditional values. #1 ) Base Baud rate, as mentioned below can increase or decrease this value. See Base Baud Rate #2 ) Factoring Value - as mentioned below can affect this value. #3 ) Daily Limits CAN NOT be exceeded, if they are lower than session bytes, or some bytes have been already downloaded today then daily limits will be honored. IF DAILY LIMITS IS SET TO 0, THEN IT IS ASSUMED THAT DAILY LIMITS WILL NOT BE ENFORCED. See also Daily Limits. #4 ) If Real Ratio is set, then the actual ratio is given rather than session bytes. NOTE: If Real Ratio is larger than session bytes or daily bytes, then both session and daily bytes will be imposed upon the limits. See also Daily Bytes, Session Bytes or Real Ratios. #5 ) If File Ratio and/or Byte ratio is set, and ratios are NOT in line, then zero bytes will be granted, regardless of session bytes. Example of session bytes with Base Baud rate and Factor Value: (Session Bytes * ((Current Baud Rate/Base Baud Rate) * (Factor Value/100))) ie: (1000000 * ((9600/2400) * (200 (factor)/100))) 1000000 * (( 4 ) * ( 2 )) 1000000 * 8 = 8000000 or -----> (1000000 * ((2400/2400) * (200 (factor)/100))) 1000000 * (( 1 ) * ( 2 )) 1000000 * 2 = 2000000 or -----> (1000000 * ((300/2400) * (200 (factor)/100))) 1000000 * (( .25 ) * ( 2 )) 1000000 * .5 = 500000 Now, set as 2:1 seems useless, however if factor is set to 125 for example, then it would be easier to use than say an odd baud rate in base baud rate. ie: (1000000 * ((9600/2400) * (125 (factor)/100))) 1000000 * (( 4 ) * ( 1.25 )) 1000000 * 5 = 5000000 or -----> (1000000 * ((2400/2400) * (125 (factor)/100))) 1000000 * (( 1 ) * ( 1.25 )) 1000000 * 1.25 = 1250000 or -----> (1000000 * ((300/2400) * (125 (factor)/100))) 1000000 * (( .125 ) * ( 1.25 )) 1000000 * .25 = 156250 Daily Bytes (Daily Bytes) This value WILL NOT be exceeded in one calendar day, regardless of other settings or values. IF DAILY LIMITS IS SET TO 0, THEN IT IS ASSUMED THAT DAILY LIMITS WILL NOT BE ENFORCED. This does not normally have the same limitations as PCBoard's bytes limits on midnight roll over ! However, these same limitations can apply in certain situations, although they are unlikely. This means you should be able to let a user go past midnight, and still get full bytes the following day ! Base Baud Rate (Base Baud Rate) This is similar to the Base Baud rate as in the PCBoard PWRD file. If the Base Baud rate is set at 2400 baud, and a user logs in using 4800 baud, twice the bytes will be allotted for that session. ( the above is affected as well by the Factoring Value, as mentioned below ) Session bytes are doubled, tripled, etc using the Base Baud rate values. NOTE: Daily Limits are STILL enforced for all accounts, regardless of settings of Base Baud rates or Factoring Values. ( Unless Daily Limits are disabled by a zero setting ) Factoring Value for Base Baud Rate (Fac 1/100) A mathematical factoring value for base baud rate. This is a new concept to base baud rate, and allows you the sysop a better control over base baud rate than previously available. This is set in 1/100ths, meaning a value of 100 is equal to 1, a value of 125 is equal to 1.25 in mathematical terms. If the base baud rate is 2400 baud and the base baud rate is 0 (zero) or 100, then the factoring is done as done by PCBoard. As an example, if a user gets 100K at 2400 baud they would get 200K at 4800 baud, 400K at 9600 baud, etc. If however a 300 baud user was online, they would get only 12.5K or 1/8th the value of 100K. Factoring adds a new twist and multiplies or divides by the factor rate, rather than just by one as is the normal case. With factoring set to 200 (200/100ths) then the same user above at 2400 baud would still get 100K. However, a 4800 baud user would get 400K and a 9600 baud user would get 800K. Inversely, a 1200 baud user would get only 25K and a 300 baud user would get only 6.25K. This feature encourages higher speed and penalizes lower speeds to a greater degree. Display (Dsp) If turned ON the Display User Information at Login is handled by the TUBS door. If turned OFF the Display User Information at Login is disabled in TUBS. File Ratio (File Ratio ?:1) This is the ratio required for the File Ratio to be enforced at. If set to 2:1 you will be granting two files for every one file received. If set to 1:1, you will be granting one file for every file given. A word on the side, our ratio system will run smoothly and cause no grief or be caused no grief if you are using PCBoard's UPCRED or BYTECRED flags for instant credit. Bear in mind however that PCBoard's credits will apply to ALL users, and TUBS will only credit based upon user levels in security file. Bytes will be granted based upon Session Bytes as listed in the security file. Session bytes and Daily limits will be honored in all ratio systems. For Real Ratios see Real Ratio further down in this documentation. Byte Ratio (Byte Ratio ?:1) This is the ratio required for the Byte Ratio to be enforced at. If set to 2:1 you will be granting two bytes for every one byte received. If set to 1:1, you will be granting one byte for every byte given. A word on the side, our ratio system will run smoothly and cause no grief or be caused no grief if you are using PCBoard's UPCRED or BYTECRED flags for instant credit. Bear in mind however that PCBoard's credits will apply to ALL users, and TUBS will only credit based upon user levels in security file. Bytes will be granted based upon Session Bytes as listed in the security file. Session bytes and Daily limits will be honored in all ratio systems. For Real Ratios see Real Ratio further down in this documentation. Upload Processing (ULP) This is a somewhat critical flag, and should be used only after reading this documentation. The ULP flag will NOT provide for upload/download ratios, but will instead credit additional bytes in the user account for new uploads. The Byte Ratio is still used for the upload credit, however the actual ratio is NOT considered at all in the calculations. This provides for boards with Monthly or Annual accounts to reward users for uploads. This provides boards that call out long distance to gather files themselves, and have pay members, to in effect 'pay' or reward members for contributing the system. This flag should be used with some degree of caution however, as some users will upload any and all files to obtain additional bytes. This problem should not be as severe in this case as with true ratio systems however, as users are just obtaining 'additional' bytes. Reset Periods: (Rst) This flag can be set to either N, D, W, M or Y for Not used, Daily, Weekly, Monthly or Yearly. The system will reset account bytes to initial bytes as defined in the security file for users security level based upon this flag. The interval period for this flag is per user, and is calculated from the time the user first started using the TUBS system. Yearly If set to "Y" for yearly resets, the account bytes will be reset to initial bytes on the annual anniversary of the date shown as last reset date. This is not based upon a day of the week, such as Sunday or Monday, but rather on the day the initial login or last reset was done. This can be affected by either modifying the last reset date. Monthly If set to "M" for yearly resets, the account bytes will be reset to initial bytes on the monthly anniversary of the date shown as last reset date. This is not based upon a day of the week, such as Sunday or Monday, but rather on the day the initial login or last reset was done. This can be affected by either modifying the last reset date. Weekly If set to "W" for yearly resets, the account bytes will be reset to initial bytes on the weekly anniversary of the date shown as last reset date. This is not based upon a day of the week, such as Sunday or Monday, but rather on the day the initial login or last reset was done. This can be affected by either modifying the last reset date. Daily If set to "D" for yearly resets, the account bytes will be reset to initial bytes on a daily basis. The results of this can not be adjusted, as last reset date is set each time online, and the reset takes place daily. Daily accounts will however not normally have the midnight rollover loss of bytes associated with PCBoard ! As a matter of fact, a user could be granted both days bytes during one login if so desired. The SysOp would have to let the user know this was possible, and how to accomplish it. This flag makes T.U.B.S. operate exactly the same as PCBoard's PWRD file with the added flexibility of upload credits for a specific security level, while not affecting the other levels, as UPCRED or BYTECRED would do. PWRD File VERY IMPORTANT !! If users security level has any information other than zero bytes in the PWRD file, then TUBS will ignore the user, and allow them to have the same bytes as indicated in the PWRD file. TUBS will also display the bytes allowed in this session for the user as provided by the PWRD file. ( NOTE : TUBS will ONLY display the user info if the "Display User Info at Login" is set to NO in PCBOARD.DAT, and the Display User Info is set to YES in the TUBS Security File. ) See Display User Info section in this documentation for more detailed explanation. Display User Info It is recommended that if you use the "Display User Info at Login" in PCBSetup (Options #1 - top right hand side of screen), that it be set to NO. If Display User Info is set to NO, then TUBS will display all the necessary information, and will appear seamlessly as a part of PCBoard. If Display User Info is set to YES, there are possible situations where the PCBoard display and the TUBS display will be separated by the system. This will cause an uneven flow to your screen display, making a somewhat less desirable display to the user. If you want NO display at all, set the Display User Info in the Security File to NO for that specific security level. ( see Display {Dsp}) The User Info displayed in TUBS will display all the data as shown by PCBoard, plus ratio information if used for the specific user, bytes in account, bytes in session, and reset frequency if specified. NOTE : It is not recommended that both displays be used at once. We do recommend for clean displays, and a cleaner interface to PCBoard that the Display option in the security is the ONLY one that is used. File Ratios File and Byte ratios are provided for the user and are configurable by the SysOp. The SysOp can adjust the ratio required (1:1, 2:1, 3:1, etc) to be maintained by the File Uploads. This provides a File Ratio Enforcement as well as a bytes distribution system. If the Files are in line then the Session bytes are given to the user. ( this can be over ridden by the daily bytes field, based upon the daily bytes setting, and total bytes downloaded by user today ) If the File Ratio Fails, FILEFAIL will be displayed to the user, and zero bytes will remain for session. We have included @WAIT@ in the demonstration file to keep the screen displayed for the userr Byte Ratio File and Byte ratios are provided for the user and are configurable by the SysOp. The SysOp can adjust the ratio required (1:1, 2:1, 3:1, etc) to be maintained by the Byte Uploads. This provides a Byte Ratio Enforcement as well as a bytes distribution system. If the Bytes are in line then the Session bytes are given to the user. ( this can be over ridden by the daily bytes field, based upon the daily bytes setting, and total bytes downloaded by user today ) If the Byte Ratio Fails, BYTEFAIL will be displayed to the user, and zero bytes will remain for session. We have included @WAIT@ in the demonstration file to keep the screen displayed for the userr See Real Ratio below. NOTE : If both File Ratio and Byte Ratio are set, both levels MUST be maintained by the user for any bytes to be allocated in session. In all cases the daily bytes will control maximum for day if daily bytes is set. Ratio Type: This flag allows defining ratio calculation type. There are three valid values. ( N/S/R ) N flag disables the ratio system for all users of specific security level. S flag sets ratios at Session Ratios for users of specific security level. R flag sets ratios at Real Ratios for users of specific security level. Session Ratios : ( S setting in RT ) Session Ratios will distribute bytes based upon setting in Session Bytes. If ratios are in line, the full session bytes will be allotted to the user, provided the daily flag is either NOT set, or user has not used total daily allotment. Daily Download Bytes will still control overall bytes per day unless this setting is set to zero, in which case Daily Limits will be disabled. Real Ratios : ( R setting in RT ) This option was provided to give you the ultimate in flexibility ! Now you can have bytes allocated on File/Bite ratio based upon the actual ratio rather than the allocated amount in session and daily limits. This option still requires the ratio to be in line prior to allotting bytes to the user. Real Ratios will distribute bytes based upon the following formula and conditions. First, all File and/or Byte ratios MUST be in line as set out by the SECURITY file. If BYTE ratio is NOT used, then Real Ratio WILL NOT function. Bytes under Real Ratio will be distributed using the following formula. ( Total Bytes Uploaded * Byte Ratio ) - Total Bytes Downloaded This means if a user has uploaded 100,000 bytes and has downloaded 100,000 bytes, with the ratio set at 2:1, then the following would be the bytes allocated. ( 100,000 * 2 ) - 100,000 = (200,000) - 100,000 or 100,000 bytes remaining. Or if a user uploaded 350,000 bytes, downloaded 500,000 bytes, using a ratio of 5:1.. Then .. ( 350,000 * 5 ) - 500,000 = 1,250,000 bytes remaining ! NOTE : All bytes allocated under Byte Ratio and/or File Ratio using either Session Bytes or Real Ratio system will comply with session byte and daily byte limits. This means that in the above situation of 1.25 meg remaining, if the session bytes were set at 800K and the daily bytes were set at 2 Meg. The user would be allotted 800K upon first login of the day, and would continue to get 800K or the Daily limit of 2 meg less daily download bytes until the daily maximum was reached. If ONLY the byte setting is used this can be used in a fashion we call Actual Ratios. The File Ratio is NOT considered in the calculation or allotment of bytes, therefore : if a user uploads 100K and downloads 300K with a ratio of 3:1, they would be allotted (100000 * 3) - 300000 = 0 bytes or if they uploaded 150K and download 300K they would be allotted (150000 * 3) - 300000 = 150000 bytes. Upload Credits on Byte Accounts When Upload processing is turned on, any user who uploads bytes will be granted additional bytes in their account. This factor is adjusted by the byte ratio. Example : A user has 750,000 bytes remaining in their account, with a ULP flag set and byte ratio set at 3:1. They have just uploaded a 325,000 byte file. Their account now will contain 750,000 + ( 325,000 * 3 ) or 1,725,000 bytes. Figure 4 is a more extensive example of a Security Editor Screen with various examples. I shall attempt to explain in detail the differences with each security level, and how changing a flag can affect the bytes in a users account. ╔══════════════════════════[ Security File Editor ]═══════════════════════════╗ ║ ║ ║ Base Fac File Byte R U R D ║ ║ Usr Initial Session Daily Baud 1/ Ratio Ratio T L s s ║ ║ Lvl Bytes Bytes Bytes Rate 100 ?:1 ?:1 P t p ║ ║ ║ ║ 81 2000000 800000 800000 0 0 0 0 N N N N ║ ║ 82 0 800000 0 0 0 0 0 N N N N ║ ║ 83 0 800000 1600000 0 0 0 0 N N N N ║ ║ 84 0 800000 0 2400 200 0 0 N N N N ║ ║ 85 0 800000 0 0 0 2 0 S N N N ║ ║ 86 0 800000 0 0 0 0 2 S N N N ║ ║ 87 0 800000 0 0 0 2 2 S N N N ║ ║ 88 0 800000 0 0 0 2 2 R N N N ║ ║ 89 2000000 800000 0 0 0 0 0 N Y N N ║ ║ 90 2000000 800000 0 0 0 0 2 N N D N ║ ║ 91 10000000 800000 0 0 0 0 0 N N W N ║ ║ 92 50000000 800000 0 0 0 0 0 N N M N ║ ║ 93 500000000 800000 0 0 0 0 0 N N Y N ║ ║ 94 2000000 800000 0 0 0 0 0 N N N Y ║ ║ 95 0 800000 1000000 0 0 2 2 S N Y Y ║ ║ 96 2000000 1000000 2000000 0 0 0 0 N Y D Y ║ ║ ║ ╚════════════════════[ The Ultimate Byte System V1.0ß3.7 ]════════════════════╝ Figure 4 Explanation of levels in Figure 4 ║ ║ ║ Base Fac File Byte R U R D ║ ║ Usr Initial Session Daily Baud 1/ Ratio Ratio T L s s ║ ║ Lvl Bytes Bytes Bytes Rate 100 ?:1 ?:1 P t p ║ ║ ║ ║ 96 2000000 1000000 2000000 2400 200 0 0 N Y D Y ║ I will attempt to go into some detail of the security file fields, and give some examples of each. ║ 81 2000000 800000 800000 0 0 0 0 N N N N ║ Security level of 81, Initialation bytes of 2 megs. Each session will be granted 800 K, if available. With an absolute daily limit of 800 K. ║ 82 0 800000 0 0 0 0 0 N N N N ║ No initial bytes granted, SysOp must grant bytes. Each session 800K will be granted, if available, and there are no daily limits set on this account. ║ 83 0 800000 1600000 0 0 0 0 N N N N ║ Again, no initial bytes, however there is a 1.6 meg limit placed on daily bytes permitted. ║ 84 0 800000 0 2400 200 0 0 N N N N ║ This provides us with 800K session bytes, with no daily limit. However the bytes will also be adjusted based upon the base baud rate of 2400 baud and a factor value of 2. ║ 85 0 800000 0 0 0 2 0 S N N N ║ A session bytes of 800K will be granted if the file ratios are in line, which is set at 2:1. Session bytes are used as RT is set to S. ║ 86 0 800000 0 0 0 0 2 S N N N ║ Same as above, except Bytes are checked for ratio rather than files. ║ 87 0 800000 0 0 0 2 2 S N N N ║ Yet another ratio example, with both files and byte ratios required to be in line for session bytes to be allotted. ║ 88 0 800000 0 0 0 2 2 R N N N ║ Similar to above except real ratios are distributed rather than session bytes. ie: If 800 K is uploaded, and 1 meg downloaded bytes distributed in this session would be. (800 * 2) - 1000000 = 600 K ║ 89 2000000 800000 0 0 0 0 2 N Y N N ║ This account has 2 meg in initial account, with 800K per session and no daily limit. Upload Processing is initiated, meaning the user will be granted two bytes in their account for each byte uploaded. See the Byte Ratio for multiplier value of ULP. ║ 90 2000000 800000 0 0 0 0 2 N N D N ║ A bit more complicated ! This one provides 2 meg initial bytes, with 800K per session. There are no daily limits, however when this user runs out of the 2 meg they are on Byte ratios at 2:1. This account is reset to the full two meg in the account on a daily basis. ║ 91 10000000 800000 0 0 0 0 0 N N W N ║ Similar to above account with 10 meg in initial account, 800K per session, and no daily limit. There is no upload credit or byte ratio provided, however the account is reset weekly. ║ 92 50000000 800000 0 0 0 0 0 N N M N ║ This provides 50 meg per user, with 800K per session, and is reset monthly. ║ 93 500000000 800000 0 0 0 0 0 N N Y N ║ This provides 500 meg on initialization, with 800K per session and an annual reset period. ║ 94 2000000 800000 0 0 0 0 0 N N N Y ║ A 2 meg initial bytes, 800K per session, and no daily limits. This account will display user info at login however. ║ 95 0 800000 1000000 0 0 2 2 S N Y Y ║ This account will provide a session bytes of 800K if files and bytes ratios are in line. (session is under RT). Display is on at login. And a daily 1 meg limit is set. The Yearly reset has no effect as there are no initial bytes set. ║ 96 2000000 1000000 2000000 0 0 0 2 N Y D Y ║ A two meg initial bytes, reset daily, with a 1 meg session and 2 meg daily limit. This account also credits for uploads on a two to one ratio. Deposit Doors : While we do not wish to take away from Deposit Doors, they may become redundant with our system in place. Depending upon how your users are given bytes a Deposit Door is not necessarily needed. I personally do still run Cam DeBucks Deposit Door however, providing certain users the ability to store only time, other the ability to store bytes and time, and still others no storage at all. If the user is configured with the Initial Bytes the same as you would like for a daily limit, and reset is set to DAILY, then a Depository Door will operate the same as it does for PCBoard. If a user is set for Annual bytes for example, a depository door is not needed. However the user of a depository will not seriously cause any problems to any account regardless of how it is set up. Once the bytes are stored in the deposit door they will be removed from the user account for that session. It will be possible in theory however to gain the maximum amount allowed in the deposit door as extra bytes above those in the users account. This would be done by waiting to expire, keeping full bytes in the account, and then withdrawing the bytes. This will be rectified if you set the expired security level in the deposit door to remove the bytes upon expiration of the users account. However, some deposit doors do not properly use the expired security level after the expired date, but continue to user the normal level. This can be prevented if you run PCBSM in an event and copy expired into the normal security area. TUBS will look at both security levels, and use the proper one based upon the expiration date found in the users file. NOTE : Some Depository Doors and some other doors will leave the user with zero bytes upon exiting. I have not found a good way around this yet, however am working on it. Other doors such as QMail, RoseMail, etc will enter and exit maintaining bytes properly. By simply joining another Conference, or by reopening TUBS the bytes are returned. As joining another Conference will regain the lost bytes, I am not sure what these doors are doing that some other doors do not. When we determine exactly what these doors are doing wrong, then we will attempt to rectify it. Bytes Door Installation: For experienced sysops, TUBS is a easy door to install, with no maintenance files or configuration files necessary! Although TUBS uses a TPA, you will find this is one of the best used TPAs you may ever install. Many other TPA programs are simply not used by many or even the majority of users, making the extra bytes redundant. TUBS on the other hand, uses only 32 bytes per user, and bytes are something that virtually every user on your system will utilize. You will have to set up a TPA by using PCBSM.EXE. Note that on a multi-node system ALL nodes must be down for this operation. PCBSM will generate a backup users file in this operation, however you may wish to have another backup offline just in case. Enter PCBSM, choose menu option "Add/Remove Third Party Application" to generate a new TPA. For TPA information use TPA Name : TUBS Version : 100 Static Size : 32 Dynamic Size : 0 Keyword : BYTES the keyword must match the name of the door in your DOOR.LST file For verify that the data structure corresponds to the current version of TUBS, we have chosen a version number of 100, corelating to v 1.00. Press PGDN to generate your TPA. o Please ensure that your environment variable PCBDAT is set. If not please put in your autoexec.bat SET PCBDAT=(drive\path\pcboard.dat) ie: SET PCBDAT=C:\PCB\PCBOARD.DAT You will now need to make some changes using PCBSetup. The first will be creating a door, this may be necessary in more than one conference, although each conference may point to the same door. Depending upon your setup, only the Main Door changes may be necessary, only you as a SysOp can determine that. It WILL however be necessary from every Conference that you wish the user to have access to it. It is highly recommended that it is at the very minimum available from the Main Conference, as well as ALL other Conferences that have auto rejoin upon login set to YES. Batch File Example of batch file : @ECHO OFF CD \DOORS\TUBS BYTES ** Note : Do not reload PCBoard, as this is a shell door. Door Installation Using PCBSetup choose the DOOR.LST file to edit. File Pass Sec Login USER.SYS DOOR.SYS Batch Path BYTES 0 Y Y N C:\DOORS\TUBS In the above example, we show pathing to the batch file, this would be placed in the C:\DOORS\TUBS directory. (or other directory as you have chosen) By doing this you save multiple doors for each node. NOTE: If you have other auto-login doors, you will need to modify them, or adjust BYTES to accommodate your plans for login. We have adapted our autologin door to accommodate branching for different users as necessary. If you need help in this area, please let us know on the support board, or in one of the mail networks we carry. PCBSetup Configuration : It is highly recommended that you disable the "Display User Info at Login" with PCBSetup in Options #1 screen. This will make a much more pleasing display for your users. Example of possible Screen displays to User User Information Editing User Number : This corresponds directly with the user number as defined in the PCBoard Users file. Name : This is the users name as found in the PCBoard USERS file. Security Level : Security level as in PCBoard USERS file. Expiry Date : Users Expiry Date. Expired Security Level : Users expired security level. Last Reset Date : The date the last automatic reset or initialation was done on this account. Locked Out : User is unable to obtain bytes from this system. SysOp has chosen to disallow bytes. Most of the users information display will be hidden from the display. Auto TPA Update : This will ensure that the users account is adjusted automatically if the users security file information changes. Use with caution, as if you set initial bytes manually for example, they will be reset to the security file defaults upon re-entry to the TUBS system if this flag is set. This flag can provide a great deal of extra automation, however it can also cause some grief that is difficult to track down if used incorrectly. Initial Bytes : Bytes assigned to a use upon first time into system, upon reset by system as defined in reset period, upon Auto TPA update (if Auto TPA is set), or upon automatic reset due to security level change. (expiration of user, or other reason for change) Bytes Left in Account : Current bytes in users account. Total Bytes Downloaded : Total bytes downloaded as defined in PCBoard USERS account. (last time user was through TUBS system) Total Bytes Uploaded : Total bytes uploaded as defined in PCBoard USERS account. (last time user was through TUBS system) Total Files Downloaded : As displayed in PCBoard USERS account. Total Files Uploaded : As displayed in PCBoard USERS account. Bytes Downloaded Today : As displayed in PCBoard USERS account. ╔═══════════════════[ TPA Data Editor ]═══════════════════╗ ║ ║ ║ User Number: 1 ║ ║ Name: ROBIN WELLS ║ ║ Security Level: 241 ║ ║ Expiry Date: 00-00-00 ║ ║ Expired Security Level: 240 ║ ║ ║ ║ Last Reset Date: 08-06-92 ║ ║ Locked Out: N ║ ║ Auto TPA Update: Y ║ ║ Initial Bytes: 500000000 ║ ║ Bytes Left in Account: 500000000 ║ ║ Total Bytes Downloaded: 13919722 ║ ║ Total Bytes Uploaded: 31851779 ║ ║ Total Files Downloaded: 1175 ║ ║ Total Files Uploaded: 104 ║ ║ Bytes Downloaded Today: -100000000 ║ ║ ║ ╚══════════[ The Ultimate Byte System V1.0ß3.7 ]══════════╝ Figure 5 ╔═══════════════════[ TPA Data Editor ]═══════════════════╗ ║ ║ ║ User Number: 1 ║ ║ Name: ROBIN WELLS ║ ║ Security Level: 241 ║ ║ ┌─[ Data has been changed ]───┐ ║ ║ Expired S│ Do you want to save it? Y │ ║ ║ └─────────────────────────────┘ ║ ║ Last Reset Date: 08-06-92 ║ ║ Locked Out: N ║ ║ Auto TPA Update: Y ║ ║ Initial Bytes: 500000000 ║ ║ Bytes Left in Account: 500000000 ║ ║ Total Bytes Downloaded: 14919722 ║ ║ Total Bytes Uploaded: 31851779 ║ ║ Total Files Downloaded: 1175 ║ ║ Total Files Uploaded: 104 ║ ║ Bytes Downloaded Today: -100000000 ║ ║ ║ ╚══════════[ The Ultimate Byte System V1.0ß3.7 ]══════════╝ Figure 6 Error Level Upon Exit TUBS will return an Error Level equal to the user security level upon exit from the program. This will allow some simple batch file routines to be developed within the logon door file. You will NOT be able to run another door requiring TPA's at present, however, it will allow more flexibility and control. Registration: Pricing of Product: Many long hours of development went into this product, however we feel that we also want to provide you as reasonable a pricing structure as possible. We feel that beta testers should be reward for their work, and beta testers will be granted a free registered key file upon release of the product. (limited by the quality and quantity of input provided by the beta site - this protects beta sites, and us from abuse ) Pricing of TUBS v1.0 will be $40.00 U.S. or $45.00 Canadian. All Canadian residents please add 7% G.S.T., and all Ontario residents please add 8% P.S.T. Foreign orders please submit in U.S. dollars. Key File Distribution: A Demo Key file will be included with this product. The demo key will run all of the features of the system with NO crippling of any kind. The demo key will expire after 60 days of your initial installation. An expired key file will however still run your program, and will not remove any features of any kind. ( some delays, and unregistered prompts will be added ) Due to our rather unique method of demo key distribution, there will be no need to call our board to get a demo key file, nor will it expire prematurely on you. You will be granted a sixty day demo period automatically, regardless of where or when you get this product. We also will provide Beta Keys (downloaded from support board), and registered keys. (downloaded from support board, mailed upon request (for a small fee), or uploaded to your board. (for a small fee) Tampering with the key file in any way is prohibited, and will render the key useless. We have taken great care in your users byte integrity however, and loss of a key file, corruption of key file, or expiration of key file will not cause loss of bytes to your users, or loss of operation of the system. (a slight inconvenience to users may be present in the way of additional displays and delays in the system) Beta Test Sites: We are looking for beta test sites for several products, many of which we are unable to name at present however. If you feel you could be a valuable asset to our organization please send in the enclosed beta tester application form. Beta testers will receive free beta keys for the tested products. Beta keys will expire, however will have a three month limit on expiration periods. We hope to have our products out of beta within that three month period ! All beta testers who have provided feedback on the product, ideas on improvement on the product, and any bugs or problem items to sufficient degree will be presented with a free registered key file at the end of the beta cycle. We will run our beta cycles for all products in the above manner until further notice. We feel beta testers do work hard, and do spend some money, therefore rewards for the work are in order. Over the years we have personally beta tested eleven products and alpha tested seven. Many of these are fine products, and the authors have worked exceptionally hard, and deserve credit for their hard work. Any beta product that I have tested however I will not and do not currently run without the authors blessings, or an authorization from the author. However, true to our word, we will distribute key files to those who help us out in this sometimes difficult process. We will provide all beta test sites with as error free code as possible, and will test all code on our system. Beta key files are downloadable from the support BBS upon your approval. We have several products in various stages of development at this time, and hope to be releasing several other new and unique products to you in the near future. Support BBS Information: Platinum Software Development Platinum Software has chosen Central Ontario Data Systems as its support board. The board has given us the privilege to log on regularly and answer all questions and process ordering information. All orders will be processed within 48 hours under normal conditions, other conditions may prevail, but you will be left ample notice if conditions change. Our support boards phone number is : (705) 722-8194, (705) 728-5815 (705) 835-6448 (sorry this was left out in earlier doc files !) Central Ontario Data Systems has given us the unique ability to have our own bulletin board. We wish to express our thanks for this. Upon entering the system, you will only see a brief hint that you have reached Central Ontario Data Systems, and be instantly placed into Platinum Software Development Support Board. All of our files are in the Main Board. As a matter of fact, we have at this time seen no reason to add extra conferences to this board. The board is using an instant registration system (InstaReg) to allow you immediate2 access to the system and the support Conference upon first call. You will be provided with a MENU to select your registration level. BE SURE to select Platinum Software Support at this Menu. You will also have the option for Beta Test Site registration, which will provide all the information that is in the BETA application form. This will supply a quicker method of applying to be a Beta Site, but does not guarantee acceptance any faster or more readily than would mailing in the form. Upon completion of the registration, you will be placed into the Support Area of the board. (Depending upon which node you call, this may be the Main Conference, with no other Conferences available to you) Your personal key file is available by sending in a cheque or money order to the above address. Both U.S. and Canadian cheques are processed. Sorry, we can not accept currencies other than US or Canadian dollars. Visa registration is accepted either online, or by filling in and mailing the form enclosed in the package. ( VISA.FRM ) We would like to pass along our thanks to the authors of several products who have made our life both more enjoyable, and much easier. Clark Development - PCBoard - PCB Development Kit - InstaReg (Registration Door) Cam DeBuck - PCBDeposit Please use the registration form ( REGISTER.FRM ) for cheque or money order forms. Personal cheques will have a 10 day delay on processing prior to the generation of the key file (online) or mailing one back to you. This will allow sufficient time for the cheque to be processed by the banks. Visa orders placed online will be authorized with the key file being generated within 48 hours. Product Credit : PCBoard v14.5 - Clark Development Corp PCB Deposit - Cam DeBuck PCBToolKit - Clark Development Corp Microsoft - MS-DOS 3.30, MS-DOS 5.0 Compaq - DOS 3.31 Novell - Netware 3.31, Netware 2.2 ArtiSoft - LanTastic 4.1 Display Files: There are several display files available to you as a SysOp, which will provide enhanced displays to your users above and beyond what we have provided. LOCKOUT Lockout File This file is displayed to your users instead of the normal text. This will provide information if you wish, letting the user know why they are locked out of the door. All of the normal PCB @ codes will function in this file, as will the PCB @ color codes. PROMO Promo File This File is not normally used, but will be displayed at the beginning of the entrance to the TUBS door. We do not recommend the use of this file, however it was provided for promotional file information in our early releases and has been left in place. It will support all the PCB @ codes if you do find a use for it. BYTEFAIL Byte Fail This File is displayed if the BYTE ratio fails. This file is provided and can be edited, it will support all the @ and @ color codes as well. This file will display when bytes are NOT distributed to a user on BYTES or BYTES/FILES ratio who fails the BYTES ratio test. We have included @WAIT@ in the demonstration file to keep the screen displayed for the userr FILEFAIL File Fail This File is displayed if the FILE ratio fails. This file is provided and can be edited, it will support all the @ and @ color codes as well. This file will display when bytes are NOT distributed to a user on FILES or BYTES/FILES ratio who fails the FILES ratio test. We have included @WAIT@ in the demonstration file to keep the screen displayed for the userr Bulletin Board Name Changes : You may change your Bulletin Board name twice in the first two years free of charge. However the Sysops name may not change. For more than two changes, a fee will be charged for the services. After two years a fee will be charged for change of Bulletin Board names. Name Changes of SysOp : We will change Sysops name free of charge as long as you own the product. You will however have to provide photocopies of signed legal documentation showing the reason and date of change of name. We will have to be provided with address, names and phone numbers of legal authorities to contact for verification purposes. Typically name changes will apply in the event of marital status change, adoption, or personal reasons for name change. Licence Agreement : The Ultimate Bytes System, its accompanying programs, documentation and associated files are Copyrighted (C) 1992 by Platinum Software Developments. All rights reserved. You may not engage in, nor permit third parties to engage in any of the following : A ) Altering the software, the documentation, the key files or any other files associated with or supplied with The Ultimate Bytes System. B ) Attempting to reverse engineer, disassemble, decompile any of the software, key files or associated files in any way or by any means, either electronic, mechanical or manually. C ) Granting licences, sub-licences, leases or any rights of any kind of this software to others. D ) Selling or giving away key files without proper notification to Platinum Software Development. Platinum Software grants you a licence to use this software as long as you agree to meet, and continue to meet all the above conditions. Any present or future violations of any of the above conditions will result in the termination of your licence to use this software. Upon termination for any reason, you must immediately stop using this software, and destroy all copies of the key files in your possession. Platinum Software reserves the right to cancel your licence at any time for any violations incurred that may not be listed in this documentation. Cancellation of licence due to violation of agreement will forfeit your ability to use this product, and any or all fees paid to use this product. Licensing Changes : We will charge a small nominal fee to re-register a change of ownership. ( typically in the $10.00 range within the first year of ownership ) Future Upgrade Policies: We will provide future upgrades free within this version number for all minor releases and bug fixes. ( any version 1.xx releases are free ) We have not plans for any upgrade fees for major version changes, we do reserve the right to charge a small fee for major version upgrades. We will however keep all future upgrade fees at less than 50% of the current price of the most current version. To obtain our support on future version, we will reserve the right to request that you run the most recent version of the software. This is to allow us to provide maximum support, as we will not be able to maintain the support for several versions at the same time, and will supply support for the most recent version only. Hopefully this is not totally confusing. Future Ideas: While we have not decided at this point what we might add to version 2.0 of TUBS, some ideas that we have tossed around at this point One of these ideas being the addition of an upload processor to allow the ratio accounts to be credited at the time of upload. This can be accomplished now by running bytes again upon re-entry to the board, but we would like to offer a seamless interface that is invisible to the user. Time control for Session Time, Daily Time and Account Time should be out in the next major release. Password Control is another option requested and, we will consider the possibilities of this one. All Document Files written by: Robin Wells - Platinum Software Development