Text 957, 95 rader
Skriven 2008-06-21 08:34:32 av Mike Luther (1:117/3001.0)
    Kommentar till text 955 av Robert Wolfe (1:261/20)
Ärende: SIO 1.60D
=================
Will someone here refresh my memory?

 RW> Well I also have Warp 4 Server for e-Business 
 RW> installed on this machine as well and as soon as I can 
 RW> find the necessary drivers to get it to have network 
 RW> connectivity under VPC 2007, I'll install SIO 1.60d 
 RW> there and see what I can come up with.  But, so far, 
 RW> at least the drivers for SIO that start up at boot 
 RW> time start up like they are supposed to.  Now to 
 RW> configure the VModem ports and see what happens :)

Even though 'registerd', doesn't SIO either 1.60 or 2K have a control mechanism
in it which blocks two systems on TelNet from talking to each other if they
have the same serial number?  Other than that multiple installations of SIO on
different machines work fine.  The only reason I bring this up is that with the
apparent lack of ability to register the product, curious connection blockage
may show up that some might not understand.

Or did Ray release a version of this that doesn't have this issue before
stepping away from the people who need this tool?

Another issue with SIO/SIO2K you might note.  Even though you do have enough
registered copies of the tool to work between systems as he planned, there can
be glitches in other communications interfaces between systems.

One I know of involves HyperAccess Pro and HyperHost operations.  I've used two
tools as fully registered products for many years now on OS/2. However, with
POTS dialup for remote OS/2 Desktop use, I've found that although you can use
SIO2K for the HyperHost end, you cannot use SIO2K for the HyperAccess Pro on
the dial-in terminal.  The connection can be made just fine.  But the remote
desktop freezes unless you use SIO 1.6 for the dialing end.  This is not true
with TCP/IP interface connections per my research.  Only POTS phone line work.

As well, I've also found that SIO2K here seems to be involved with MCP2 latest
XRC05 and all else Fix Pack systems with rare hard system lockups when multiple
comm port activity is going on, together with other intense TCP/IP operations
through simultaneuous IP activity, at the same time intense hard disk I/O is
taking place, together with a rare update of the .INI files that is triggered
somehow.  At least on MCP2 with PEERLAN used as a 'server' in this case.

After days of boot time, I may see a complete brute force power off required on
a box with compete multi-line telephone system total logging of all dial and
line control signal data, which is involved in very complex file I/O and
database work.  At this point for over 500,000 logged calls in the lines.  That
at the same time other complete TCP/IP traffic is also going on for merged
interface of the phone line and much other traffic to other remote systems.

When the system is powered down, and returns through the complete CHKDSK repair
of all the partitions, I'll see only a file allocation error size for the file
SIO2K.LOG which apparently was involved in some curious operation at the same
time as the clock gets jammed and you can see the exact time the system failed.
 If the system has an 'unclean' .INI file operation, which I always check after
this stuff with UNIMAINT, I'll see the corresponding same time on the corrupted
.INI file game too!

A further trigger for this is the .LOG file for Privoxy's proxy server,which
will also show the file allocation error size issue too when it is involved.

Stopping this usually rather rare incident is really made less rare by only
enabling Privoxy when Seamonkey use is actually made on this box. It is also
made much more rare by going in for long periods of unattended Desktop use on
the box and from an OS/2 command line prompt:

                     cache /lazy:off

That disables lazy write for OS/2.  Which can be restored with /lazy:on as
desired.  However if I do that I really need to stop and restart the intense
COMM port program as well to, I think, avoid problems once I go in an set the
cache lazy write back on.

I have not ever seen this with Warp 4 FP17, all latest Fix Packs boxes. As well
all the boxes have been serviced with the absolutely required DHCP fixes that
we found out are required that IBM released, even post FP17 and XRC04 for MCP2
boxes.  The issue here is that every time a DHCP lease renewal is required,
somehow the DOS-VDM AUTOEXEC.BAT file in the system is never 'closed' when it
is touched!  And you run out of file handles as you'll have handle after handle
all still 'open' for AUTOEXEC.BAT if you look at all this with Theseus 4, where
you can see the evidence of it!  This is just another lockup vector.

It would seem valuable to those anticpating working with SIO or SIO2K on
multple systems on on those which could touch each other via VMODEM,thus, to
know if there is a version of SIO that Ray released without the multiple same
serial blockage.  Before the 'same' copy of this might be downloaded all over
whatever and then produced non-connect issues. Which as far as I remember don't
produce any 'error' notation you can see from my work with them.

Thoughts?


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

Mike @ 1:117/3001

--- Maximus/2 3.01
 * Origin: Ziplog Public Port (1:117/3001)