OS/2 Shareware BBS: 2 BBS

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

/ OS/2 Shareware BBS: 2 BBS / 02-BBS.zip / mag7demo.zip / WHATSNEW.ZIP / WHATSNEW.7 < prev

Wrap

Text File | 1993-09-01 | 69KB | 1,334 lines

September, 1993 - Magnum BBS version 7.00C List of new features, bug fixes & enhancements since v6.00C *************** * * * NEW PROGRAM * ======> MAGINST.EXE * * ----------- *************** This new program is an "intelligent install" program. It will install Magnum version 7.00C from scratch, or over any existng version of Magnum (including betas, commercial releases, and demo versions) from version 4.00C and up. If you're running a version of Magnum less than version 4.00C, contact Gilmore Systems. *************** * * * NEW PROGRAM * ======> MAGFILE.EXE * * ----------- *************** WARNING: This new program only works once you've installed or upgraded to Magnum version 7.00C, do not run this program until you've completed installation! By popular demand, many Sysops have asked for a way to get an entire directory into their FILE database(s) without having to manually go through the motions of 'uploading' the individual files. We bring you MAGFILE.EXE, which can do just that! It can add entire directories to any particular FileBase and any file area of any FileBase. One major use for this program is for when you need to deal with CD-ROM disks. To add an entire directory of files you must first create an ASCII text file containing the list of the files in the directory you wish to add. This can easily be accomplished on the OS/2 command line with (assume G:\SOMEDIR\DIR1): DIR G:\SOMEDIR\DIR1 >MAGDIR.LST the output of the DIR command has now been written to the MAGDIR.LST file. Next, edit the file, stripping out any directory names or any other text lines which don't contain valid filenames and sizes. Next, you will need to place 7 keywords and parameters at the top of the file (each on a line of its own). By way of example: #INIT: D:\MAGNUM\PGM_DIR\MBBSINIT.1 #BASE: 5 #AREA: C #NAME: 41-52 #SIZE: 18-26 #DESC: ** From CD-ROM \SOURCE\C\SAMPLES #CDROM: F where #INIT: Defines the filespec to one of your MBBSINIT.x files. #BASE: Defines which FileBase to add these files to. If you do not have the Extended FileBase module, this parm should be 0. #AREA: Defines which FileArea (of FileBase) to assign these files to. #NAME: Defines column positions that filenames are in (FAT FORMAT ONLY). #SIZE: Defines column positions in which the file sizes appear. #DESC: This will be the description line added to each of the files. #CDROM: Optional! Defines the drive letter of CD-ROM drive Do NOT supply a parameter if not using a CD-ROM drive!! Lines starting with the ! or ; characters are ignored (comment lines). Optionally, the #DESC: parm can also define column positions in case you wish to manually provide a description for each file. Save the changes, then run MAGFILE.EXE as follows: MAGFILE.EXE MAGDIR.LST When the program completes successfully, your files have been added to the FileBase specified in the #BASE parameter. If you execute MAGFILE.EXE without any parameter (ie: just MAGFILE.EXE and no filename), then the above instructions will appear on your screen. And don't forget to change your STARTUP.x file(s) for FileBase 0, or run your FILEBASE.EXE program (for extended FileBases) to accurately indicate the proper directory paths for the BASE and AREA parms you supplied above. Take note that although the 7 keywords and their parameters need to occupy the first 7 text lines, any of these keywords can re-appear anyplace else in the file with different parameters. This will allow you to change the file area or the FileBase or desc fields midstream. The changes take place from that point on, or until another change is encountered. Also note that if your FileBase already exists (ie: FILE.DAT for example), the new records will be appended (added) to the database, otherwise the program will create the database. NOTE: This program does NOT check your existing FileBase for duplicate names (ie: names already in the database which may also appear within your directory list). Remember, duplicate filenames are fine as long as they're in different FileBases, but duplicate filenames in the same FileBase won't work as you might like them to. Most file operations in Magnum work on the first matching file! To get to a file with a duplicate name, use the #nnnn method (instead of the filename) when answering a filename prompt while online. This is a great little program to have, and is now be included in the Magnum BBS package. =========================================================================== *************** * * * NEW PROGRAM * ======> MAGDRIVE.EXE * * ------------ *************** You wanted better CD-ROM support and now it's here! This program is a simple program to run. Simply run it with the drive letter of your CD-ROM drive as the parameter to this program. For example, if the drive letter of (one of your) CD-ROM drive is F, then run the program as: MAGDRIVE F The output of this program is placed in a file d.DIR (where 'd' is the drive letter you specified)... in the above example, the output file would be F.DIR The resultant d.DIR file is an ASCII text file of all of the files in each and every subdirectory of that drive! Edit the d.DIR file with your favorite text editor according to the rules of the MAGFILE.EXE program described above, but DO NOT remove any of the statements starting with PATH[ in column 1. The d.DIR has already filled in the #CDROM, #NAME, and #SIZE fields for you. When you've finished editing the file, run it as the parameter to the MAGFILE.EXE program. The #BASE and #AREA parameters will determine which area of which FileBase the CD-ROM files will be stored in. The files will always remain on your CD-ROM drive. Unlike other BBS software, Magnum has no need for copying any files from your CD-ROM drive to someplace else in order to [A]ccess, [D]ownload, or perform any other function. Although there may be litterally thousands of subdirectories on a particular CD-ROM disk, as far as the online user logged onto Magnum is concerned, they're all in File Area x of FileBase y (where x was the parm to your AREA keyword in the d.DIR file, and y was the parm to your BASE keyword in d.DIR). Once you've run the MAGFILE.EXE program against the d.DIR file, you may delete the d.DIR file, all information is now in Magnum's File Database(s). Note that there may be many duplicate filenames on any given CD-ROM disk. A popular name which may occur in many subdirectories is READ.ME. If the online user specifies a filename (to a filename prompt), Magnum will always use the first matching entry. To get to the particular file you have in mind, always use the #nnnnn method of file entry. =========================================================================== MBBS.EXE: -------- - Changed such that after an RMAIL command is issued (either via an ACE command or at the "command => " prompt), the node used for the AMMO modem link will automatically be re-activated. - A "modem" (ie: certain WAN networks) can now have incoming calls established by only the presence of DCD (data carrier detect). To accomplish this, simply change the ANSWERTYPE parm in your STARTUP.x file(s) to D (to indicate DCD) and recompile with MAKEMBBS.EXE (make sure the node is shut down when recompiling). - The display on the MBBS.EXE console for file transfers now includes the start time of the xfer. - Added a new capability to the MBBS.ACE file: the ability to queue a command based on the date of the month! For example, if you wanted to queue (store) an ACE command to be executed on the 15th day of each month (at 02:01), your ACE command might look like this: -15,02:01,"maintain.cmd",wait or suppose a command is to be executed on the 1st of each month (at 01:00): -1,01:00,2 shutdown 02:00 the secret is the - character (the minus sign) in column 1 of the queued command. Keep in mind that February has 28 (or 29) days, therefore, if you want a command to execute on the 30th of each month, it will never execute in February! Likewise, if you specify for a command to be executed on the 31st of each month, it will never execute during months containing less than 31 days! - Added another new capability to the MBBS.ACE file: the ability to queue a command based on a specific date! For example, if you wanted to queue (store) an ACE command to be executed on July 4, 1994 at 02:01, your ACE command might look like this: 07/04/1994,02:01,"maintain.cmd",wait or 04.07.1994,02:01,2 shutdown 02:00 Note that the date can be either in European or U.S. date format. Leading 0's for month or day are not necessary (ie: 7/4/1994). The year (if provided) can be 1 to 4 digits. The year is optional, and if omitted (ie: 7/4 or 4.7 or 07/04 or 04.07), then the command will execute on July 4th EVERY year. If a 1-digit year is provided, the current decade will be used (ie: if the current year is 1993 and you provide 5 for the year, then 1995 will be used); if a 2-digit year is provided, the current century will be used; if a 3-digit year is provided, the current millenium will be used. A 4-digit year will be accepted as is. - Any command that you can type at the MBBS.EXE control program's "Command => " prompt, can now be optionally entered via a program you may be developing. Simply create a file called TMP.ACE in the PROGRAM DIRectory and write your commands (one per line, each line terminated by a CR/LF - in other words, it's an ASCII text file). No queued commands are allowed (as opposed to the MBBS.ACE file). Commands are to be written exactly the way you'd type them at the "Command => " prompt. After all the commands in the file are executed, Magnum will delete the file. Any text lines not starting with either a digit (node#) or the * character will be discarded. Magnum will check for the presence of TMP.ACE only once per minute. - Powerful new capability added: the ability to program your own actions based on modem result codes! We recommend the VERBOSE modem setting (AT V1) for this. The way it works is as follows. When your modem answers an incoming call, the two modems begin a "handshake" procedure. During this handshake, your modem may return many different information strings to Magnum, such as CONNECT, CARRIER, FAX, ARQ, MNP, LAP, etc. Beginning with this release, you can act on any one of these through an ASCII text file which you create by the name of SPECIAL.x (where x is the node#). These SPECIAL.x files are optional, and you can have one for each node, any node, or none. These SPECIAL.x files are to be located in your PROGRAM DIRectory. By way of example, suppose you have a fax-modem on node1 which returns the word FAX if it determined that the remote caller is a fax machine. Your SPECIAL.1 file might look like this: FAX { ex c:\fax\faxpgm.exe %com% } ARQ { ec } When you start your BBS (MBBS.EXE), it reads the SPECIAL.x files. When the modem returns word results (such as FAX), Magnum compares it against the keywords in your SPECIAL.x file for that node. Your keywords must end with the { character. When it finds a match, it performs the statements it finds for that keyword until the } character is reached. In the above example, when it matches on FAX, the one statement between the curly brackets tells Magnum to EXecute the program c:\fax\faxpgm.exe and pass it the handle of the comport. As you may have guessed, one of the allowable program statements is EX, which means EXecute. In passing command-line arguments to the program to be executed, you may specify any parameters you wish, however, the following parameters have special meaning: %com% - Magnum will replace this with the comport handle. %baud% - Magnum will replace this with the baudrate (DCE). %device% - Magnum will replace this with the device name. There are other allowable program statements. In the above example, the keyword ARQ has as its statement EC - this program statement tells Magnum to treat the connection as an error-correcting connection. For those of you using Verbose modem codes, this would be the means of determining and setting the connection to error-correction = TRUE. Other error-correction word results are MNP and LAP. You are not limited to one program statement between the { and } braces. Other allowable program statements are: PAUSE nnnnn - Pauses nnnnn miliseconds (ie: 3000 = 3 seconds). SEND string - Sends "string" to the modem. "string" is meant to be a message to the user. Modem commands (ie: AT) will not work once carrier is raised. EX pgm [parms] - We covered this above. EC - No parms required (or allowed). Covered above. x cmd | * cmd - Any commands that you can type at the MBBS.EXE "Command => " prompt may also be supplied as a program statement here. NOTE:-At this time, only 5 modem codes (and thus 5 pairs of { and } program statements) are the maximum allowed. This should be more than adequate. Most of the modem codes you would probably deal with are: MNP, LAP, ARQ, FAX Once again, you are not limited to the above modem codes, you can use (and act on) any modem code that your modem returns. The above list of 4 modem codes are merely what we feel would probably be the most widely used. -The EX program statement does not actually start any programs, it merely sets the program to be started ONCE CARRIER IS RAISED! Once the program is actually started, it will start in its own session, and Magnum will terminate the program immediately in the event of a dropped carrier! If you're using the %device% keyword as part of the EX program statement, you should have the OPENMODE parm of your STARTUP.x file for that node configured to indicate S (shared). -The modem codes (ie: FAX) returned by your modem almost never appear on a line by themselves. Keep in mind that the words you're searching for in your SPECIAL.x file(s) (ie: FAX, ARQ, etc) are compared for in your actual modem result strings by checking to see if the word occurs at any point in the string. In other words, if you're searching for ARQ, your modem may actually return: CONNECT 9600/ARQ This will match the ARQ word in your STARTUP.x file because ARQ does indeed occur within the modem result string. -The SEND program statement will work once carrier is raised. Keep in mind that once the commands within your file have finished, the regular program, trademark and copyright notices will be sent to the remote modem (but a 'clear-screen' command will be sent first). This is the purpose of the PAUSE command - you may want to use the PAUSE command after your last SEND statement to make certain the user has enough time to read your SEND statements. DO NOT USE the SEND statement until after carrier is raised (usually indicated by CONNECT). -If you make any changes to a SPECIAL.x file, in order for the changes to "take", you must deactivate the node (x INACTIVE), and re-activate it (x ACTIVE). -Only .EXE programs are allowed. If you wish to run a .CMD file, your EX statement should look like this: EX C:\OS2\CMD.EXE /c SOMEFILE.CMD and you could also include any command-line parameters after the .CMD filename. Note the /c (lowercase) - this is mandatory! - Note that all searching/matching for your modem keywords terminate upon raised carrier! CONNECT is usually the last keyword your modem will return, however, once CONNECT is returned, as far as Magnum is concerned, carrier has been raised! So if your modem is a FAXmodem and returns a string with the word FAX in it AFTER the string which contains the word CONNECT, the match for FAX will never materialize since carrier has already been raised. - New feature: the ability to automatically invoke "Command => " commands at the end of each session. For example, when an onlline user ends their session on node 1, you may optionally have a file ATEND1.ACE, which can have any commands in it that you could ordinarily type at the "Command => " prompt. Each node is associated with its own ATENDnn.ACE file (ie: ATEND1.ACE, ATEND2.ACE, .... ATEND10.ACE, ATEND11.ACE, etc). The format of the file is one command per line. The file is a normal ASCII text file which you create with your text editor. It is extremely important to keep in mind that commands in these files should be short & brief. The same rules apply to these files as they do when you type something at the "Command => " prompt: the BBS is frozen until the commands are finished. Try to refrain from running any programs at this point. Although these files have an extension of .ACE, queued commands are not allowed! Queued commands are ONLY allowed in the MBBS.ACE file. - New "Command => " commands: * ERRLOG ON * ERRLOG OFF If you specify ON, any warning or error messages will be logged to the file MBBS.ERR in your program directory. Note that once ON is specified, the file MBBS.ERR remains open until the BBS is shut down (* ENDNOW), even if you specify OFF. Also note that whenever you restart your BBS (MBBS.EXE), it will delete the MBBS.ERR file upon startup. - If you issue the PLAY command, you can use it as sort of an automated logon. To do this, record your session (log on as //0), and logoff. Edit the resultant MRECORD.x file for that node, removing the logoff command (G) and save the file. - If "x INACTIVE" was typed at the "Command => " prompt (or via .ACE file), even if node x is already inactive, MBBS would remember this and inactivate the node whenever it became active! Fixed. - Some Sysops have reported a scrolling problem with MBBS which would shift everything up by one line. If/when this happens, the MBBS "Command =>" prompt would not function. This problem has been fixed. - Changed "Ring detected on line xx" to "Ring detected on node xx". - To accommodate up to 33 nodes, all configurations of MBBS.EXE have been changed in the area of displaying which nodes are "in use" (ie: someone online). Starting with this release, the three lines below the upper right portion of the screen (below "All Rights Reserved") will hold the display of which nodes are "in use". If the console node is "in use" it will appear within angle brackets. The display of console node prior to this was (assume 4-node configuration): 4(4) if the console was logged onto node 4, or 4(3) is the console was logged onto node 3. The new method will simply be which logical node the console is on (ie: <4> or <3>, etc). This also required changing the display of date and time from: Tuesday, 17 August 1993 - 14:39 to: Tuesday, 17 August 1993, 14:39 =========================================================================== MSESSION.EXE: ------------ - The November release of Magnum v6.00C introduced a bug with AMMO/RMAIL which sent the ENTIRE msgbase to a remote link in the event that the previous link with the same remote system failed. Fix applied. - Changed such that after an RMAIL link, alerts MBBS.EXE to re-activate the node. - Added "POSTED" field to message headers whose creation was on a remote Magnum system. This field shows the date & time of the time the message was posted (received) on your system. - Added "<echo>" field to message headers who's "to" serial number is different than that of your BBS. The word "<echo>" will appear when the message is to be echoed to other systems (in lieu of the word "<sent>" or "<unsent>"). - Changed date & time field of message headers from: "DATE: mm/dd/yyyy TIME: hh:mm" to: "DATE: mm/dd/yyyy hh:mm" - Marked file(s) are now saved between sessions. These are saved as Uid.FMK (were 'id' is the user's id) in the USER DIRectory. All *.FMK files will be deleted whenever a pack of the file database is performed. - Extended file descriptions (message style) for uploaded files were being placed in the last MsgBase (for those who have the extended msgbase) the user was in instead of MsgBase 0. Fix applied. - The "Read Messages Submenu", choice V (View Unread Mail) was taking too long. This has been speeded up by several orders of magnitude. To take advantage of this speed increase, the NEW_MAIL parm of your STARTUP.x file(s) should be set to F (force). If it's set to A (ask), then the speedup will only occur if the user answers Y to the "check your mail" prompt. If it's set to B (bypass), then no speedup will occur unless the user chooses P (personal mail check) in the message menu prior to choosing R (read) and V (view). [NOTE: These menu choices may have different letters on your system] - Changed the user's "[E]nvironment" section such that when they try to change their system password, Magnum will now prompt them for their current password. This will prevent someone from changing a user's password who's logged on to the system but walked away from their terminal for any reason (thus giving someone else the chance of changing their password). - Added choice 25 to user's "[E]nvironment" section. This allows the user to pick a default Editor type (Ansi, Line, or None). If the user does not choose a default editor type (or chooses "None"), Magnum will prompt the user prior to message entry as to which editor to use. - The number of files allowed per batch download has been increased from 9 to 50. Also, the internal length for each filespec has been increased from 60 to 80 bytes (ie: do not exceed a filespec of 80 bytes when using the MILC @E2 or @E3 commands). - Improved speed on "New Files Search" and file "Text Search" routines. - During local (console) logon, file 'uploads' previously aborted if the source filename you're uploading isn't found. Many times this was due to a spelling error when entering the source ('from') filename. This has been changed such that if the source file isn't found, Magnum will re-prompt you for the filename again (a blank name will quit). This should save you some frustration from the previous way. - Fixed bug that would allow R, W, or L access in a FILE*.GRP file without specifying it. The bug was due to not stripping comments out, therefore if the character R, W, or L (case independent) appeared within a comment for that group, access would be given (requires Extended MsgBase module). - Fixed bug of Sysop Menu's "[S]tats" (pack) which didn't delete the physical file on disk which was described by that of a deleted file record. - Fixed the following bug: if Download is chosen, and you choose Y to view or modify marked files, an endless loop would occur if you chose INFO on a marked file that you don't have LIST access to (but have DOWNLOAD access to). - File xfers invoked with the MILC @E2 or @E3 command, or when uploading an "attached file" to a message, would not flag the "<You have new mail>" routine that a file xfer was taking place. Fix applied. - When a user changes the MsgBase (from within the Message Menu), Magnum will now either 1) perform a personal mail check, 2) prompt the user to perform a personal mail check, or 3) bypass the mail check and/or prompt. The action it takes is based on the parameter you supply to NEW_MAIL in your STARTUP.x file for that node. - Due to the nature of high-speed modems, large modem buffers, and other factors, <Ctrl-X> is NOT always trapped during a NonStop File Listing. For this reason, when a user chooses N (NonStop) at the FileListing's "More" prompt, Magnum will now check for the presence of FILECONT.BBS in your SESSION DIRectory. If this file exists, Magnum will display the file to the user. Within this file, you can warn the user that during a nonstop file listing, they may not be able to break out of it! You may also prompt the user as to whether they're sure if they want to continue with their choice of Nonstop. Upon return, Magnum checks the variable @Z0 for the presence of Y or N. If it contains Y, Nonstop filelisting will continue. If N or any other character, they'll be reprompted with the "More" prompt. The prior contents (if any) of the @Z0 variable will be preserved prior to the "More" function ending. An example of the prompting: Do you really want NonStop? (Y/N) => @Z0('yn'); - File Existence tests would intermittently fail (even if the file existed) when attempting to find a file across a network drive. Fix applied. - Enhanced "[W]hos On" command. Who's currently on the system is contained within individual files in the SESSION DIRectory by the filenames of *.USR (where * is the ID number of the user's who are on). The user's city, state and country will also be shown depending on the GEO_PRIVACY setting in the STARTUP.x file for the node the user is on. - If you wish to override the display of the "[W]hos On" command with that of your own, simply create the file WHOS.ON in your SESSION DIRectory. The contents of this file should contain the MILC commands you wish in order to convey the information you wish to display during the "[W]hos on" command. Note that this file will NOT be used for information regarding a NEW (first time) caller - the default display will be used for a first time caller instead. The way the WHOS.ON file works is that it's similar to a displayable MILC file, but it's processed as soon as the password is entered. It's not displayed, but rather interpreted (MILC characters are replaced) and written to the nnnnn.USR file for that ID on that node. Whenever someone does a "[W]ho's On" from the main menu, Magnum simply displays the contents of each of the *.USR files it finds. - In the event that you don't want a certain user to display during the "[W]hos on" command, simply create a file in the SESSION DIRectory by the name of *.USX (where * is their ID number) - this can come in handy for Sysops who don't want their users to know that they're on the system (ie: create a file 0.USX), the actual contents of the file is unimportant. This enhancement also fixes up the problem some Sysops had where the "[W]hos on" command would show users that are no longer logged on. - The "Press Enter" prompt has been removed after display of the following files: QSECnnnnn.BBS IDnnnnn.BBS SECnnnnn.BBS if you want a "Press Enter" after display of these files, use the @C9 MILC command prior to ending the file. - The improper FileSize reporting for "attached files" has been corrected. - When doing a Pack of an extended FileBase who's datafile is NOT the FILE.DAT file in your SESSION DIRectory, the pack would inadvertently overwrite the FILE.DAT file in the SESSION DIRectory with the newly packed database file. Fix applied. - Some Sysops running Rmail have stated they don't want to see the MsgMarkers during the reading of mail. If you are one of these Sysops, simply create the file NOSHOW.RMM (no show of remote mail markers) in your SESSION DIR. The contents of the file are unimportant. If the file exists, no messages which are MessageMarkers will be displayed. - With the introduction of the AGE: parm within the AMMO.MAG file (for those using RMAIL), an expiration date on all MsgMarkers generated will bear an expiration date equal to that of today's date + the number of days in the AGE parameter. If the AGE parameter is set at 0 (no AGE), the expiration date will default to 30 days. If the AGE parameter is LESS THAN 30 days, the expiration date will also default to 30 days. - MILC commands @E81 (change FileBase) and @E83 (change MsgBase) always changed to the base in the @N1 variable, regardless of whether it was a valid base or even if the user had access to it. Fix applied. On the same topic, there was an error in the user manual (v6.00C) for these two commands (page 4-15): it should read that if the variables @N0 and @N1 are equal then the change took place. - The "Read Messages Submenu" now offers three additional choices: '+' and '-' if you have the extended msgbase module, and C to change conference areas without having to go back to the main message menu. Choice '+' will move the user into the next succeeding sequential msgbase the user has access to. Choice '-' will move the user into the next preceding sequential msgbase the user has access to. - When using command-stack chaining (starting your commands with the ';' character), the listing of FileBases and MsgBases will now be supressed if changing File or Msg Bases using command-stack chaining. Requires extended filebase module and/or extended messagebase module. - New MILC commands: @V95 - Returns BBSID (for use with QWK) @O24 - Returns the DEVICENAME used for this node. @O25 - returns OS version (ie: "1.30", "2.00", "2.10", etc). @E4 - Places name of "response file" in @Z0. The "response file" is the name of the file that any @Zx(""); or @Nx(""); requests will be written to. @E5 - Turn off "response file" header. This supresses the header that Magnum writes to the "response file" prior to logging the responses (ie: user's name, id, phone number, date & time, etc). NOTEs: - This works only on the currently-displaying file! If you "include" a file, you must also issue this command from the included file if you want supression. - This command should be issued prior to writing (ie: prior to issuing any @Zx(""); or @Nx(""); commands. @E6 - Override "response filename" with that of the one in MILC variable @Z0. For example, to create a DOOR.SYS file, you would assign the name of the file in @Z0 (ie: @Z0="d:\magnum\ext_dir\door.sys";), then you would issue the @E6 command. Make certain to also issue the @E5 command to alert Magnum to NOT write the response file header! @E7 - Open the (ASCII) file in @Z0 for Reading. Upon successful open, @N0 will contain 0, otherwise an error number. If you open another file with @E7 prior to closing an existing opened file, it will close the existing file first. @E8 - Read one text line (up to 100 chars) of the file opened with @E7 (above) into @Z0. The number in @N0 will indicate how many bytes were read. If 0, the file is automatically closed. Magnum will insure that each line read has a CR/LF pair at the end, therefore, any blank lines read will have at least 2 bytes. The purpose for the @E7, @E8 and @E9 commands is to have the capaibility of reading an ASCII text file and scanning for a match on a certain keyword with the @Bx(@Z0~"keyword"); statement. As a rough example, here's a small example file which only displays those text lines which contain the word "execute". @z0="d:\mydir\read.me"; @c12 @e7 @b99(n0>0); Open was successful! @p0 @e8 @b99(n0=0); @b1(z0~"execute"); @b0; @p1 @z0; @b0; @e9 @p99 @E9 - Close the file opened with @E7 (above). For examples, see the file MAKEDOOR.BBS with this distribution; it demonstrates how to make a DOOR.SYS equivalent for those external door programs which depend on this file (ie: DOS 'doors' such as TradeWars is being ported to OS/2). NOTE: External 'door' programs such as TradeWars which make use of a DOOR.SYS-equivalent file expect their dates in U.S. date format; Magnum writes dates in either U.S. or in European date format depending on what the user's default date format is; you may have to notify the user to change to U.S. date format! The MAKEDOOR.BBS file was placed into your EXT DIR with this installation. If you plan on using it, you will need to modify part of it to reflect things about your system - see the comments within that file. @E14 - ReOpen FileBase 0 (main) @E15 - ReOpen MsgBase 0 (main) These new commands are to be used after calling a .MEX program with the @E0 command (do not use these if calling the .MEX program with the @E1 command). When a .MEX program is called to update a user's file or msg access areas online, the update takes place immediately, however, the information within the file & msg menus don't reflect the change until next logon. Use of the new @E14 and @E15 commands will refresh the access areas to the menus. ==>> NEW NEWS (just in): You can now run certain DOS doors via Magnum!! If you're running OS/2 2.1, you can run a DOS door as follows: - In your STARTUP.x file(s), set your OPENMODE to S (shared). - Your DEVICENAME parm MUST be a STANDARD devicename (ie: COM1, COM2, etc). Non-standard devicenames will not work (ie: DIGI1). - Use the new MILC command @O24 to obtain (and pass to the DOS door) the DEVICENAME. - Only DOS doors that use STANDARD devicenames will work! This method is NOT supported under OS/2 1.x or 2.0. It will only work under OS/2 2.1 so far. ==>> Download MAGFOSS.ZIP from our BBS... it will allow you to run almost any DOS door!! - Since Marked Files are now saved between sessions, logic was implemented to delete these saved files in the event of a file 'pack'. However, what we failed to realize was that Expired or Deleted files (which became expired or deleted since the user's last logon), were still saved in the user's list of marked files (this presented a problem when the user went to modify, list, or download marked files). Fix applied. Note: whoever is online issuing the pack command (usually the sysop or cosysop), their file of 'marked files' (if it exists) can not be deleted. After a pack, you must delete it manually (extensions with .fmk in the USER directory). - When in the [E]nvironment menu, if the user's lines/screenpage is greater than or equal to 28, there will be no break in the display of the settings. If the user changes from a lines/screenpage of less than 28 to 28 or greater, the Environment menu itself won't recognize the change until the next time the user enters the Environment menu (ie: they'll have to Quit, then re-enter the Environment menu). - When doing "[S]tats of Databases" from the Sysop menu: if you're using an Extended FileBase or Extended Msgbase such that you've defined more than one FileBase or MsgBase within the same database file, the system will now show you the number of records it found which ARE in the currently selected base. This number will show up within angle brackets after the FileBase indicator. - Fixed bug which would save a "file description" message with the wrong name. - When forwarding a message to someone from the message disposition prompt, you'll now be returned back to that message disposition prompt after entering the ID(s) of who to forward the message to. - When in the Group Chat section, issuing a /WHO command will produce the same results as issuing the "[W]hos On" command from the main menu. This is for consistency as well as making the Sysop (or others) appear invisible on the system when using the *.USX file feature. - New Feature: When the Sysop (or CoSysop) is reading a message while in the the Message Section of the BBS, pressing the <Ctrl-E> key (at the message disposition prompt) will now prompt you as to whether you wish to edit the M)essage or the H)eader. After editing, you'll be returned to the message disposition prompt. - New Feature: When the Sysop (or CoSysop) is in the File section and has entered the name (or #nnnnn) of a file to the "Utilities" prompt, they can press the <Ctrl-E> key in order to modify the record for that file. - When in the Sysop menu, if you choose "Remote Sysop Console", it would only work if you dialed in on a single-digit node (ie: node 1 thru 9). Fix applied. - In the message section (and other sections), choices which are defaults such as "(N)ext, [A]gain, [B]ackthread" were enclosed within parenthesis rather than square brackets. This has been changed to angle brackets instead (ie: "<N>ext, [A]gain, [B]ackthread"). If I missed any, let me know! - When in the Sysop menu, User Database area, moving on to the Next record would prompt you with "Delete User (Y/N) => " if that user record is deleted. This is fine, but with many sequential deleted records, you'd be stuck answering this prompt for every record with no other way out until you came across an undeleted record or the last record in the user database. Therefore, the (Y/N) portion has been changed to (y/n/Q) where Q (the default) means Quit. - When in the Sysop menu, User Database area, if you change any field of anyone's record, Magnum would check to see if they were online. If they are, Magnum would go ahead and update their record in online memory. This is wrong! Most Sysop's set up their BBS's such that ALL nodes point to the same SESSION DIRectory. However, in the case of those Sysops who set up some nodes to be different BBS's (ie: different SESSION DIRectories), the online user may not even be a part of that BBS! I've fixed the code so that when it matches on an online user's user id, it then goes and checks to make sure the BBS they're on is also pointing to the same SESSION DIRectory before making any online changes in memory. To make this a little clearer, suppose you had node 1 and 2 set up as a BBS for motorcyclists (session directory is d:\magnum\cycle\ses_dir), and nodes 3 and 4 set up for your church group (session directory is d:\magnum\church\ses_dir), and node 5 (assuming 5-node version) is your local console node. If you log on locally using the node 3 configuration, (ie: * LOGON 3) to get to the church group BBS, then enter the Sysop menu and pull up the record of ID: /10 (for example), and someone with an ID of /10 just happens to be online on node 2 (the motorcycle bbs), if you make any changes to record 10, their entire online record (in memory) would be updated! This means (for example) that ID /10 with a name of "Pack Leader" would become ID /10 from the 'other' BBS with a name of "Father O'Reilly". That's the reason the check for the matching session directory needed to be thrown in! - Fixed problem with ANSI message editor where message text would be left over after choosing some of the options in the <ESC><ESC> menu. - When responding (replying) to a message with the ANSI editor, bringing in any marked lines from the message being replied to was too slow. This has now been sped up: instead of updating the entire screen for each inserted line of a marked block, the insertion of the entire block will now be performed in memory first and the screen will be updated once at the end of the insertion. At the end of the update, the cursor will remain on the original line that the insert was started from. - New: The ANSI message editor will now attempt to adjust the number of text lines in the text-entry area to that of users with lines/screen sizes of 28 or greater. - New: When logged on via the CONSOLE (only), the ANSI message editor will now recognize the <Ctrl-End> key combination to mean to delete all characters on the current line starting at the cursor position to the end of the line. - Enhanced: When re-reading a message you're responding to with the ANSI editor with marking facilities, the - - MORE - - prompt formerly prompted you to press any key to continue. This forced users to read the entire message first before they could mark any text lines. This has been changed such that the - - MORE - - prompt will now prompt you for (Y/n) where if you supply N, the display of the message will stop and you'll be able to mark any text lines - even if those lines haven't been displayed - as long as you know which line numbers those text lines are on. - New: when in the message database area of the Sysop menu, you may now supply a record number in response to the prompt which will take you to the nth message in that message database. Start the record number with the # character. Example: #850 will take you to record number 850. If you supply a record number out of range, you'll receive a beep and will be reprompted. - New: The inclusion of RJE Database in the "Stats" section of the Sysop menu, as well as the ability to Pack the RJE Database. Deleted records can only be marked as deleted by a .MEX program! - Enhanced: Many Sysops have complained about users forgetting about their middle names when logging on by name. This release will match on first and last name and attempt to match on middle name if present. For example, "John Smith" will match on "John F Smith" or "John David Smith", etc. Also, "John S Smith" will match on "John S Smith" or "John Steven Smith". "John Steven Smith" will also match on "John S Smith". If the match is not correct (ie: the prompt "Is this correct (Y/N) => " is answered with N), the user will then be prompted as to whether to search further or to re-enter their name. - Modified Ammo/Rmail such that ZFRONT.EXE is no longer needed when using InfoZip's UNZIP.EXE program. - Fixed bug when using the MILC @B (branch) command to branch to a forward reference (a @P label appearing later in the file) which would result in certain formatting problems. - The timer is now stopped during SysChat (chat between sysop and user) when the Sysop presses <F7> to start the chat. When the Sysop presses <F7> again to terminate the chat, the timer will reactivate (note that there may be a delay of up to one minute before the timer actually restarts). - When the user chooses to Enter a new message, Magnum will now check for a file by the name of NEWMSG.BBS in your DISPLAY DIRectory. If it exists, this file will be displayed to the user. The purpose of this file is to notify the user of anything you wish, most likely to tell them to enter a message to a specific ID (ie: /1) for "technical support", or some other specific ID on your system. - The logon entry (First name or /ID => ) has once again been enhanced. In that up to 20 characters are allowed for a first name, if a user can supply their entire name on the 'first name' entry line, separating their first (optional middle) and last names with either the space character or the ; character, Magnum will take the entry as supplied. - When supplying filenames (or file numbers) to download prior to downloading with a batch protocol, Magnum will now accept up to 100 characters in response to any filename prompt. This will enable the user to specify multiple filenames, separated by spaces or by the ; character without having to wait for the prompt for the next filename to download. Normally, this is only accomplished by command-stack chaining (ie: starting with the ; character), however, in order to be compatible with other systems, we've implemented this new feature. - The message "Caller on Node xx is Paging You..." would appear wherever the current cursor happened to be. This has been changed to apppear at column one of the next line. - Fixed problem with @C5 and @C6 MILC commands. - Intelligence added to slightly boost priority levels during file xfer. - Problems with the buffer that holds dynamically-generated menus fixed. - Problems with the "More" prompt being erased are fixed. - NEW: In that only 255 file groups and 255 message groups are allowed with the extended filebase and extended msgbase, we've added the following feature: - If the file Uxxxxx.MG exists (where xxxxx is the user's id number), this file will be used INSTEAD of any MSG group that user is assigned to. - If the file Uxxxxx.FG exists (where xxxxx is the user's id number), this file will be used INSTEAD of any FILE group that user is assigned to. The format of the Uxxxxx.MG and Uxxxxx.FG files are identical to that of the corresponding .GRP files. If you create Uxxxxx.FG or Uxxxxx.MG files, they are to be placed in the SESSION DIRectory. Do not use leading zeros for the xxxxx portion! Examples: U0.MG - Group File for ID 0 for MsgBase access U156.FG - Group File for ID 156 for FileBase access - When viewing a user's record in the Sysop menu, whatever File Group or Msg Group they're assigned to will be followed by the '*' character if the override file (Uxxxxx.?G) exists for that user. =========================================================================== MAKEMBBS.EXE: ------------ - The ANSWERTYPE parm can now be the character D to indicate DCD. This is for certain WANs in which a "modem" appears to be present, but only the presence of a carrier is used to determine an incoming call. The baudrate of the incoming call will always be equal to the BAUDRATE parm. - The following fields in your STARTUP.x file(s) can now be blank (ie: no parms required): MODEMRESET, STARTUP1, STARTUP2, STARTUP3, REINIT. This is by popular demand. Examples of where parms for these fields are meaningless or unnecesary: Device is a pipe, console node, WAN, serial port connected to null modem cable & dumb terminal, etc. - Support now added for 57600 baud (DTE rate) as a parameter to the BAUDRATE keyword. - For those using Numeric modem result codes, the following keywords have been added to support the new 16800 baud connections available on some modems (such as the new US Robotics HST dual standard): RC_16800 ERC_16800 ERCA_16800 ERCB_16800 - The default PRTY_CLASS and PRTY_LEVEL have been changed (defaults are used only when you don't specify a parameter to these keywords in your STARTUP.x file(s)). The default PRTY_LEVEL is now 2 for all nodes. The default PRTY_CLASS is now 0 for the console node, 10 for all other nodes. - Added Four (required) keywords: MSGMENU_BASEUP:- Moves to next succeeding MsgBase (requires extnd MsgBase) MSGMENU_BASEDN:- Moves to next preceding MsgBase (requires extnd MsgBase) FILEMENU_BASEUP:-Moves to next succeeding FileBase (requires extnd FileBase) FILEMENU_BASEDN:-Moves to next preceding FileBase (requires extnd FileBase) If you're not using (or don't have) the optional extended MsgBase module, then the security levels of MSGMENU_BASEUP and MSGMENU_BASEDN should be set to a level higher than that of the Sysop so that these menu choices will not appear online. If you're not using (or don't have) the optional extended FileBase module, then the security levels of FILEMENU_BASEUP and FILEMENU_BASEDN should be set to a level higher than that of the Sysop so that these menu choices will not appear online. - Added four (optional) keywords: FILEGROUP: - Default FileGroup (0-255) for new user MSGGROUP: - Default MsgGroup(0-255) for new user The FILEGROUP keyword should only be used by those sysops with the optional Extended FileBase Module. The MSGGROUP keyword should only be used by those sysops with the optional Extended MsgBase Module. Even with these modules, the use of these keywords are optional, and if not supplied, will default to 0 (no FileGroup and/or no MsgGroup). The use of FileGroups and MsgGroups will significantly speed up the new capabilities implemented by the four new keywords described above. MENU_HILITE: - Allows you to specify a character and color which tells Magnum to change the color of the character immediately following it. Example: MENU_HILITE: ~12 This tells Magnum that the ~ character means to change the very next character to color 12 (see the MILC @A command for color number meanings). With this method, your menu choice definitions in your STARTUP.x file(s) can look like: MAINMENU_MSG: M,5,[~M]essage Section which tells Magnum that the character M is to be changed to color 12 (bright red). If the online user does not have their color settings on, the ~ character (or whatever character you specified in the MENU_HILITE parm) will simply be stripped, and no color change will happen. Note that this character will also be stripped for color users. NOTE: *** Do NOT use the [ character as the parm for the MENU_HILITE keyword!! MENU_COLOR: - Allows you to override the default color of 2 (green) in which dynamic menus are built. For example, to present your menus in brown: MENU_COLOR: 6 NOTE: External Menus ALWAYS override the dynamic menus!! =========================================================================== MSGLIST.EXE: ----------- - Prior to this version, mail received from other systems (via AMMO link) were not included in mail lists created by MSGLIST.EXE if the date did not fall within the start & stop date of the MSGLIST parameters. This has been changed to include mail based on the date the msg was POSTED on your system, rather than the date the mail was created. For those msgs whose posting date on your system are different than the creation date, the posting date will be appended to the subject field as <<MM/DD/YYYY>> or <<DD.MM.YYYY>> depending on the user's date format. - Incorporated enhancements to generate mail in QWK format. To specify QWK mail format, the last command-line parameter to the program (optional msgbase) should be immediately preceded by the letter Q (no spaces between the Q and the msgbase). NOTE: Change the PHONE1 parameter of the SYSOP user record (ID: /0) to indicate your main BBS Phone#! - The processing time (speed) has been dramatically improved! - ALL MsgBases on the system can be generated by specifying Q* as the last parameter to the msglist.exe program. A new MSGLIST.RJE file has been included to incorporate this capability. The generation of ALL MsgBases is only possible with the QWK option (not with POWER). Note that when ALL MsgBases are specified, conference names are supplied only for those conferences in which actual messages were produced. If generating a specific MsgBase (as opposed to ALL MsgBases), conference names will be supplied for ALL conferences the user has access to in that MsgBase. - If the QWK portion is used, the resultant QWK file will be placed in the download RJE area of FileBase 0 and will follow the naming convention of RJE files EXCEPT that the extension will be .QWK instead of .ZIP - this eliminates the need to enclose the .QWK file within a .ZIP file. In other words, the naming convention is Uid@n.QWK where id is the user's id, and n is a character 0 to 9 or A to F. The file will be password protected with the user's logon password. If the user's logon password exceeds 10 characters, only the first 10 characters will become the password. Just for fun, you could add the following lines to your COMPRESS.LST file: .QWK: D=PKUNZIP2.EXE -o %s L=PKUNZIP2.EXE -v %s if you do this, this would enable the user to view the contents of this file just as if it were a .ZIP file! Personally, I wouldn't recommend this because it tempts the user to spend more unnecessary time on your system when they could just download the file to begin with. - If the QWK portion is used, you can have the following optional files in your SESSION DIRectory. If present, they'll be included in the QWK packet: HELLO.Q - The 'Welcome' file to be included in the QWK packet. NEWS.Q - The 'News' file to be included in the QWK packet. GOODBYE.Q - The 'GoodBye' file to be included in the QWK packet. note that these files need not be text files, they may also contain ANSI escape sequences. There is NO MILC processing. These files (if present) are merely copied verbatim into the QWK packet. - If the file NOSHOW.RMM exists in your SESSION DIRectory, then MsgMarker(s) will not be included in your POWER or QWK file(s). - Abides by the Uxxxxx.MG file (if it exists) in lieu of the MSGxxx.GRP file [if extended MsgBase module installed]. =========================================================================== RJEMONIT.EXE: ------------ - The code within this module to lower its priority to 'idle class' was located in the wrong place. It's now been moved to the right place. =========================================================================== RJEQWK.EXE: ---------- - This is a new program, equivalent of RJEPOW.EXE (for uploaded POWER message responses) but for uploaded QWK message responses. NOTE: As of this writing, PK-Ware has not released their OS/2-equivalent of their DOS version 2.04 ZIP format. =========================================================================== RJEPOW.EXE: ---------- - The SUBJECT line of an incoming message would sometimes be blank if its a reply to an existing message. Fixed. =========================================================================== MBBSEXEC.EXE: ------------ - The runtime display of "Record: xxx of yyy" has now been changed to just "xxx" for purposes of speed gain. "yyy" is displayed on the line above the "xxx" line and is only displayed upon program start. - By popular request, when changing a file AREA, the physical file is also moved to the directory described by that area. - Added new Keyword for USER database: @EDITOR_PREF This keyword refers to the user's preference of L (Line editor), or A (Ansi editor). - Add new Keywords for FILE database: @CDROM - This keyword (if alphabetic) indicates the file is on a cd-rom or other drive described by a directory which is external to the file database. @PATHNUM - This keyword indicates which path number to use in the external pathname file (if @CDROM is alphabetic). Ordinarily, you will have no use for these two keywords, however, those of you writing in-house applications which interface with Magnum may have a use for these. - When processing the USER database, if a change is made to the @REMAINING field, Magnum will now recognize this and respect it if the user who's record is being changed is online at the time of the change. If their time remaining for the period is less than the new change to their time remaining (for this call), the time remaining for the period will also be adjusted. - Corrected a bug which updates an online user who's on a node that's configured as a "different" BBS than the one described in the MBBSINIT.x (STARTUP.x) file being used by MBBSEXEC. Ordinarily, most Sysops configure all of their nodes as the same BBS (ie: the same SESSION DIRectory), so this bug has gone undetected for quite some time. The correction now compares the SESSION DIRectory of the one used during MBBSEXEC processing and compares it to the SESSION DIRectory of the online user(s) who's ID matches the record being processed - if the two SESSION DIRectories match, the change is made online, otherwise the online change is ignored for that node. - The keyword @K_DL_THIS_PERIOD was being mistaken for @K_DL when processing the USER database. Fix applied. - The read-only variable @RESULTCODE is now set when doing a string compare with the ~ comparator (string within a string). The value of @RESULTCODE will be 0 if no match, otherwise it will be the starting position of the place within the string the match was found. For example, if @STRING1 contained "a musical instrument", then the following statement would set @RESULTCODE to 3: if(@string1 ~ "music") { . . } - By popular request, the new function EXTRACT() has been added. This function requires four (4) parameters: EXTRACT( target_string, source_string, start_position, byte_count ) This function can extract any portion of source_string and place that extracted portion into target_string. For example: @string1 = "Hello there, my name is Joe" @string2 = "name" if(@string1~@string2) { extract(@string3,@string1,@resultcode,9) } The above code sample uses @string3 as target_string, @string1 as source_string, @resultcode as start_position, and 9 as byte_count. The statement extracts from @string1 (the source_string), 9 characters (the byte_count) beginning at position 17 (the start_position of where "name" appears within @string1. The resultant target_string (@string3) will contain (without the quotes): "name is J" Now for the rules: target_string: must be either a @STRINGxx variable or a number. If a number, the number represents which @STRINGxx variable to use. source_string: must be either a @STRINGxx variable or a string literal (enclosed in doublequotes - ie: "hi there"), or a number. If a number, the number represents which @STRINGxx variable to use. start_position: must be one of: a @TALLYxx variable, the @RESULTCODE variable, or a number. byte_count: must be one of: a @TALLYxx variable, the @RESULTCODE variable, or a number. NOTEs: - no indirect addressing is allowed within any of the EXTRACT() parameters! - if the value of start_position is out of bounds during runtime, the program will abort with an error message which states the contents of the variables. Under normal operations this should never happen. - If the value of byte count is more than the number of bytes in the string from the starting position, then only the number of bytes left in the string will be extracted. For example, if you find the word "music" in a string and want to extract the entire string from that word on, set the byte_count parm to 999 or some other large number. =========================================================================== USERS OF RMAIL (AMMO): --------------------- - MsgMarkers are now marked with the 'echo' field 'off'. - New optional paramater can now be placed anywhere within the AMMO.MAG file (as long as its on a line by itself): AGE: xxx where xxx is the age (in days) of messages which are allowed to be sent to or received from other systems. For example, if you have: AGE: 20 then no messages older than 20 days will be sent to other systems. Likewise, no incoming messages older than 20 days will be accepted by your system. The age (in days) of a message is determined by its creation date (the date the message was created). This feature is HIGHLY recommended for all Sysops participating in AMMO/RMAIL. The "AGE: xxx" (without the quotes) specification is not limited to appear only once in the file. You may place it on however many lines of your AMMO.MAG file that you wish, each occurrence can have a different parameter. Once this specification appears in the AMMO.MAG file, the age you specify is in effect until another AGE specification appears in the file, or for the remainder of the file (whichever occurs first). You can even have a different AGE parameter for every serial# if you wish by placing an AGE statement on the line immediately before a particular serial#. One excellent example of how this feature would be of great significance is when you're setting up a new AMMO account: without the use of the AGE field, your first link with a new AMMO account will receive your entire messagebase(s). You may want to limit the outgoing messages to this new account by, say, 60 days. Also, for informational purposes, a parameter of zero (ie: AGE: 0) turns off this feature (ie: no age calculations will be performed). - All MsgMarkers will now be stamped with an expiration date of 30 days. If your AGE parameter is greater than 30 days, MsgMarkers will be stamped with an expiration date of AGE days instead. - A new copy of RMAILMAP.EXE was placed in your SESSION DIRectory. ALL PROGRAMS: ------------ - Any programs (.EXE) supplied with this Magnum revision which deals with compressed (ie: .ZIP, .ARC, etc) files will now abide by the rules of your COMPRESS.LST file (if it exists). If it does not exist, an internal default will be used. NOTE: Do not override the default of PKZIP2.EXE (the old pk-ware format) if you're using AMMO/RMAIL. Some systems are still using the older format and will not be able to unzip your mail packet! You may, however, override the PKUNZIP2.EXE default (or replace PKUNZIP2.EXE in your EXTERNAL DIRectory). - Programs which set or use the hardware buffering built into your UART (if your UART auto-buffers) have had the code that disables this buffering removed. This applies to: MBBS.EXE, MSESSION.EXE, GETFILES.EXE, and the PUTFILES.EXE programs. ------------------------------------------------------------------------- GENERAL NOTES: ------------- - OS/2 2.1 GA has many problems. Most notably, the COM.SYS driver supplied with the OS seems to slow the overall system down, and cause problems with RJE and SYS3175 errors. I strongly recommend using Ray Gwinn's drivers instead (download SIO102.ZIP) from our BBS which is orders of magnitude faster and more stable than IBM's drivers. And by all means, help Ray with a contribution towards his great software. - OS/2 2.1 GA has returned the 'hung session' problem. IBM is 'working on it' but it seems that this problem has disappeared if using Ray Gwinn's SIO driver. - MultiMedia and OS/2 2.1 GA 'break' the API call DosSetMaxFH() which obtains more file handles for the application. Until IBM comes out with a fix for this problem, Magnum will not run when MultiMedia is installed. However, we've come up with our own workaround: create a file MMPATCH in your PGM_DIR (program directory) -- the contents of the file is unimportant, only its existence is checked. If the file exists, the code to work around the MultiMedia problem will be invoked. Do not forget to delete this file if/when IBM releases a fix for the MultiMedia problem. - In OS/2 2.1: from time to time, when a session starts (as an icon), the OS will place the icon for that session directly over an icon for another session. Moving (dragging) that icon out of the way reveals the other icon underneath it. - OS/2 2.x doesn't seem to want to display our icon file. To get around this, create the following statements in your MBBS.ACE file: *,1 icon d:\magnum\pgm_dir\msession.ico *,2 icon d:\magnum\pgm_dir\msession.ico . . . of course, you'll need to substitue the path name you're using on your system; and the three dots merely represent additional statements, one for each node you have on your system. In that these are "immediate" commands (read only on startup), you'll need to shut down the bbs and restart it in order for these commands to "take". - PK-Ware doesn't seem to be making any progress in coming out with an OS/2 version of their ZIP utils for 2.04G format. You can download UNZIP16.EXE from FileBase 0 on our BBS to get InfoZip's OS/2 version which DOES support it. You can either rename this to PKUNZIP2.EXE and place it in your EXTERNAL DIRectory, or modify your COMPRESS.LST file accordingly. - For those running OS/2 2.1 GA and wish to run DOS doors (just about any door that runs under DOS BBS's), download MAGFOSS.ZIP from FileBase 0 on our BBS. This offering from Greg Rumple makes it such that Magnum will run virtually any DOS door program under OS/2 2.1 GA. If you take advantage of Greg's driver, please help support his development efforts with a contribution so that we can see more of his excellent software in the future! --------------------------------------------------------------------------- CLOSING REMARKS --------------- Good news: if you've been waiting for PK-Ware to release their OS/2 versions of the ZIP/UNZIP programs which support the 2.04G compression format they've released under DOS, you can download UNZIP16.EXE from our BBS and use it while you're waiting! You can either rename it to PKUNZIP2.EXE and replace the current PKUNZIP2.EXE with it; or keep the same name (UNZIP16.EXE) and place it in your EXTERNAL DIRectory and modify (or create) your COMPRESS.LST file accordingly. UNZIP16.EXE works under both OS/2 1.x and 2.x. Users of OS/2 2.x: IBM's COM drivers are (as usual) not the greatest (they've even been known to hang the system). I strongly recommend downloading Ray Gwinn's comm drivers and using these instead. The latest release (as of this writing) is available for download on our BBS under the name of SIO102.ZIP and is located in FileBase 2. This is a supberb piece of work, please send in your registration fee to Ray if you plan on using these drivers for more than 30 days (which I'm sure you will). If you're using an intelligent serial board such as Artic or Digiboard, disregard this paragraph, as the drivers for these boards are supplied by Quadron (for Artic cards) or Digiboard (for Digiboard cards) disregard the above. If you're using DigBoard, please call their BBS and download the latest revision of their drivers. Their current drivers (as of this writing) have some problems which are easily fixed by downloading the new ones. End.