Subj : Telnet
To : Erich B.
From : Mike Luther
Date : Thu Oct 04 2007 10:51 pm
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 @ 1:117/3001
--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)
