Hi Mark, 1/2

About "LSPPPDlr 2003" of December 13:

...an image is worth a thousand words...

What versions of {COMMO}, Telix and RLFossil are those, please?
My thoughts have been to gather everything together for others...

Everything? Would that be the information relative to the programs
or the archives themselves?... 8^) It turns out that i was thinking my `LSPPPDlr 2003' UpDate is over-due for a switch to the 2004 edition so i
began working on new dedicated pages as you were posting this morning...

I've gathered the addresses on which i intend to base my pages; in
its present state, its the old 2003 page plus a few more links somewhere
in a crude listing AT THE END. It might help, you can visit this ~URL~:

http://public.sogetel.net/bicephale/eng/2k4updat.htm

The external dialer now handles two types of Packet-Drivers: ~PPP~
DialUp (`EPPPD.EXE'/`LSPPP.EXE') and ~NIC~ (`RTSPkt.COM' in my case). I
also wrote a Batch-File to simplify the installation so i decided to put
it to good use, the next step probably would be to .ZIP it all together.

I have {COMMO} v7.7 but i note that it has a 30 day trial period and
that there is a COMMO.ID file for registered users... How bad does
it get if it is not registered? Have mr. Brucker's people released
a free key and/or are they continuing on with {COMMO}'s development?

There's no such lock in v7.7! As i must have wrote, in `DOS-INet',
my understanding was that the author got a thought for the blind when he removed the "Nag Screen" in his release of December 1998 - right in time
for ChristMass... The people he left behind after he died didn't appear
to "care" about his work when i learned about his death via the official {COMMO} mail-list (on YahooGroups), we were lucky to be informed at all.

As for `Telix', i'm refering to version 3.51...

I have a floppy here of Telix 3.22 from deltacomm... a quick search
for "14" thru the v3.22 docs i have turns this up...

Problem: We have our modems on a network and we need a network
version of Telix in order to access them. Does Telix have network
support built in?

Solution: ...we have developed a version of Telix which uses the
Int-14 calls, and it is now available as a separate product.

It would appear that they incorporated this functionality in a later version... Now i've gotta hunt that one down...

I wonder what might have been possible if only the `Windows' frenzy
had occured a few years later. What if innovation could have followed a
more inclusive path?! Sniff! 8,-( An affordable solution, these days,
could be Dial BackUp routers if one is no AOL customer or he never sends
FAX documents (AOL's SoftWare must access the MoDem, similarily to a FAX application); but imagine if MoDem Servers had been developped when DOS
was still strong and kicking! Hummm... Sorry, i dream out loud... ;-)

Well, to me it was like most ~BIOS INT-14~ drivers crawl at 9K6 bps
when i tried one. Your reference to a MoDem pool reminds me of emerging alternatives which the average BBSers hardly ever heard of, euh... like
~NCSI~ (NetWork Communications Services Interface) which was copyrighted
by the NPC company but it was used with Novell's `LAN WorkPlace for DOS' SoftWare: its interrupt was 0x6B, standard signals (~Xon~/~Xoff~, ~DTR~
and ~RTS~) were supported and the speed limit reached 115K2 bps instead.

But maybe HardWare performance has more inlfuence than i suspected!

I must confess that the matter of local connection speed (~DTE~,
isn't it?) sure sounds somewhat "elusive"... ...the "unknown"
result returned by `MS-Kermit' was said to make perfect sense...

...it is all too easy to tell the FOSSIL using software what speed
the FOSSIL is running at so that transfer calculations may be
performed... my RemoteAccess BBS knows the FOSSIL driver is locked
at a set speed (115200) but it still uses a/the connection speed...

Hummm... Wouldn't it be possible that `Kermit' doesn't depend on a
number defined by the ~FOSSIL~ driver to compute the cps transfer speed?

...from what i've read from you and others, i can easily see why it
doesn't from the butt-type attitudes of kermit's developer(s)...

Well, "The Team", as i called them, sure reacted poorly when i went
to their NewsGroup with a macro-file which i actually used for this very
same reading/posting activity, to be honest... I'd need to dig up if it
were crutial for me to know what their position was exactly but only Joe Doupnik would be worth it, anyway (he was slightly less agressive). %-)

I confirm `MS-Kermit' replies "unknown" but i'm unable to tell why.

When a user logs off, my system fires up telix... ...and runs a
script to fetch the session's stats from the modem...

BBSes depend on a fully compliant level 5 ~FOSSIL~ driver which can
support application swapping... ...i wish `RLFossil' were compliant
enough to support the use of a `ZMoDem' protocol driver run from `MS-Kermit's terminal interface, or vice-versa!

...DSZ (and FDSZ, i believe) can be used to dial out...

Remember that `RLFossil' is no ~UART~ emulator and hence this means
only the ~FOSSIL~ flavour of `DSZ' can resume the ~TelNet~ session after `MS-Kermit' has left it in a "Hot" state, as i like to refer to it. :-)

[The present message concludes next...]
--- Maximus/2 3.01
* Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)

