Hi Winston,

     About "MS-Kermit Transfers" of May 5 and "Kerm_RLF.INI
File" of May
7:

WS> To All You MS-KERMIT People...
MS> ...address me directly!  Oh, while i'm thinking of it...  ...have
MS> you finally obtained cps figures using a ~RAMDisk~...
WS> ...the drive spins when the file WATTCP.CFG is read...  A load from
WS> a RAMDisk into memory should be silent, so I am investigating...

     At an early stage, when i first discovered this fine hobby, i began
to put my `{Commo}' macro programming skills to real use by testing some
external dialer concept of mine which was intended for the packet-driver
from FTP SoftWare.  According to its absolute minimum requirements, 8088
4.77 Mhz PCs were insufficient and, indeed, just failed - until i loaded
`PC/TCP' from a ~RAMDisk~, that is!  A ~RAMDisk~ can make the difference
under extreme circumstances, using one proved to be a major breakthrough
in this particular case:  low processing resources combined with `PC-XT'
class Hard-Disk mechanical factors introduced delays which prevented the
`PC/TCP' packet-driver from completing its preliminary ~PPP~ negociation
phase in time, a ~RAMDisk~ effectively removed the extraneous factors...

     As i was reminded lately, after i switched to another ~ISP~, delays
due to mechanical factors can be excessive but so might the user's work-
load if a given ~ISP~ is too quick at canceling connection.  My new INet
access happens to be based on a mixed pool of ~PPP~ servers, among which
a number of them won't leave room for delays.  My P-200 Mhz machine will
let me use external dynamic dialer macros such as mine but i suspect the
extra work-load may very well cause my connection to abort should i dare
test 8088 HardWare with this ~ISP~.  It's quite possible a ~RAMDisk~ may
save the day again, if experiencing difficulties;  chances are i'll need
to use one or i'll end up with a dead-end (dummy) interactive validation
phase followed by disconnection, disconnection alone or even the Ascend/
Lucent `Pipeline' Terminal interface where the "ppp" command is one more
dead-end (the NetWork Administrator insisted "~PPP~ over Terminal" isn't
supported, that only ~PAP~/~CHAP~ validation is, that i must start ~PPP~
negociation without waiting for the ~ISP~'s ~ASCII~ #125d characters and
even less the menu).  Oh, and he'd like me to upgrade, i.e. abandon this
Legacy hobby of mine, because of his very specific validation scheme!...

     Anyway.  %-)  Yes, i can testify that there are instances where the
~RAMDisk~ helps but the result isn't garanteed (one has to give it a try
first).  In your situation, i'd install my COMMAND INTERPRETER, my .CFG,
.INI, .EXE and other MAIN FILES on ~RAMDisk~ to limit Hard-Disk noise...

                                  ;-)

     A ~RAMDisk~ which i often used is `SRDisk v2.08', by Marko Kohtala:

          ftp://ftp.simtel.net/pub/simtelnet/msdos/ramdisk/srdsk208.zip

     This 76 Kb archive includes a variety of drivers, one of them makes
a great ~RAMDisk~ for shoe-string memory budgets since it's redefinable,
the content doesn't necessarily have to be lost and its drive-letter can
be found from a DOS environment variable.  It beats `RAMDrive' any time!

                                  B-)

WS> ...file transfer using the WildCat! KERMIT...  I have set the file
WS> TYPE to...  Am I forgetting anything?  ARCE will still not unarc...
MS> ...3rd-party implementations as that found in all `WildCat!'
MS> packages are crippled...  You already got an extensive example...
MS> ...you could UpLoad a known binary archive and DownLoad it using
MS> `Kermit' in order to compare the two.  The different content might
MS> very well prove to be informative...  ...you refer to options which
MS> i don't recognize...  ...i'd rather wait to see the full listing...
WS> Here is my Kerm_RLF.INI file...

     Then you're using `MS-Kermit' with the March 16 options i gave you.

WS> Am I right to assume that I should change the 1K and 3K packet...

     I fail to see how this would affect translation.  Less efficient or
perhaps down-controling (?) ~ISP~s may force you to lower these sizes to
something like 256 and 1024 bytes respectively (Sogetel certainly does).

     Unless you'd be testing a custom `Kermit' configuration where Craig
has selected text transfers instead of binary i can't but confess that i
am puzzled.  I guess i'll go see for myself what it does, eventually!...

                                  ;^)

WS> Thanks for the tip!

     Don't thank me yet:  the packet-size you get with `WC-Kermit' isn't
going to be negotiated to a higher value!  8,-(  That's the reason why i
tried to convince Craig Healy that the internal `Kermit' protocol should
be discarded and replaced by `MS-Kermit v3.15 Medium' run as an external
protocol driver.  I wasn't convincing enough, he removed the `MS-Kermit'
option before i had a chance to make him prove its real value.  Too bad!

     Sysops are like that, Robert Couture opened the door to `MS-Kermit'
then never showed up again (it was right before the April fool's day)...

                                         Salutations,

                                         Michel Samson
                                         a/s Bicephale
                                         http://www.iquebec.com/dos-inet
                                         (UserName="U" and
PassWord="P")


... DOS+TCP/IP+TelNet+ZMoDem/Kermit+.QWK technologies on 8088s or higher
--- MultiMail/XT v0.42 - Who wants to make TelNet OLMR BBSing UNIVERSAL?