ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

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

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / BBS / RBBS_PC / RBBSDOCS.ZIP / RBBSDOCS.12B < prev next >

Wrap

Text File | 1990-11-05 | 26.4 KB | 528 lines

RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-10 DKAAAA.ZIP is ready for download. DKAAAAa.ZIP is ready for download. DKAAAAb.ZIP is read for download. As each file is downloaded successfully it is removed from the list and is no longer displayed to the user as ready for download. 12.6.2 The "Library" Subsystem and PC-SIG's CD-ROM -------------------------------------------------- The CD-ROM published by PC-SIG consists of a DOS subdirectory for each 360K diskette in the PC-SIG library. Sometimes the disk contains all the files already in the ARC format other times they just contain a group of files. The key here is the A)rchive function. The resulting file to be made available for download will NEVER be greater than 360k. This is important since a caller may only have a floppy based system and could not capture a file any larger than a 360k floppy can contain. The PC-SIG's CD-ROM creates the problem of listing both the individual files contained on each diskette as well as a summary description of the individual disks. This can be solved by listing each of the 18,000+ files in the MASTER.CDR using positions 43-76 for the description, positions 77- 79 for the disk drive, and positions 80-82 for the valid categories for downloading. These are contained in the file specified by CONFIG parameter 217. MASTER.CDR might also contain a list of names of the files that would be created by the A)rchive function. This allows the caller to scan a category (i.e. category 200) for disk titles only. Note that the files do not exist until the user uses the A)rchive function. A SysOp who did not wish to allow individual file downloads might only include these entries in the MASTER.CDR rather than the other 18,000 entries. The directory for the PC-SIG CD-ROM is over 1.5 megabytes in length and can take up to 10 minutes to search completely (when using a PC at 4.77 MHz). If the SysOp is using FMS, it is recommended that the category file for the normal FMS directory and the category file for the Library FMS directory be the same (PC-SIG has 27 different categories for its files). 12.7 Creating the Personal Files Directory ------------------------------------------ RBBS-PC's "personal" file support is analogous to RBBS-PC's support of "personal" messages in that these files are specially addressed to a specific caller or group of callers based on security. Personal file downloads differ from the general download in three major ways: 1) the time limit check is bypassed in personal downloads, meaning that a qualifying caller can download a file regardless of time left. 2) only files explicitly listed in the personal directory can be downloaded. Normally files to be downloaded will be looked for on the disk(s) where files are available for downloading whether they are listed in a directory or not. 3) only callers with matching user record or sufficient security can download a file. Normally any caller with security enough to issue the download command can download a file. RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-11 Personal files provide a way that files can be delivered to specific individuals. As an example, a vendor's support bulletin board for a software product might make the upgrade downloadable only by paying customers. A credit reporting corporation can make credit reports electronically available only to the people who order them. Or, a SysOp can make a file privately available to only one caller. One of the most useful applications for personal downloads is to make certain files available regardless of time remaining. Previously, SysOps had to increase the security of callers or set artificially high session limits just to make certain large files available. By putting these file names in the personal directory and limited by security level, these files can be made available regardless of how little time is left. For example, the large files comprising RBBS-PC can be made downloadable to all callers even though they are limited to 30 minutes. Access to personal files can be limited in two ways. First, the files can be downloaded only by callers which have a matching value in their user record. For example, files can be limited by name (any field in the user record can be selected). Alternatively files can be limited by security level, meaning that a file can be downloaded by any person with that security level or higher. File access based on security level can also be accomplished using the standard RBBS-PC file security mechanism, but to do so places the caller's under the standard RBBS-PC constraints of maximum time per session/day. Using the "P)ersonal files" command in the files section, a caller is asked what files the caller wants to download. The only files available to the caller for downloading are those explicitly listed as belonging to the caller, unlike the general download command which will look for any named file on the disk. The caller can ask to List the files available. Callers will see only those belonging to them. There is a special option to download all and only the "new" files specifically addressed to the user by matching a field in the caller's user record. RBBS-PC keeps track of whether the caller has ever downloaded the personal file. When listing, new personal files are marked with an "*" in front of their names (they are "tagged"). Selecting the new files starts a multi-file download for all and only the personal files the caller has never successfully downloaded. Files you want downloaded ONLY through the personal file features of RBBS-PC should be put in their own subdirectory as specified in CONFIG parameter 142. If you put the personal files in a download subdirectory they would be available then to anyone who could name them. RBBS-PC will search the download areas for a personal file if it is not found in the subdirectory specified in parameter 142. Second, in the same place as the personal files themselves, put in a special personal directory with name specified in CONFIG parameter 143. This directory is the same format as the general file directories of RBBS- PC. The format is as follows: Default Field Positions Length Description of Field 1 - 12 12 The first 12 characters of an entry have the file name, with no internal spaces. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-12 13 - 73 Variable The next group of characters can have anything in them. This will be displayed to the caller who asks for a listing, along with the file name in the first 12 columns. The length of this group is 21 characters plus the length of the upload description specified in CONFIG (40-46, defaults to 40). The default length of this field is 61 characters. 74 -104 Variable The next group of characters are what is used to identify the file as "belonging" to the caller and must match a field in the user record. In CONFIG parameter 43 and parameter 44, the SysOp specifies the position in the user record to use and how many characters. The default is to begin in column 1 and use 31 characters for the caller's name, but any field in the user record can be used. Optionally, a security can be entered in this last field to limit the file based on the security level of the caller. To use security rather than a match on the user record, simply put a blank as the first character in the field, followed by the security level. 105 1 The last character must be an "*" to signify that the file has never been downloaded or an exclamation point if ever downloaded. This personal directory works very much like the File Management System shared directory, using a field in the user record as the category and limiting callers to their one category, or limiting the file to the group of caller's with the minimum required security. The personal directory is fixed length and read in reverse from bottom to top. After setting up or modifying the personal directory, you use the CONFIG utility parameter 187 to check whether the personal directory has the proper format. The personal directory can be created by a text editor (i.e. EDLIN) but be sure to put in the "*" in the last column when creating a new entry so that the file will be tagged as new. Also be sure to make each entry fixed length. If the user's identity does not fill out the length of the last field, be sure to pad the record with blanks out to the full length. When setting up a personal file directory there are seven configuration options peculiar to personal files: CONFIG Description parameter 43 what part of the user record used to identify files as parameter 44 belonging to the user (beginning column and length), parameter 143 the name of the personal directory, parameter 142 the drive and path where the personal files and personal directory are stored, parameter 144 the protocol that must be used downloading, parameter 147 whether the files downloaded are to be concatenated, and parameter 188 the CONFIG utility to check the structure of the personal directory to make sure it is in the properly format. Parameter 147 and parameter 187 require some explanation of how they might be used. Limiting the caller to a required protocol to use is not something one would generally do. But, for special purpose downloads, like RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-13 downloading to a printer, one might want to require ASCII, for example. Or, if all callers are to use the same communications package or only a particular protocol is efficient, you can specify what callers must use. Concatenating files means that when multiple files are specified for downloading, the files are sent continuously in one stream of data rather than individually as separate files. In effect, the files are physically combined at the time of downloading. All messages between files are suppressed - the only messages that appear to the caller are those that normally occur when the first file transfer starts and when the last file transfer ends. Concatenation is currently supported only for ASCII downloads. An example of a situation that might use this feature of RBBS-PC is a business that generates short reports for clients. Their clients want to call in remotely to get time-critical reports and print them right in their office on pre-formatted paper. Each report is a separate file on RBBS-PC with all the necessary printer commands already included in each file. A SysOp might set up RBBS-PC such that the main menu was restructured to make the P)ersonal files function be P)rint reports to reflect the more specialized nature of the board. Callers to this board would call in, identify themselves, and select P)rint reports from the main menu. Callers could use L)ist to see what is available if they are looking for some report in particular; just select all new reports; or ask for a particular report if they must have it immediately. In the last two cases, RBBS-PC would notify the caller to set up to receive and press [ENTER] when ready. The pre-formatted reports with embedded printer control sequences would stream out onto the paper (including formatting like bold or underline) positioning the text to fit in boxes. The paper is automatically advanced as needed. When done, RBBS-PC beeps the user, who then turns the "save to printer" feature off of whatever communications package is being used. To set up this application, the personal file options would be configured to use the caller's id (e.g. account number). The files and directory would be put in a special subdirectory not shared with anything else. The CONFIG parameters would be set to specify that caller's must use ASCII ("A") as their protocol and that multi-file downloads will be concatenated. Another example is that of an electronic job placement service that wanted to limit non-subscribers to a security level 5 with 10 minutes. However, they also want non-subscribes to be able to download a file of potential employment opportunities that may take more than 10 minutes. The following entries would be put into PRIV.DIR: JOBSFORU.ARC 282888 07-14-87 List of job opportunities you might want 5 /|\ /|\ 12 74 Each record is padded with blanks so that 29 blank characters follow the security level, followed by an '*'. The '*' is not shown in this documentation since it is in a column too far to the right. RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-14 12.8 Automatically Checking & Converting Uploaded Files ------------------------------------------------------- Verifying the Integrity of a File --------------------------------- RBBS-PC's on-going commitment to providing SysOps with the ability to protect themselves and their callers is reflected in precisely this kind of feature. When a file is uploaded, RBBS-PC will look for a file called T<ext>.BAT (where <ext> is the characters that make up the extension of the uploaded file). RBBS-PC looks for this file on the drive and path specified in CONFIG parameter 105. If this file exits, RBBS-PC will SHELL to either: a.) the program specified in the file (if it only has one line) or b.) to the .BAT file itself. In this way a SysOp may install whatever processing is desired after a file has been uploaded. If the BAT file contains exactly 1 line, RBBS-PC will shell to the contents of the bat file, passing on the command line the two parameters: a.) the name of the file upload (first) and b.) the name of the file to write the results to (second) If the BAT file contains more than one line, RBBS-PC will SHELL to the BAT file itself, passing a.) the name of the file upload for "[1]" and b.) the name of the file to write the results to for "[2]" as the first and second parameters, respectively. RBBS-PC will consider the upload to have failed and delete the uploaded file, if the file to which the results are to be written has a length greater than 2 bytes. The BAT file should either a.) not write a result file or b.) leave an empty one if the upload is okay. If the file that was uploaded is not okay, the external application should write out some error message more than 2 bytes long. A typical use for this feature of RBBS-PC is to test the compression of the uploaded file and pipe the results to a text scanner that looks for an error string and redirects the output to a file if an error is found. For example if files that are uploaded with the extension .ZIP were to be tested, a SysOp might create the file TZIP.BAT PKUNZIP -T [1] | FGREP "error in a" > [2] An alternative implementation is: PKUNZIP -T %1 IF ERRORLEVEL 1 ECHO BAD UPLOAD > %2 SETERROR 0 Under versions of QuickBASIC prior to 4.5, programs that reset the error level cause illegal function call 5 upon return from the SHELL. Therefore RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-15 it is necessary to run a utility to reset the error level back to 0 before going back to RBBS-PC. This is what the SETERROR.EXE file does. The recommended procedure is to use PKUNZIP, check errorlevel, and reset error level to 0. PKUNZIP outs somewhat variable strings when different errors occur, making a filter based on text more difficult to implement. Converting Uploads ------------------ RBBS-PC can be configured by the SysOp to cause uploads with extension <u- ext> to be converted to the default extension <d-ext>. To do this, the SysOp must put a file named C<u-ext><d-ext>.BAT on the drive and path specified in CONFIG parameter 105. If the file exists, RBBS-PC will SHELL to it. If the SysOp wants all .ARC files uploaded converted to a .ZIP file, create a file CARCZIP.BAT in the subdirectory specified in CONFIG parameter 105. To convert .PAK files to .ZIP, create the file CPAKZIP.BAT. Sample conversion batch files are included on the RBBS-PC distribution diskettes. 12.9 Fast File Search --------------------- RBBS-PC 17.3 includes an enhanced file-search capability for uploads and downloads. This enhancement has two advantages: (a) File searches are much faster. In the case of very slow devices like a CD-ROM, this can be the difference between sub-second response and a 45 second response. File searches are now virtually instantaneous. (b) Files not stored on this system can trigger macros. This allows requests for files stored elsewhere, either off line on backups, or on other cooperating systems, to trigger later processing. The basis for the fast file search is a file, configuration parameter 267, which is a sorted list of file names available for downloading. The default name is FIDX.DEF. The format of this file is: columns 1-12: file name columns 13-16: location index (1, 2, 3, ...) columns 17-18: carriage return line feed. All data is stored as character data and the file is editable. The file names must be stored with no internal spaces and a period separating the prefix from the extension. The list of file names MUST BE SORTED BY FILE NAME in order for the fast file search to work. The location index is the record number (line number) of the locator file, whose default name is LIDX.DEF, and has the following layout: columns 1-63: location of file column 64: any character. MAKEFIDX puts in a period. columns 65-66: carriage return line feed. This file is all character data and is editable. Essentially, the location index points to a record in the location file. E.g. if FIDX.DEF has RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-16 RBBS-BAS.ZIP 2 HARPIE.ARC 3 and LIDX.DEF has C:\DOWN1\ C:\DOWN2\ C:\UP\ Then RBBS-BAS.ZIP is located in directory C:\DOWN2 (2nd record) and HARPIE.ARC is located in C:\UP (3rd record). The location field should be a drive/path terminating with a "\" if any path is given, and file must be filled with blanks through column 63 if the path is shorter. You must put some character in column 64. Many editors delete trailing blanks, so you should probably put in a non-blank. A period is a suitable choice. RBBS-PC will use a binary search on the first 12 characters in FIDX.DEF. This binary search can be significantly speeded by provided "tabs" for this file, indicating the record at which the first file is that begins with the symbols "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ". This is like the "tabs" you see on dictionaries, so you can directly turn to the B's, for example. A tab file has the same prefix as the file name file, except that it adds a "T". For "FIDX.DEF", the tab file would be "FIDXT.DEF". RBBS-PC will automatically detect and use a tab file if available. The tab has 72 characters in it. Each 2 bytes represents a binary integer whose value is the record number in FIDX.DEF where the first file occurs that begins with the respective symbols above. Thus bytes 3-4 show where files begin with "1" and bytes 69-70 where files begin with "Y". Two utilities with source code are provided for setting up the fast file searches. The source, for compiling under QB 4.5, is included. MAKEFIDX will create both the file name list (FIDX.DEF) and the location file (LIDX.DEF), from a list of directories (see MAKEFIDX.CFG) or a list of file names, or both. You must next sort FIDX.DEF by file name. A good shareware utility for this is QSORT (QSORT FIDX.DEF /1:12). MAKETABS will create a tab file (FIDXT.DEF) from the sorted file list FIDX.DEF. A sample batch file for recreating a fast file system is MAKEFFS.BAT. It uses MAKEFIDX.EXE, QSORT.EXE, MAKETABS.EXE, and configuration file MAKEFIDX.KG. You need only edit MAKEFIDX.KG to change the filespecs (/FileSpec=) to match where your files are, and where to write the index files. Reconfiguring to Take Maximal Advantage of Fast File Searches ------------------------------------------------------------- The fast file search is virtually instantaneous on an 8088 with a tab file for 5000 file entries. The savings on wear and tear on the hard disk can be very significant as well. And the time it takes to set up the fast file search is only a few minutes. Most SysOps, therefore, will want to implement fast file searching, whether or not they have a slow device like a CD-ROM. RBBS-PC's FILE MANAGEMENT SUBSYSTEM 12-17 RBBS-PC will first search through the drive/paths specified in config to be available for downloading, as it always did. Files not found there will then be searched using the fast file search system. The way the fast file search works is that a file found in its list is looked for only in the designated location. Nothing else is searched. The optimal way to implement fast file searching is to reconfigure the drive/paths available for downloading down to at most the upload directory, and let the fast file search handle everything else. That way, files will be searched first in the upload area, and those not found at first will then be searched using the fast file search system. Note that every file in the fast file search list is considered to be available for downloading whether or not its drive/path is listed in the configuration program as a downloadable area. Note that you can have separate fast file search systems available for each sub-board. You can also use the fast file search for common files and have a separate download area for the sub-boards. Note that whenever you relocate files, you must re-create the fast file search system. This is not hard since it takes little time and can be automated. Macros with the Fast File Search -------------------------------- The location file for the FFS (LIDX.DEF) can have in it "M! <macro file>", where "<macro file>" is the name of a macro, instead of a drive/path. RBBS-PC will then execute the macro. Thus, you can have special processing for classes of files, perhaps to o advise that the upload is not wanted o tell the caller on what other BBS the file can be found RBBS-PC will put a "U", "D", or "V" in work variable 1 depending on whether the file request is to upload, download, or view, so that you can customize your macro for the situation. This if you want to display a message only on an upload, you could have UNWANT.IMC with 0 {ON [1] {==U {*B The file {C1{FI{C0 is {C2NOT WANTED{C0 here. Please do not upload it. {END {END ON RBBS-PC regards the file as not found when a macro is executed. However, you can inside the macro use the macro command "LO" to set a location that RBBS-PC will use to look for the file, the same as if the drive/path were given in LIDX.DEF. Thus, you can use macros for files that really are present. For example, if RBBS-EXE.ZIP is downloaded, the file is located in D:\D1, and the entry RBBS-EXE.ZIP in FIDX.DEF is mapped to a record in LIDX.DEF with the entry "M! C:\RBBS\DWNRBBS.IMC", then the following macro displays a special message but still causes the file to be found: 0 {ON [1] {==D RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 12-18 {*B Congratulations. You are about to download the best BBS! Call me voice at 703-978-4339 if you need any help. {END {LO D:\D1\ {END ON