About "LSPPPDlr 2003" of December 13:

...an image is worth a thousand words...

What versions of {COMMO}, Telix and RLFossil are those, please?
My thoughts have been to gather everything together for others...

Everything? Would that be the information relative to
the programs or the archives themselves?... 8^)

mainly just the archives...

It turns out that i was thinking my `LSPPPDlr 2003' UpDate is
over-due for a switch to the 2004 edition so i began working
on new dedicated pages as you were posting this morning...

cool...

I've gathered the addresses on which i intend to base my
pages; in its present state, its the old 2003 page plus a few
more links somewhere in a crude listing AT THE END. It might
help, you can visit this ~URL~:

http://public.sogetel.net/bicephale/eng/2k4updat.htm

i'll try to remember that...

The external dialer now handles two types of
Packet-Drivers: ~PPP~ DialUp (`EPPPD.EXE'/`LSPPP.EXE') and
~NIC~ (`RTSPkt.COM' in my case). I also wrote a Batch-File
to simplify the installation so i decided to put it to good
use, the next step probably would be to .ZIP it all together.

excellent!

I have {COMMO} v7.7 but i note that it has a 30 day trial period and
that there is a COMMO.ID file for registered users... How bad does
it get if it is not registered? Have mr. Brucker's people released
a free key and/or are they continuing on with {COMMO}'s development?

There's no such lock in v7.7!

all i had/have to go by is the info within the commo77 archive... that and some
basic guesswork ;)

As i must have wrote, in `DOS-INet', my understanding was that
the author got a thought for the blind when he removed the "Nag
Screen" in his release of December 1998 - right in time for
ChristMass... The people he left behind after he died didn't
appear to "care" about his work when i learned about his death
via the official {COMMO} mail-list (on YahooGroups), we were
lucky to be informed at all.

i, for one, thank you for that notification...

As for `Telix', i'm refering to version 3.51...

I have a floppy here of Telix 3.22 from deltacomm... a quick search
for "14" thru the v3.22 docs i have turns this up...

Problem: We have our modems on a network and we need a network
version of Telix in order to access them. Does Telix have network
support built in?

Solution: ...we have developed a version of Telix which uses the
Int-14 calls, and it is now available as a separate product.

It would appear that they incorporated this functionality in a later
version... Now i've gotta hunt that one down...

I wonder what might have been possible if only the `Windows'
frenzy had occured a few years later. What if innovation could
have followed a more inclusive path?! Sniff! 8,-( An affordable solution, these days, could be Dial BackUp routers if one is no
AOL customer or he never sends FAX documents (AOL's SoftWare must
access the MoDem, similarily to a FAX application); but imagine
if MoDem Servers had been developped when DOS was still strong and kicking! Hummm... Sorry, i dream out loud... ;-)

n.p. on the dreaming... however, i'm not sure what you mean about the AOL stuff
must access the modem like a fax app... i've set up many AOL systems to use the
internet to get to AOL after a dialup connection is made... no changes are needed to that setup when one upgrades to some DSL or cable connection, either...

i'll also note that i'm aware of at least one person who figured out how to use
his AOL connection to access the internet without using the AOL software at all... it was a matter of determining the proper logon sequence and now he uses
that connection "clean"...

Well, to me it was like most ~BIOS INT-14~ drivers crawl
at 9K6 bps when i tried one. Your reference to a MoDem pool

that came about when users didn't want to have to put a modem in each machine... corporate users were one of the first to desire this...

reminds me of emerging alternatives which the average BBSers
hardly ever heard of, euh... like ~NCSI~ (NetWork
Communications Services Interface) which was copyrighted
by the NPC company but it was used with Novell's `LAN WorkPlace
for DOS' SoftWare: its interrupt was 0x6B, standard signals (~Xon~/~Xoff~, ~DTR~ and ~RTS~) were supported and the speed
limit reached 115K2 bps instead.

yes, i believe that that is where i first encountered a workable solution to the multiple modems problem...

But maybe HardWare performance has more inlfuence than i
suspected!

it may very well... on my internal 10mb LAN, i'm getting 9kcps with the windows
version of qmodem pro to my bbs sitting on another machine on my LAN... that other machine is running OS/2 with vmodem, RemoteAccess and the OLMS offline mail door that i'm testing for compatibility... the protocol driver in use is CEXYZ in that OLMS installation but i also have FDSZ available as well as other
protocol drivers that i may be able to use to provide X, Y, and Zmodem protocols... i went with CEXYZ so as to be able to provide zedzap (8k-zmodem) capability... not that it is important or that anyone will actually use it ;)

