Beijing Paradise BBS Backup

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

/ Beijing Paradise BBS Backup / PARADISE.ISO / software / BBSDOORW / LVCAT35M.ZIP / UPGRADE.DOC < prev

Wrap

Text File | 1992-04-06 | 20KB | 456 lines

LiveCat Version 3.5/TDM+ LIMITED TEST DRIVE VERSION Upgrade Notes and Installation Addendum Release date: 03-22-1992 Welcome to the 3.5 version of the Live Systems Door Monitor series! Version 3.5 is a maintenance release that fixes a few known bugs, adds a few new features that have been asked for over the last few months, AND reworks quite a few internals in preparation for Version 4.0, to be released in 3rd quarter 1992. This document is an addendum to the regular documentation for versions 3.0, 3.1 and 3.13. Since we are completely rewriting the documentation for version 4.0, we chose to not produce a full update to the 3.5 documentation at this time. We felt the time would be better spent working on Version 4.0. If you are installing the Door Monitor for the FIRST time then you will follow the installation instructions as documented in the regular documentation, while referring to this document for any differences. In terms of first time installation there are VERY few differences. If you are upgrading your installation to 3.5 from any 3.x then all you need to do is read this document for the differences in operation and for those few items that will need to be changed in your setup. For the most part, this 3.5 upgrade is a 'plug & play' upgrade, but there ARE a FEW changes that you might want to make to take advantage of the new features incorporated in V 3.5. [[ Version 3.5 Change Log ]] Below is a brief listing of the changes, enhancements and additions you will find in V 3.5. 1.) ZKEY menu startup. For some time you have asked for the ability to have the monitor start up running the ZKEY menu, the menu that a user would NORMALLY see only by pressing 'Z' while inside the monitor. This feature makes it possible to bypass the BBS systems door facility completely and integrate the monitor seamlessly into the BBS. The user hardly even knows that an outside program was run. More later. 2.) New internal video handlers and enhanced Ansi capability. Local screen displays are several times faster than before and ansi compatibility of the internal ansi driver is much improved. 3.) In the 3.x release the TIME LOCK feature did not function properly. The ability to close the entire doors system between certain hours had been broken and not caught by the beta team. In V 3.5 the TIME LOCK feature functions correctly. 4.) Much improved handling of the USERS on-line time. Version 3.5 now PROPERLY handles temporary time reductions because of pending and upcoming events and will not permanently reduce the users total doors time because of this. This feature now also allows proper timing control on those systems that permit split logons in a single day. The monitor now calculates time properly for those situations. 5.) Improved DOOR.SYS compatibility. In versions prior to 3.5 we only produced the original V1 DOOR.SYS, not the EXTENDED V2 format as used by Wildcat! 3.0 and GAP 5.x and 6.x. In V 3.5 we support BOTH formats of DOOR.SYS. Door type 'D' (Generic Door.sys) writes the standard V1 door.sys and door types 'G' and 'O' now produce the EXTENDED DOOR.SYS _FULLY_ compatible with Wildcat! 3.0 and GAP 5 & 6. 6.) Added LIMITED support for WWIV doors. We now produce the CHAIN.TXT file required by WWIV doors. More on this later. 7.) Added a PERMANENT DOORS USERS file. This was required for proper control of the users time and to clear the way for some new features that will be added in V 4.0. More on this later. 8.) Multi-Node users have long requested a way to limit a door to running only on certain nodes. This has particular application for DesqView and other multitasking systems. You can now specify the highest COM PORT # that the door should be allowed to run on. More on this. 9.) Multi-Node users have asked for a way in an event to UNLOCK any doors that might be accidentally left in a 'locked' condition. A new program called LOCKFIX.EXE is included with V 3.5 and can be run in an event to unlock all locked doors. 10.) Version 3.5 is NOW available and FULLY supports the Ultra BBS, it is known as LivePro/U. 11.) Increased use of Memory swapping techniques to speed execution times. 12.) The bye command in previous versions (if used) would log the bye as a carrier drop to the BBS caller logs. For GAP and Wildcat! 3.x systems this is now logged as a normal user logout if you enable the BYE feature in the monitor. This documents MOST of the changes present in V 3.5. There are others, mainly internal that you won't notice but provide increased reliability in a variety of circumstances. [[ UPGRADING A 3.X VERSION OF THE MONITOR TO 3.5 ]] If you are already running a 3.x version of LiveCat then your upgrade is VERY simple. Follow these steps: 1.) ERASE the following files before starting the upgrade. LIVECAT.EXE LSEDIT.EXE LSFIP.EXE LSPACK.EXE LSCONFIG.EXE 2.) Go to the \WC30\WCWORK\NODE1 directory and ERASE MONITOR.CFG 3.) If running MULTI-NODE go to each of your OTHER NODEx directories and ERASE MONITOR.CFG from those directories as well. 4.) Copy the NEW .EXE files from this package to the directory in which you had the OLD versions of the .EXE files installed. 5.) Go to the LIVECAT directory and ERASE LCUSER.DAT 6.) Go to the \WC30\WCWORK\NODE1 directory and run LSCONFIG.EXE to create a new MONITOR.CFG for LiveCat 3.5. 7.) If running MULTI-NODE go to each of your OTHER NODEx directories and run LSCONFIG.EXE in those directories as well to create a new MONITOR.CFG file the node. 8.) Do NOT erase your LC.SYS file from any of the NODE directories. This is your key file and LiveCat will NOT run without it. The current LC.SYS is fully compatible with V 3.5, you do NOT need a new key file. Thats it for the upgrade! You can now reboot and things will run as they did before. [[ INSTALLING A FRESH 3.5 SYSTEM ]] If you are installing LiveCat for the first time then follow the installation instructions in the main documentation file. There are no differences to document in installation between V 3.5 and 3.0 or 3.1. If you are running an earlier version of LiveCat, V 2.0 for instance, you cannot upgrade directly to V 3.5. You MUST start over, painful as it might be there is no alternative. [[ USING NEW FEATURES IN V 3.5 ]] This section documents the changes and new features of Version 3.5 in detail, read it carefully! * TIME LOCKING * All previous versions of LiveCat incorporated a feature called VTL, or Vault Time Lock. The features allows you to COMPLETELY LOCK down the doors system between certain hours of the day. In Version 3.1 this feature was broken and did not function properly. It has been fixed in Version 3.5 and now functions AS DOCUMENTED in the manual. No changes to it's operation were made other than to fix it. * ZKEY MENU STARTUP * This feature was added by popular request. Some BBS systems such as Wildcat 3.x and GAP 5 and 6 allow the sysop to define custom menu entries. In Wildcat! these are called 'DOS HOOKS' and in GAP they are called 'Sysop Definable Menu Items'. This feature may be present in other supported BBS systems as well. What this is for is to allow you to use one of these sysop definable entries in your main menu to bypass the doors module of the BBS and drop right into our monitor. To use this, define a DOS HOOK or SYSOP DEFINABLE option to whatever key stroke, or series of keystrokes you want. For WC 3.0 people you will then create a MAIN1.BAT or a MAIN2.BAT that contains the ZKEY startup for the monitor. GAP users would have a batch file that is the same NAME as the COMMAND that shows in your main menu. Other BBS owners will use whatever method is available, if any to create sysop definable menu entries. In this batch file you will simply put: LIVECAT MONITOR.CFG ZKEY You would of course substitute LIVECAT in the above with SUPERDOR, LIVEPRO, WILDFIRE or whatever is appropriate for your system. The word ZKEY replaces the default menu that would normally go on this line. THIS FEATURE IS AN OPTION! You DON'T need to use it this way. You can still continue to run with the monitor dropping into a default menu from the BBS's doors subsystem just like it always did. Unless you specifically want to use this feature you do NOT need to change any of your LIVEx.BAT files or DOOR_X entries. It should be noted that this feature CAN be used even if you don't have definable menu entries. This would serve to allow ONE batch file ONLY to enter the Monitor system. If you define ONE batch file or DOOR_X entry to be a ZKEY entry point then you might as well do away with ALL the rest of the .BAT files or DOOR_X entries since the user finds themselves in the ZKEY menu instead of a default DOOR menu. It should simplify things for both you AND your users. * NEW INTERNAL USER TIME HANDLERS * This release drastically alters the manner in which the users time remaining for doors is maintained. This is the single most important and detailed change being made in V 3.5. The object of this change is to cure the situation where users entering doors during the time when they would get a temporary reduction of their time because of a pending event or an imminent log off in and a split log on situation. I had not intended at this time to do away with the LCUSER.DAT daily users file and replace it with a PERMANENT Isam user file until version 4.0, but as I got into this I decided that since so much work had to be done there anyway that I'd just go ahead and do it now. This version will CREATE a new Isam User file named LCXUSER.DAT and LCXUSER.IDX when it is run the first time. The file is permanent and will maintain user records forever in the manner we need. This should be totally transparent to you when the file is created and the old one becomes obsolete. This change should make timing problems with split-logons and pending event time reductions transparent and error free. * IMPROVED DOOR.SYS COMPATIBILITY * There are now TWO different versions of DOOR.SYS being used. I refer to them as DOOR.SYS I and DOOR.SYS II, DOOR.SYS II being commonly referred to as 'Extended DOOR.SYS' Previous versions of the monitor produced ONLY a DOOR.SYS I for doors requiring DOOR.SYS. This caused problems with SOME doors written specifically for Wildcat! 3.x in which the door author tried to read in the FULL EXTENDED DOOR.SYS II which we were not creating. This would commonly result in INPUT PAST END OF FILE ERRORS when attempting to run the door. To accommodate this the new LSFIP now supports BOTH formats of DOOR.SYS, if you mark a door as 'D' type it will create the older DOOR.SYS I format still used by many doors, if you mark the door as a 'G' or 'O' type door it will now create the EXTENDED DOOR.SYS II format as used by GAP 5.x+ and Wildcat! 3.0+. This SHOULD clear up any problems you might have been having doors written specifically for the Wildcat! 3.0 interface. * LIMITING DOOR RUNS TO CERTAIN NODES (multi-user only) For a long time some of you that run multi-nodes under DesqView or some other multi-taskers have been asking for a way to limit which nodes a door can be run on. In this version LSEDIT adds a new field to the door attributes window called: Highest Comport to Allow (1-8): What ever number you place here is the HIGHEST comport that the monitor will allow the door to be run on. For instance, you might have 4 nodes running under DV, on COM1, COM2, COM3 and COM4. You install a new door that only supports COM1 and COM2. In this field in the attributes put the number 2, indicating that COM2 is the highest comport number the door should be allowed to execute on. A user on node 3 or node 4, COM3 or COM4 trying to execute the door will now get an error message telling them that this can not be run on this node. This should solve the problem for you. * INCREASED USE OF MEMORY SWAPPING * We had been having random reports in V 3.1 and 3.13 that sometimes under certain circumstances LSFIP would create a ZERO length PCBOARD.SYS and PCBOARD.DAT file. I've finally I THINK traced this to a memory problem. In ALL previous versions of the monitor LSFIP was SHELLED from the monitor, meaning that the monitor remained in memory and shelled command.com and lsfip underneath it. In reality this required a fairly large hunk of memory which I think was causing the problem. This version of the monitor NOW SWAPS the monitor out of memory before running LSFIP and then back in when LSFIP is complete. This frees the ENTIRE memory heap for LSFIP to run in and if that was the problem this should fix it. Those of you using EMS to swap will find the running of LSFIP almost instantaneous now. If you are using disk swapping the speed should be about the same but more memory will be available for LSFIP. * BYE COMMAND ENHANCEMENTS * The BYE command has been reworked so that in the cases of Wildcat! 3.x, GAP 5.x and 6.x the DROPPED CARRIER MESSAGE will _NOT_ be written to the callers log as they were in the past, instead they will show as normal logoffs from inside a door. For GAP users and door authors this is significant in that the monitor NOW instructs GAP to REREAD door.sys on return from the monitor where it did NOT do this before. As an author of GAP doors any changes you wish carried BACK TO GAP must be made to DOOR.ORG while the monitor is running. This file is renamed back to DOOR.SYS when the MONITOR exits and GAP will reread it and react to changes in any fields that you were manipulating. Users of Wildcat! 3.x, the USERINFO.DAT is modified to indicate to WC that the user logged of from outside the system and WC will reread and react to any changes you as an author make to USERINFO.DAT. It should be noted that the monitor does NOT manipulate or rename or otherwise tamper with the USERINFO.DAT except in the case of use of the BYE command. All it does is read it in, change field 15 to Y and then write it back out so WC knows the user logged off normally. * LIMITED WWIV DOOR SUPPORT * This is the first version of the monitor to support the WWIV format for running doors. Due to the nature of MOST WWIV doors however, this support is limited so if you intend to try to run WWIV doors, read this carefully. The BIGGEST problem with running WWIV doors is that most of them do NOT have built in COMPORT facilities but instead rely on WWIV itself being present to provide EXTERNAL comport services to the door! A FEW WWIV doors we tested had support for fossil drivers in which case they should run fine using LiveCat and nothing else except the fossil installed. If the WWIV does NOT have built in comport support and does NOT support use of a FOSSIL for comport control then you have a problem. You MUST use SOMETHING to provide EXTERNAL COMPORT SERVICES to the door, which LiveCat does NOT do! We recommend the use of a program by Marshall Dudley called DOORWAY to provide these external comport services. Doorway is an excellent program and works very well as a complimentary product to LiveCat. In beta testing we had LIMITED success using Doorway to run WWIV doors, but if you are willing to tinker and play you can probably get them to run this way. In order to support the use of Doorway in conjunction with LiveCat to run a WWIV door, we create TWO files if you mark a door as type 'I', for WWIV support. We create BOTH a DOOR.SYS and a CHAIN.TXT file. The DOOR.SYS file is required for DOORWAY to startup and the CHAIN.TXT file is created for the WWIV door itself to use when DOORWAY starts it up. You must obtain DOORWAY and read it's documentation to learn how to use it and attempt to set it up to run these doors. Documenting the use of Doorway is beyond the scope of this documentation. * USING LOCKFIX.EXE (Multi-User only) Because of circumstances beyond our control, a door may crash while being run in your system forcing a reboot. If this situation occurs, LiveCat never gets a chance to reset the 'Door In Use' flag in a multi-user system. This will result in a user trying to enter the door getting a message indicating that the door is IN USE ON ANOTHER NODE when in fact it is not. Previously, the only way to clear this condition was to start LSEDIT and edit the door script involved to change the DOOR LOCKED flag from Y back to N. This was clumsy and time consuming and could sometimes be missed for days until a user complained about it. LOCKFIX.EXE is provided with V 3.5 so that you may run it one of your normal events to clear these lock flags. If none of the doors are in a locked condition, LOCKFIX does nothing. Any flags set to Y at the time it is run will be set to N. This program MUST be run with all other nodes DOWN, or at least no running LiveCat at the time or a sharing violation will occur. There are no parameters to issue or anything else when LOCKFIX is run. You MUST however make sure that your event batch file changes to a NODEx directory before running LOCKFIX. LOCKFIX reads the MONITOR.CFG file to find the LiveCat database files. [[ WHATS NEXT ? ]] At this time we have begun the engineering of Version 4.0. Version 4.0 will be almost a complete re-write of the system utilizing EVERYTHING we've learned over the last few years with LiveCat. I'm obviously not going to tip my hand at this time about what the new features of 4.0 really are but suffice it to say this! V 4.0 will knock your socks off! If you've liked LiveCat so far, you'll LOVE Version 4.0. 4.0 utilizes state-of-the-art in programming techniques and compiler technology. We are building features into 4.0 that will surprise EVERYONE! Maybe even US! Version 4.0 is due to be released in the 3rd quarter of 1992 so be watching for it, and SEVERAL other significant new products from Live Systems this Spring, Summer and Fall.