Howdy!
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)