I must confess that the matter of local connection speed (~DTE~,
isn't it?) sure sounds somewhat "elusive"... ...the "unknown"
result returned by `MS-Kermit' was said to make perfect sense...

...it is all too easy to tell the FOSSIL using software what speed
the FOSSIL is running at so that transfer calculations may be
performed... my RemoteAccess BBS knows the FOSSIL driver is locked
at a set speed (115200) but it still uses a/the connection speed...

Hummm... Wouldn't it be possible that `Kermit' doesn't
depend on a number defined by the ~FOSSIL~ driver to compute
the cps transfer speed?

it is possible but i was thinking of the "pre" calculation that tells one how long the transfer will take... on a BBS where time may be limited, that can come in handy so that one doesn't run out of time when trying to download maill
packets...

...from what i've read from you and others, i can easily see why it
doesn't from the butt-type attitudes of kermit's developer(s)...

Well, "The Team", as i called them, sure reacted poorly
when i went to their NewsGroup with a macro-file which i
actually used for this very same reading/posting activity, to
be honest... I'd need to dig up if it were crutial for me to
know what their position was exactly but only Joe Doupnik would
be worth it, anyway (he was slightly less agressive). %-)

i hear ya there...

I confirm `MS-Kermit' replies "unknown" but i'm unable to
tell why.

me either from here...

When a user logs off, my system fires up telix... ...and runs a
script to fetch the session's stats from the modem...

BBSes depend on a fully compliant level 5 ~FOSSIL~ driver which can
support application swapping... ...i wish `RLFossil' were compliant
enough to support the use of a `ZMoDem' protocol driver run from
`MS-Kermit's terminal interface, or vice-versa!

...DSZ (and FDSZ, i believe) can be used to dial out...

Remember that `RLFossil' is no ~UART~ emulator and hence
this means only the ~FOSSIL~ flavour of `DSZ' can resume the
~TelNet~ session after `MS-Kermit' has left it in a "Hot" state,
as i like to refer to it. :-)

that is probably pretty accurate, too...

)\/(ark
* Origin: (1:3634/12)

Hi Mark, 1/2

About "LSPPPDlr 2003" in two parts of December 13:

...an image is worth a thousand words...

What versions... My thoughts have been to gather everything...

...relative to the programs or the archives themselves?... I've
gathered the addresses on which i intend to base my pages...

Mainly just the archives...

Oh! Well, when i'm ready to zip it as a single archive and to call
it, euh... `LSPPPDlr 2005', most likely, euh... i'll add that one too!

;-)

...i was thinking my `LSPPPDlr 2003' UpDate is over-due for a switch
to the 2004 edition so i began working on new dedicated pages...

Cool... I'll try to remember that...

The time has come, it's still crude but i noticed how much damage i
had to repair after my ~ISP~ made some changes a few months ago... I've
been busy clearing up a few issues before i touched `2K4UpDat' so i hope
this wasn't urgent, you only get plain-text addresses but it's readable.

The external dialer now handles two types of Packet-Drivers... I
also wrote a Batch-File to simplify the installation...

Excellent!

