home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
High Voltage Shareware
/
high1.zip
/
high1
/
DIR10
/
GT1800_3.ZIP
/
GT1800_1.LZH
/
README.176
< prev
next >
Wrap
Text File
|
1992-07-23
|
30KB
|
788 lines
===============================================================================
Release Notes for GT POWER 17.06
June 29, 1992
===============================================================================
-» If you are running a modem with a fixed DTE and floating DCE, the
two baud rates will now be displayed on the status line... it will
look something like this:
24:192
Which means: DCE Baud = 2400 and DTE Baud = 19200. The zeros are
dropped off to conserve space on the status line.
-» GT now supports COM1 through COM8, and IRQs 0 through 15. These
extra IRQs, above 7, are only available on AT/286 and 386 machines.
I must admit I don't have a COM port above IRQ 7 to test with, I have
followed the instructions for implementation of the higher IRQs that
is found in the book "PC System Programming" published by Abacus... it
is about the size of a large phone book <GRIN>. The COM ports have the
following pre-assigned addresses and IRQs:
COM PORT HEX ADDRESS IRQ
-------- ----------- ---
1 03F8 4
2 02F8 3
3 03E8 4
4 02E8 3
5 4220 3
6 4228 3
7 5220 3
8 5228 3
The port addresses for COM5 through COM8 were obtained from a book called
"Windows 3.1 Secrets" published by Info World, and correspond to those
used on MCA-bus machines. However, please note, GT requires any COM port
it uses to have an IRQ all to itself, despite that fact that most of these
are shown as IRQ3.
GT uses the addresses for COM1 through COM4 that are normally used on
ISA-bus machines, in other words, MCA-bus machines use 3220 and 3228
for COM3 and COM4 respectively, and IRQ3 for COM3.
Remember the command line option to specify these odd-ball ports...
/3 $3220:10
Would specify COM3 at address 3220 hex and IRQ10.
Of the high IRQs, normally 10,11,12 and 15 are unused. According to
the book, IRQ9 may also be available, but it is less clear.
-» At the recent convention in North Carolina, many people expressed the
desire to bypass the new files inquiry for directories that are located
on a CD-ROM drive. Therefore, I have added a switch to the GTDIR.BBS
file to allow this to happen. The switch is ",CD", and here is an
example of its usage:
E C:\GT\GENERAL,,C:\GT\FILES\GENERAL.BBS,CD General file area
^ ^ ^ ^ ^
| | | | |
| | | | This switch forces GT to bypass the
| | | | new files inquiry on this file area.
| | | |
| | | This is the full pathname of the file containing
| | | the file descriptions for this file area.
| | |
| | This is an empty field, reserved for future usage, it
| | will contain the symbolic name associated with the file
| | area, for use with a future "GOTO" command.
| |
| This is the pathname for the file area, i.e. where the files
| for download are actually located. If there is not a separate
| path name for file descriptions, then the FILES.BBS will be
| placed in this directory.
|
The minimum access level required to gain access to this file area.
-» The (M)ove command appears on the message reading sub-menu. With this
new command, messages can be copied to any other message base, even moved
to netmail. The original message can be deleted or retained. A note can
be added to the message, if the sysop wishes to explain why the message
was moved.
The "MV" permission has been added to the GTPASSWD.BBS authorization
list, so that non-sysops can be given the ability to execute the (M)ove
command.
-» The carbon copy feature allows us to send the same message to a group
of people. The list of names may appear in the message itself or be
contained in a separate file. This feature is controlled via dot
commands. Like other dot commands, a '.' is put into column 1 of any
line of the message, followed immediately by the appropriate commands.
Probably the most familiar dot commands are: .CS, .GL, .GM and .RR.
Now there are a couple of new ones:
.CC ..... Carbon Copy. For example:
.cc John Doe,64/2
This command would send a "carbon copy" of the current
message to "John Doe" on net/node 064/002.
.cc John Brown
This command would send a "carbon copy" of the current
message to "John Brown" in the current conference.
.BC ..... Blank Carbon. This command works like the .CC command,
except that this carbon is not included in the distribution
list. This is neat, if you want to send a carbon to someone,
but not alert the others receiving carbons.
Pre-canned distribution lists.
It is anticipated that folks will have distributions that they repeat
over and over again. So, by using the '@' syntax, the .CC command
can be used to call up a pre-written distribution... as follows:
.cc @c:\gt\betadist.lst
The full pathname must be declared for this entry. If the pathname
is omitted, it will default to the GTPATH directory. The contents
of the distribution file, is the same syntax as would appear in the
regular message (given above). For example:
.cc John Fisher,22/1
.cc Rob Roesch,64/3
.cc Red Gambrell,33/16
.cc Stephen Ricciardelli,9/400
This is an excerpt from my BETADIST.LST file. Also, it is possible,
in pre-canned distributions, to blank out the names and replace them
with a comment. For example:
.la Beta Distributors
.cc John Fisher,22/1
.cc Rob Roesch,64/3
.cc Red Gambrell,33/16
.bc John Doe,1/33
.cc Stephen Ricciardelli,9/400
Notice the .LA command on the first line. The .LA command can only
appear in pre-canned distributions, and if it appears, it must be the
first entry in the file. .LA is short for .LABEL, which can be spelled
out if desired. If a .LA line is at the beginning of the pre-canned
distribution file, then no names are shown on the carbon copy list in
the message, rather it would show like this:
Carbon Copy: Whatever your label designates goes here
In my example above:
Carbon Copy: Beta Distributors
Note, it is possible to mix netmail responses with local conference
responses. For example, this is okay:
.cc Stephen Ricciardelli,9/400
.cc John Doe
.cc Perry Alexander,32/1
The first and third carbons would be delivered via netmail. The 2nd
carbon would be placed into the currently selected conference.
The "CC" permission has been added to the GTPASSWD.BBS authorization
list, so that non-sysops can be given the ability to send carbon
copies.
-» The number of external protocols supported has risen from 16 to 18.
-» There is a new switch in the external protocol table (under Alt-I).
The DSZ Log switch. If this switch is set to 'Y', then GT will get
the transferred filenames from the DSZ log.
IMPORTANT: Care must be taken when upgrading, to make sure the DSZ Log
switch isn't turned on accidentally -- since it is in the
same position that used to be occupied by the redundant
overlay switch.
To enable this feature to work properly, several things must be done:
a. The DSZLOG environment variable must be setup, probably in your
AUTOEXEC.BAT file. And it must contain a full pathname for the
DSZ log file. For example:
set DSZLOG=c:\gt\logs\dsz.log
b. The DSZ log should be emptied before the external protocol driver
runs, since GT will process all the names in the log! Here is an
example that I have used:
del %DSZLOG%
dsz port %1 handshake both rz
if not exist %DSZLOG% goto end
type %DSZLOG% >>c:\gt\zmodem.log
echo ******** >>c:\gt\zmodem.log
:end
This is my DZRX.BAT file. Notice that I first delete the DSZ log,
then run the DSZ program. Finally, I save the DSZ log, by appending
it to the end of my ZMODEM.LOG (just in case <GRIN).
My DZTX.BAT file looks very similar, so I didn't see any reason to
include it here.
c. Make sure that the protocol driver is setup and able to produce
DSZ logs. This is very important, as some protocol drivers, or
unregistered protocol drivers, may not produce DSZ logs.
d. The final thing you must do to enable the DSZ log inside of GT is
to put a 'Y' in the DSZ log column of the external protocol table,
so that GT knows which protocols are going to use the DSZ log. At
this time, I assume DSZ, GSZ and HSlink are the only ones.
Here is a sample DSZLOG... for whatever it is worth! Detailed
descriptions of this format are given in the HSlink docs.
h 227596 10100 bps 1138 cps 0 errors 112 2316 C:\GT\UP\TEST1.DAT 0
H 177901 10100 bps 1116 cps 1 errors 0 749 C:\GT\UP\TEST2.DAT 0
Z 6121 19200 bps 1020 cps 0 errors 0 1024 gateway2.arj 0
Z 14144 19200 bps 943 cps 0 errors 0 1024 duser110.arj 0
-» Caller selectable multiple upload directories ARE now supported. This
is optional, like most new features. To enable the option, the sysop
must create a GTUDIR.BBS (an upload directory list). The format is
similar to the format used in GTDIR.BBS. Here is a sample:
Upload directories
z C:\GT\OBJ Home GT directory #2
z C:\GT\C General file area
=E C:\SPECIAL Special Purpose Area
A C:\PRIVATE Private upload directory
If you have a GTUDIR.BBS, when the caller begins an upload, he/she will
be presented with a list of directories to choose the upload to go
into. Directories can be dedicated to a particular class of caller
by using the '=' notation, as shown. The selected upload directory
will override the upload path from the GTPASSWD.BBS (in fact, if you
use the GTUDIR.BBS, the upload path from GTPASSWD.BBS is redundant).
-» The (Y)our info command, on the host main menu, has been expanded to
include the change of phone number, city/state, and password. Any
changes made are logged... both old and new values are logged.
In order for the caller to change any value, he/she must know their
old phone number to verify his identity.
In addition, the caller must have the PW authorization to change the
password. If you don't give the caller the PW authorization, then
the password will not be presented for change.
For security purposes, all passwords are now erased from the screen
after the ENTER key is pressed. To keep people from easily reading
them over-your-shoulder.
-» Rudimentary support for the Chinese Big-5 character set is being
introduced with this release. Specifically, in the past, it was common
for a Big-5 character to be split between two lines of a message. Half
at the end of the first line, and the 2nd half at the start of the next
line. I have attempted to correct this situation, with the kind help
of Raymond Wood and the Taiwanese Sysops... many thanks to everyone who
helped. I hope it works <GRIN>.
-» Multi-language support. The sysop now has the option of creating
a file called GTLDIR.BBS, which will contain the definition of a
menu. This menu will be presented to the caller immediately after
the GTSYSID.BBS screen has been displayed, and prior to the ANSI
graphics question.
The GTLDIR.BBS will have the following format:
starting in column 1: the name of a batch file to be executed
if the related menu option is selected by
the caller.
At least 1 blank must follow the batch
filename.
Following the blank there must be the text
to appear on the menu.
Any line beginning with a blank character is display for the
caller as explanatory text. Comments may be included by placing
a semi-colon in column 1.
For example:
------------
; This semi-colon is in column 1, and makes this a comment.
Language Selection Menu
; Language 1 is probably the most likely choice.
GTLANG_1 Language Number 1
GTLANG_2 Language Number 2
GTLANG_3 Language Number 3
; The end
This would appear on-screen for the caller like this:
Language Selection Menu
1. Language Number 1
2. Language Number 2
3. Language Number 3
Enter Language Selection:
The batch files, GTLANG_1.BAT, GTLANG_2.BAT, GTLANG_3.BAT
should contain simple copy commands. Copy commands that move
into place BBS/CBS screens matching the selected language entry.
Nothing heavy duty should be done in these batch runs, as there
will be limited memory available.
After the language batch file has been run, GT will display
a new screen, GTANSI.BBS, for the caller. This is just prior
to the ANSI Graphics question.
-» The mail check command has been added to the main menu via the [CK]
command keys. Be sure to update menus and help screens as appropriate.
-» A new parameter has been added to the Alt-I Misc options configuration.
The expired access level, item #20 on the Misc options screen. This
defaults to 'z'. But is now provided so that the sysop can specify
the access level he/she desires for callers that have had their
subscription expire.
-» A new caller questionnaire has been added. Sysops may now define the
QUEST0.BBS file. New callers will be forced to fill it out, between
the bullet menu and the mail check (before they get to the main menu).
If they don't fill it out, for whatever reasons (say they drop carrier)
then they will remain "new" callers, and be forced to face the
questionnaire on their next call.
PQUEST0.BBS is _NOT_ supported. Answers are stored in the ANSWER0.BBS.
-» A batch file for virus scan of uploads is now available. GT_VSCAN.BAT
will be executed, like a door, if it exists in the GTPATH, after a
caller upload. The filenames of the uploaded files will be passed
to the GT_VSCAN.BAT in a log file called GT_RECV.LOG. The format of
this log file is quite simple: (a) full pathnames are used, (b) a
single filename per line, (c) entries begin in column 1.
GT will not automatically erase or create the GT_RECV.LOG. To get
things started, the sysop must create an empty GT_RECV.LOG, the
following DOS command works nicely:
rem >GT_RECV.LOG
If the GT_RECV.LOG is created, GT will append the uploaded filenames
to it after each upload. After the GT_VSCAN.BAT runs, GT does not
automatically erase the GT_RECV.LOG, so the sysop must clear the
file after the scan is done. Again, this DOS command works well:
rem >GT_RECV.LOG
Remember to create the GT_RECV.LOG in the GT log path (which may or may
not be the same as the GTPATH).
In order to scan the upload files after the caller logs off, the sysop
should not create the GT_VSCAN.BAT, instead the virus scan logic should
be placed in the GTLOGOFF.BAT. Remember to clear the GT_RECV.LOG after
the scan is done... using this method, the virus scan can be delayed
and done on a periodic basis (for example, during daily or weekly
maintenance). The GT_RECV.LOG will run until the sysop manually resets
it, and full pathnames are recorded.
IMPORTANT: GT does not automatically create the GT_RECV.LOG. The
sysop must create it to start with, using the "rem"
command, as shown above. If the sysop forgets to do this
GT *WILL NOT* record anything in the GT_RECV.LOG.
-» Questionnaires are now programmable. The following features are
currently supported:
a. If statement.
b. Goto command.
c. Dump caller command.
d. Access level change command.
e. Access level test command.
f. Set expiration date.
g. Display a "More?" prompt.
h. Loop command.
i. Answer labels.
j. Line labels.
k. Date/time stamp.
l. Join caller to a message base.
m. Test for blank answer.
n. Test for ASCII answer.
o. Force save of questionnaire answers.
p. Terminate questionnaire and discard answers.
IF - The "IF" statement allows the sysop to test the previous entry
made by the caller. The entry can be treated as a number or
a string of characters (if a string of characters, only the
first character can be tested). Here is the syntax:
[%IF,N,1-18=MINOR]
The first 5 characters, "[%IF," is constant. The 'N' indicates
that the test will be numeric. The range 1 through 18 is
tested against the caller input, if found to be true, the
questionnaire will branch to the label "MINOR".
[%IF,X,Y=SYSOP]
Again, the first 5 characters are constant. The 'X' indicates
that the test will be made on a alphanumeric basis (i.e. as if
the entry was a string of characters). The caller input is
tested to see if the first character entered was a 'Y', if true
the questionnaire will branch to the label "SYSOP".
Ranges can also be used with "[%IF,X,". Like this:
[%IF,X,A-Z=GOOD_ANS]
If the caller entry was in the range A through Z, then the test
evaluates true and the branch is done.
The 'X' option can test multi-character answers. The first test
value is the key to the number of characters that will be tested.
For example:
[%IF,X,YES=NEXT]
In this case, the first 3 characters of the previous answer will
be tested for equal to "YES". If the caller gave a longer answer,
the extra will be ignored. If a match is made, the questionnaire
will branch to the specified label, "NEXT".
If the "IF" statement finds the test condition false, then the
questionnaire will fall-through to the next line of the
questionnaire.
GO - The "GO" command allows the sysop to branch un-conditionally
to the indicated label. For example:
[%GO,ADULT]
Again, the first 5 characters are constant, "[%GO,". When
found in the questionnaire, this causes an un-conditional
branch to the label ADULT.
XX - The "XX" command causes the caller to be disconnected from
your BBS. An example:
[%XX,reason]
The "reason" is logged to the GT.LOG file, then the caller
is disconnected. If done during a new caller questionnaire,
the caller will be unable to get to your main menu.
XD - The "XD" command allows the sysop to adjust the expiration
date of the caller. An example:
[%XD,nnn]
Where the 'nnn' is the number of days from today that the
program should set the expiration date. If 'nnn' was 365
then the expiration date would be 1 year from today.
TL - The "TL" command allows the sysop to test the callers current
access level. For example:
[%TL,E=LV_NORM]
If the callers access level is equal to 'E', execution of the
questionnaire will branch to 'LV_NORM'.
A range of values may be tested... as follows:
[%TL,A-E=LV_USERS]
Which would execute the branch to LV_USERS, if the caller's
access level is in the range A through E.
MO - The "MO" command will cause a "More? " to appear for the caller.
For example:
[%MO]
JN - This command join the caller to a message base. For example:
[%JN,c:\gtbbs\netsys]
Would join the caller to the Network Sysop's Confernce, assuming
it was in "c:\gt\netsys" on your system <GRIN>.
TB - Test last answer for blanks. For example:
[%TB,BLANKS]
If the answer last given was all blank (or empty), the question-
naire will branch execution to 'BLANKS'.
TA - Test last answer for ASCII data. For example:
[%TA,MOR_TEST]
If the answer last given was all ASCII characters (32-125 decimal),
the questionnaire will branch to 'MOR_TEST'.
SV - Force the questionnaire to be saved. For example:
[%SV]
The command should be placed near the beginning of the
questionnaire, to insure it is "in effect", before the
caller decides to drop carrier <GRIN>. Once it has taken
effect, the questionnaire WILL be saved, unless the computer
crashes.
AB - In an ordinary questionnaire, other than quest0, the [%AB
command causes the questionnaire to terminate immediately,
returning the caller to the main menu... and discarding the
answers given to the questionnaire. It will not, however,
cause a QUEST0.BBS to be discarded. For example:
[%AB]
LV - The "LV" command allows the sysop to adjust the access level
of the caller. An example:
[%LV,x]
Where the 'x' is any valid access level. And the first five
character are constant.
LP - The "LP" command allows the previous question to be re-asked.
This is very handy for cases where the caller response appears
incorrect. For example:
:ASK_SYS
[---]
Are you a sysop?
[%IF,X,Y=IS_SYS]
[%IF,X,N=NOT_SYS]
[%LP,3,ASK_SYS]
In this example, the responses 'Y' and 'N' are tested, if found
to be true, the "IF" statements will branch out to the indicated
labels. If the "IF" statements fall-through, the "LP" statement
will execute twice (asking the question a total of '3' times).
ASK_SYS is a line label (because it begins with a ':' in column 1).
Line labels must be no longer than 8 characters.
DT - Date/Time stamp the answers given. For example:
[%DT]
Answer Labels
-------------
One of the biggest problems that I've seen with questionnaires in the
past, has been that there has been no way to easily identify the
answers, without some way to cross-reference with the questionnaire.
Answer labels can be added to the questionnaire by making an addition
to the prompt line. Take the sample question above:
[---]
Are you a sysop?
As it stands, the answer will be saved without any label. To add a
label the following change must be made:
[---]
Are you a sysop? [%SYSOP]
This sort of label is not to be confused with line labels (line labels
should be on a line by themselves). However, answer labels are limited
to 8 characters, like line labels.
In the ANSWERx.BBS file, the label would look like this:
AGE : 12
SYSOP : no
BBS_PHON: 602-897-9549
VOICE_PH: 602-897-9557
Line Labels
-----------
A line label is used by the new branching commands, so that points
that control needs to be transferred to, can be identified. A line
label begins in column 1 with a ':' and the name chosen must be 8
characters or less.
Here is an example script (that I wrote to test the new features):
The [%DT] adds a date/time stamp to the answers.
Start of Sample Questionnaire
-----------------------------
[%DT]
NEW USER QUESTIONNAIRE
:ASK_AGE
[---]
How old are you? [%AGE]
[%IF,N,1-18=MINOR]
[%IF,N,19-100=ADULT]
Really! That is too old!
[%LP,3,ASK_AGE]
[%GO,DUMP]
:ADULT
You are an adult.
[%GO,ASK_SYS]
:MINOR
Hey! You are a minor.
:ASK_SYS
[---]
Are you a sysop? [%SYSOP]
[%IF,X,Y=SYSOP]
[%IF,X,N=REGULAR]
[%LP,3,ASK_SYS]
:DUMP
Sorry. You gotta go...
[%XX,DUMB BELL SYNDROME]
[%GO,FINAL]
:REGULAR
You aren't a sysop.
[%GO,FINAL]
:SYSOP
Hey! You are a sysop!
[%LV,A]
:FINAL
the end
---------------------------
End of Sample Questionnaire
-» New DOS Environment variable: GTVBUF
The user may set the size of GT's VROOM buffer with this
environment variable. The buffer defaults to 100k. If the
buffer is too small, GT will run extremely slowly, and probably
beat your disk to death. Minimum value 30, maximum value 160.
For example:
set GTVBUF=128
This would set the VROOM buffer to 128k.
The GTVBUF variable should be set so that between 150 and 200k are
available when GT starts. If available memory is too low, then
GTVBUF can be reduced, if available memory is too high, then GTVBUF
should be increased. However, values above 160 have very little
merit.
-» New DOS Environment variable: NO_EMS
The user without EMS memory (or who is having trouble with EMS
memory) can use this variable to disable GT's usage of EMS. The
default is to use EMS memory.
For example:
set NO_EMS=TRUE
This would disable the usage of EMS memory by GT.
If your system has no EMS memory, then this variable can be used
to speed up program loading (since GT will not bother checking for
EMS memory).
-» New script commands.
STATUS CLEAR
Purpose: to clear the status line.
STATUS RESET
Purpose: to return the status line to the original condition.
STATUS nn "...."
Purpose: to write a string of data at column 'nn' of the
status line.
Example:
status 5 "F1=Menu Option"
Modified script command.
CAPTURE ON
Purpose: to turn on capture mode.
CAPTURE OFF filename
Purpose: to turn off capture mode and store the text
in "filename".
-» The /V command line option is now obsolete. All external processes
executed during host mode operation will be overlay the memory
occupied by GT.
-» The overlay switch in the external protocol table is now obsolete.
All protocols will overlay the memory occupied by GT, unless they
are executed from a script (in which case, GT will remain in memory).
-» The programs DOOR.EXE and TDOOR.EXE are now obsolete. The program
structure has been rearranged into a small GT1706.EXE and the main
body of the program, GT1706.OVL.
-» The program is now able to use up to 512k of EMS memory, if it is
available.
-» A new parameter is now passed to door batch files: %3 = the baud rate.
If the door requires some other parameter to be passed, such as user
input or message base info, then the baud rate will be overridden by
such required information.
Normally, doors should not require both the baud rate and the other
information (the baud rate is useful, so that doors can do file
transfers with external protocols).
Regards,
Paul Meiners
6-28-92
