root@raider.raidernet.com (Bob Reineri) (09/02/90)
Every once in a while, an adb script floats by in comp.unix.xenix that patches
SCO's version of uucico to record transfer rates correctly. Something about a
HZ value being hardcoded as 20, when it should be 50.
Well, I'm now using SCO Unix 3.2.0, and it appears the same problem happens on
this system, too. I'm getting silly transfer rates of 50 cps on a 2400 baud
line (at least that's what the log says, which can't possibly be correct).
So, I dug up the old adb script I had used on my xenix system, and thought I'd
see if it worked on this Unix version. I started up adb, but the responses I
was getting to my commands looked nothing like the fix script, so I figgered
that I better not fool with it. Apparently it has been recompiled or something
because none of the addresses are correct any more.
Anyone know of a patch for the new uucico to fix this ? Any of you unix
programmers out there game to figuring one out ? I know just enough about adb
to be dangerous :-) (or, do I even need to patch it ??, ie, another fix ?)
Here's the old script I had laying around, just for reference....
----------------------- cut here ----------------------
As distributed with my version of SCO Xenix 2.3.1 for 386AT's, the new HDB
uucico records incorrect transfer times in
/usr/spool/uucp/.Admin/xferstats. This is because the version I got
was hard coded for a HZ=20 clockrate machine (i.e. an XT!) Since both
the AT286's and AT386's run at HZ=50, uucico needs to be patched to
record reasonable time in xferstats. (If this has already been
posted, then hit 'n'...)
Also, my version has a symbol table, for other patches (like
windows=7, might as well do that while your in there...)
Run "adb -w" on uucico (in /usr/lib/uucp, you will need to be root)
Here is a script:
----- start of script ----
$ date
Sun Oct 30 09:03:56 PST 1988
$ copy -om uucico uucico~
$ adb -w uucico
* windows/x
_windows: 0x3
* windows/w 7
_windows: 0x3= 0x7
* $x
* millitick+32?ia
_millitick+0x32: mov ax,0x14
_millitick+0x35:
* .?x
_millitick+0x32: 0x14b8
* .?w 32b8
_millitick+0x32: 0x14b8= 0x32b8
* .?ia
_millitick+0x32: mov ax,0x32
_millitick+0x35:
* $q
$
---- end of script ----
If you're wondering, the mov ax,0x14 is setting up a divide by 20 for
HZ=20 machines. The 0x32 changes it to 50 for HZ=50 machines..
The patch to windows is the famous WINDOWS=7 patch that helps over
lines with big delays (eg PC-Pursuit).
Erik Murrey
MPX Data Systems, Inc.
erik@mpx2.UUCP
...!{bpa,spl1,cbmvax,vu-vlsi}!mpx1!erik
-------------------------- cut here ----------------------------
Any help appreciated !
Bob
P.S. The 'windows' part of the patch seemed to work just fine....
--
* RaiderNet Public Access *Middle Tenn's Unix Gateway* Murfreesboro, TN *
* Data:(615)896-8716 896-7905 Voice:(615)849-4390 Mail:PO Box 2371 Zip 37133 *
* Domain: root@raider.RAIDERNET.COM UUCP: uunet!mjbtn!raider!root HAM: AB4SU *
* Shell Accounts, Mail/USENET UUCP Links Available -- Send Mail for Details *