I have sympathy for Matt when he seems to find my setup process too complex but i must respect author rights. I might pack the Genuine .ZIP Archives with my "GlueWare"; though, the final size (read the BandWidth
due to this alternative concept) worries me: it causes another issue...

I have {COMMO} v7... How bad does it get if it is not registered?
...info within the commo77 archive... ...some basic guesswork...

It's been some time since i read the distribution files which don't display directly in `{COMMO}', i tried to read the YahooGroups mail-list yesterday (to find a precise quote about the status of `{COMMO}') but it
isn't `Lynx' friendly, to say the least, and i sort of forgot about what
i was supposed to do once `W2K' was finished loading! I might try later
and give you at least a name but it will have to wait until a next post.

> Problem: ...modems on a network... Solution: ...Int-14 calls...

An affordable solution, these days, could be Dial BackUp routers if
one is no AOL customer or he never sends FAX documents...

...i'm not sure what you mean about the AOL stuff...

Most Dial BackUp routers handle the MoDem without external help, it
means the ~PPP~ protocol is internal and hence the script as well. On a
few rare models, the MoDem is made available over EtherNet: i found two
from 3Com (3C886 & 3C888) and one from ActionTec (GEU114000-01)... From
what i read, manufacturers take pride in advertising "AOL Compatibility"
so i conclude routers like these have something the others don't... ;^)

...one... ...figured out how to use his AOL... ...without using
the AOL software... ...a matter of determining the proper logon...

I'm please to read there's more hope than i previously suspected, i certainly would be satisfied with a script solution if i depended on AOL
for my INet access (but there's little control over the ~PPP~ process if
it's supported internally, unless the FirmWare can be re-writen)! There
is another solution: Tactical's `DialOut/IP' $oftWare could control the
MoDem remotely but can `DialOut/IP' be supported by personal Dial Backup routers? I doubt it, such simpler devices seem to be relatively cheaper
to produce or there would be more models equipped with a MoDem server...

The cost of the TacticalSoftWare license might explain, at least in
part, why a MoDem attached to a Dial BackUp router is controlled locally instead of thru ~RFC-2217~... After all, the ~CPU~ is already available
and managing the ~PPP~ protocol only involves more FirmWare code. Also,
INet access would be lost should the main PC hosting ~PPP~ support fail.

I considered a purchase. One model seemed to support ~PPP~ locally
and something told me it was possible to get partial remote control: in
the form of a "HangUp" feature, activity was sufficient to "trigger" the "HangOff"/"Dial" process. Information was so scarce i "put it on hold", nonetheless - not to mention that i've read FirmWare horror stories! :(

...to me it was like most ~BIOS INT-14~ drivers crawl at 9K6 bps...
Your reference to a MoDem pool reminds me of emerging alternatives
which the average BBSers hardly ever heard of, euh... ...~NCSI~...

...that is where i first encountered a workable solution...

But you're not the average BBSer and i only got one phone line free
for the ~PPP~ connection with my ~ISP~. :) A NetWork MoDem would still
be nice though: no more quests behind the PC to find the ~RS-232~ cable
in order to connect it to another PC (twentysome to play with); no more power-down/power-up sequences just to make sure no dammage occurs in the process; no more unplanned investigations due the manipulations, etc...

I didn't use DialUp often, lately, but it's no permanent situation;
i intend to move to a new appartment and i don't know what it will be so
a Dial BackUp router made a lot of sense: DialUp & ~DSL~ are supported.

But maybe HardWare performance has more inlfuence than i suspected!

On my internal 10mb LAN, i'm getting 9kcps...

Yet it tells me how much potential there is on a 100 Mbps one! ;-)

[The present message concludes next...]
--- Maximus/2 3.01
* Origin: COMM Port OS/2 juge.com 204.89.247.1 (281) 980-9671 (1:106/2000)

But maybe HardWare performance has more inlfuence than i suspected!

On my internal 10mb LAN, i'm getting 9kcps...

Yet it tells me how much potential there is on a 100 Mbps
one! ;-)

i hear ya there! ;) i'm this || close to getting the needed items to
upgrade the major parts of my LAN to 100mb capability... the NICs will
have to come secondary and on a machine by machine basis ;)

P.S. can you tell i'm testing something? ;)

)\/(ark
* Origin: (1:3634/12)