Howdy!

 EB> What do you use as a telnet server to work with Maximus? Any help thanks.

SIO or SIO2K ..  I have licensed copies of both for what is needed here.
You might note though, that if you happen to want to run HyperAccess Pro
and HyperHost, which I also run in some cases along with the BBS operations
on OS/2, you will need to use SIO and not SIO2K for the HyperAccess Pro box
which connects via POTS phone lines to a HyperHost enabled system.  Try as
I might, I've never been able to get HAPro to deliver a fully connected
desktop on the remote machine with SIO2K.  I suspect that if I knew enough
to do a custom setup configuration file for SIO2K that might not affect it.

It seems not to make any difference if SIO or SIO2K is in use on the system
running HyperHost.  I did turn this in to the developer as well as to Gwinn
way back when.  But no 'fix' was ever furnished for this.

You might also note that if you are a VERY heavy COMM port user of an OS/2
system with all four COMM ports in use for multiple BBS use or whatever use
you need for them, as well as heavy TCP/IP operations during constant IP
connectivity with TCP/IP together with OS/2 Peer LAN server enablement on
the same box, be carefull!

On very rare instances when multiple COMM port activity is going on at the
same time as TCP/IP operations, and you do LAN server operations with other
OS/2 connected boxes at the same time as well, you can get total system
lockup wierd issues.  I've tracked this down to three different sort of
common thread pig trails in formal testing at this with the old IBM
TestCase crew and OS/2.  We traced one lockup issue to DHCP issues in
coincidence with this heavy COMM port I/O and concurrent TCP/IP use -- at
the same time OS/2 .INI file updates might hit and repeated operations wit
DOS-VDM operations.  Every time you open and close a DOS-VDM session in the
affected boxes and AUTOEXEC.BAT or its equivalent ran, you'd wind up with
an un-released file handle for the AUTOEXEC.BAT or equivalent!  Eventually,
file handle chaos.  This was fixed in the final workout with DHCP
operations that were also related to PMMERGE.DLL changes that made it into
the system offerings as of XRC04 for MCP2 and FixPack 17 for Warp4.

If you intend to use TelNet operations in a heavily burdened OS/2 box,you
really need to consider being able to move Warp4 or MCP2 to at least this
level of FixPack.  No more mess on this at these levels.

Second, if you are running very heavy COMM port use and some programs which
have totally left open files for logging since boot time, such as SIO2K's
logging file and PRIVOXY for proxy operations with its log, in rare
instances you'll hit this same lockup deadlock when OS/2 .INI file updates
have to be run, if for some reason, exact same time COMM port I/O is needed
as well as log file writes related to that .. and .. OS2 PEER lan file
transfers are started on a box which is a SERVER for where all this
happens.  This one has never been fixed to my knowledge.

Moral of this story.  Don't plan your TelNet BBS system operation with
concurrent total connection to your IP on a box which normally hosts files
as a SERVER in PEER LAN operations as well.  Without the PEER LAN server
issue I never have the box lock issues at the above FixPack levels here.

Third .. per my experience with TelNet and OS/2, together with all the rest
of this, do *NOT* routinely use Lotus Smartsuite applications on the same
box together as an AFTER BOOT well into booted run-time first use!  The
reason is that OS/2 has what are called SOM.IR files and database total
uptime operation from bootup.  Lotus Smartsuite applications are one of
those applications suites which use the SOM.IR tools for OS/2.  At least up
until the very last FixPacks for Lotus Smartsuite, for some wierd reason
the SOM.IR files were opened for WRITE access on first use of them!  If
this happens to take place well into a booted system up time, The SOM.IR
database for OS/2 gets confused and bad things can happen.  The SOM.IR
files for everything from the LOTUS applications to WATCOM, to OPENDOC, to
even the original system SOM.IR files installed during the creation of OS/2
can get corrupted.

The only way this can be fixed, as well as what winds up in FOUND0 during
cleanup reboot is to either be able to re-copy the original files into the
needed SOM.IR files from backups of the original - or re-install the
application with the grunged files.  Which in rare cases,can require a
complete re-install of OS/2 if you can't do the backup job from a floppy
diskette utilty boot run or the ALTF1 boot to a command line to service
them.

This can be compounded by the heavy COMM port and TelNet use above in my
heavy experience at debugging all this.

The 'cure' here at least for up until these last fixes for Lotus Smartsuite
was simple.  Immediately after bootup simply open Lotus 123 or Wordpro and
load a file.  Then close the file and the Lotus application.  No more
conflict with SOM.IR files and whatever.  It may be that the last FixPack
work for Lotus Smartsuite fixed this.  It all is known at Lotus.  But I've
never been willing to bet my whatever on finding this out the hard way. 
Too easy to just use the customer work around of a ghosted file open and
close to get the needed data into the SOM database kept open by the OS/2
system from boot up time.

Just trying to help.  The best server up time I'm close to is over 88,000
hours now with less than 2 hours of un-planned down time and not one byte
of data lost.  But, grin, not with TelNet running on it either,chortle!


--> Sleep well; OS/2's still awake! ;)

Mike {at} 1:117/3001

--- Maximus/2 3.01