home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 2 BBS
/
02-BBS.zip
/
zpars106.zip
/
zparse.FAQ
< prev
next >
Wrap
Text File
|
1996-03-03
|
9KB
|
290 lines
────────────────────────────────────────────────────────────────────────────────
JC> I was unable to test the password file function as I don't
JC> know the syntax for the password file (got errors with my
JC> password.txt copied over from xlaxnode).
passwords are set using the set verb for overriding infomation gathered from the
nodelist. There is no password file per say. The passwords are set in the config
file. My preference is to keep them together in a seperate file that is
included.
set <4d-node address>,[password],[phone],[speed],[new flags]
the address is required, all the other fields are optional. The commas are
required.
or
password <4d-address> <password>
this second form does not allow spaces to be included.
────────────────────────────────────────────────────────────────────────────────
JC> Second, your modemtrans doesn't include ZYX for ZyXEL
JC> modems.
I don't have a ZyXel, also the modemtrans doesn't 'include' any flags at all.
If the flag is present in the nodelist, the corresponding bit patterns are
is set in the modem byte.
The syntax is quite different from XLAX. It was designed to work with the newer
Binkleys that match the modemtrans statement to the modembyte exactly. Thus you
can define upto 8 modem characteristics, each representing 1 bit position. For a
total of 256 (2^8) different modemtrans possible.
I have a USR dualie, thus as the config file shows, I'm interested in the
HST,H14,H16,V32,V32b flags. My dualie only does V32, thus I wish to seperate out
HST/V32 from HST/V32b.
For the ZYX flag, pick a bit pattern. say 0 for ZyXel modems ie:
ZYX 0123 ; ZYX implies ZYX, V32, V32b, V42b
For the ZyXel you would only need to worry about 3 charactistics of modems.
ZYX,V32b(V32),V42b(V42,MNP).
The modemtrans in binkley could have values for 0..7 representing the 8
possibly values of 3 bits.
────────────────────────────────────────────────────────────────────────────────
>I haven't done too much more than that for a few reasons. One is that it is
>a busy time here. Second one is that I compared the NODEX.DAT and NDX files
>produced by ZPARSE and the same produced by FASTLSTP - turned out different
>(zparse makes 'em smaller).
The indexes are packed to remove dead space. If you want to see huge index
files, try running xxxxx (~700K & 980K ;). Also note ZParse uses a longest
pattern match function with the phone numbers, not a first match as others
do.
────────────────────────────────────────────────────────────────────────────────
> How do I insert a new node number (9999 until I put him in
> the nodelist). I tried adding it to ZPARSE.PTS:
>
>
> _ _ _ O / _ _ C_U_T_ H_E_R_E_ _ _ _
> O \
> ; point file consists of the keyword boss followed by a 3d-address
> ; the boss address is used to specify the hub node to add to.
> ,9999,bbs,city,sysop,phone,9600,CM,V32b,H16
>
> _ _ _ O / _ _ C_U_T_ H_E_R_E_ _ _ _
> O \
> I inserted the keyword ALLOWNODES in ZPARSE.CFG. Obviously,
> I have done something wrong since the noe did not appear
> when I recompiled (Happily the compile is so swift!!).
Points and nodes MUST be preceeded by a boss statement.
The boss (or hub) statement tells the compiler where to add the node into
the nodelist.
> Also, I have to add s9=120s10=240,,, to one of my nodes'
> number.
The set verb uses commas as field delimiters, use the phone verb. It will
include all characters except spaces into the phone number.
"phone" <4d-addr> <full-dial string>
────────────────────────────────────────────────────────────────────────────────
>As per your request for comments, here goes. :-)
>
>If you're familiar with XLAXNODE configs, have a look at the following extract
>from my XLAXNODE.CTL file:
>
> ModemTrans 1 Z19
> ModemTrans 1 UZ19
> ModemTrans 1 V32
> ModemTrans 1 V32b
> ModemTrans 1 <2400 !V42b
> ModemTrans 1 <2400 !V42
> ModemTrans 1 <2400 !MNP
> ModemTrans 2 ZYX !Z19 !UZ19
> ModemTrans 2 Z16 !Z19 !UZ19
> ModemTrans 2 V32
> ModemTrans 2 V32b
> ModemTrans 2 <2400 !MNP !V42 !V42b
> ModemTrans 3 HST !V32 !V32b
> ModemTrans 3 H16 !V32 !V32b
> ModemTrans 3 TPEP !V32 !V32b
> ModemTrans 3 <2400
>
>Is it possible to do something like this with ZParse? What I'm doing here
>is creating a sequential thing rather than a bit-based thing. The idea is:
>
> 1 - ZyXEL 19200
> 2 - ZyXEL 16800
> 3 - V.32/V.32bis
> 4 - 2400bps w/ V.42bis (incl HST & TPEP)
> 5 - 2400bps w/o V.42bis
How about a good approximation.
modem Z19 0123
modem UZ19 0123
modem Z16 012
modem UZ16 012
; v.32
modem V32 1
modem V32b 1
; v.42 + mnp
modem V42 0
modem V42b 0
modem MNP 0
modem HST 0
modem H14 0
modem H16 0
modem TPEP 0
what this gives you is 6 modem types
8 4 2 1
z19 . . . . ; these two lock in modem types
z16 . . .
v32 . ; these two denote characteristics 2^2 = 4 types
mnp . ;
modemtrans 0 ; default no bits set, no HST, v32, v42 thus 2400 w/o MNP
modemtrans 1 ; MNP/V42/V42b
modemtrans 2 ; V32/V32b
modemtrans 3 ; V32/V32b + MNP/V42/V42b
modemtrans 7 ; Z16
modemtrans 15 ; Z19
Becuase of the way the z19, z16 flags lock in all the lower bits while setting
the upper bit(s), the available combinations are greatly reduced.
────────────────────────────────────────────────────────────────────────────────
> Can I ask you a question on how to setup Zparse to work with
> the ModemTrans in BinkleyTerm 2.59b and Nodelist version 7?
> All I like to know is how to setup Zparse so that
> BinkleyTerm sees a HST modem flag and will dial in HST
> mode..
One problem, there is no HST modem flag in Binkley. With the latest version all
hard coding of modem types has been removed. (it's a free for all)
What you need to do is decide on what characteristics of the modems you dial
are needed.
You have a Dual w/V32t ie (HST etc.. , V32b , v32t)
Using 2 bits == 2^2 different modem types == 4 translations.
ie 00 default
01 bit 0 only
10 bit 1 only
11 both bits
>----------
Zparse.cfg:
modem 0 HST ; HST in the flags sets bit 0
modem 0 H14
modem 0 H16
modem 1 V32 ; V32/V32bis sets bit 1
modem 1 V32b
modem 1 ZYX
>----------
Binkley.cfg:
modemtrans 0 atb0 ; default no bits set.
modemtrans 1 atb1 ; bit 0 set
modemtrans 2 atb0 ; bit 1 set
modemtrans 3 atb0 ; bits 0 and 1 set
I think I'm going to have to add a section to the docs about all this. If any
of this is unclear, please tell me where/how I need to explain it better. Since
I wrote it, I don't think about how it works anymore.
────────────────────────────────────────────────────────────────────────────────
Changes in BinkleyTerm 2.51 from 2.50
-------------------------------------
[...]
HEY!!! READ THIS!! IT MIGHT BREAK YOUR CURRENT CONFIGURATION!!
Bink now matches modem types exactly rather than using a bitwise
AND. This allows lots more modem types, but requires that you
change your nodelist generation and config stuff (if you're using
ModemTrans).
[...]
────────────────────────────────────────────────────────────────────────────────
Zparse makes the version7 index files smaller than program XXXXX. It can't be
working right, can it?
Zparse takes the time to pack the index nodes thus removing extraneous empty
space while keeping the BTree balanced. It adds a bit to the run time but is
(in my opinion) well worth the extra effort.
────────────────────────────────────────────────────────────────────────────────
I changed the syntax of the modem verb to allow for absolute modem types
as well as bit fields.
ie Given both of your modems are similiar ;)
;
; USR v.everything
; note the hash mark
; the order is important as the first entry listed, takes precedence!
modem #V34 1
modem #VFC 2
modem #UVFC 2
modem #V32T 2
modem #UV32T 2
modem #H16 3
modem #V32b 2
modem #H14 3
modem #HST 3
modem #V32 2
modem #V42 4
modem #V42B 4
modem #MNP 4
; this would result in 5 different modem types
; 0 - no flags
; 1 - v.34
; 2 - v.fc,v.32t,v.32b,v.32
; 3 - HST
; 4 - v.42,v.42b,MNP
────────────────────────────────────────────────────────────────────────────────
People wanted the more familiar password verb for passwords so
Password <4d ftn address> <password string>
ie
Password 1:340/302.0 testing
────────────────────────────────────────────────────────────────────────────────