Xref: utzoo comp.sys.att:7519 unix-pc.general:3702 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!noao!arizona!naucse!jdc From: jdc@naucse.UUCP (John Campbell) Newsgroups: comp.sys.att,unix-pc.general Subject: Re: Step rate change (WD2010) Some Benchmarks(was Re: WD2010 / No ECC) Summary: Help, I'm confused... Message-ID: <1695@naucse.UUCP> Date: 8 Sep 89 13:30:39 GMT References: <1624@mtunb.ATT.COM> <1182@mitisft.Convergent.COM> <594@uncle.UUCP> <2903@cbnewsc.ATT.COM> Organization: Northern Arizona University, Flagstaff, AZ Lines: 80 From article <2903@cbnewsc.ATT.COM:, by psfales@cbnewsc.ATT.COM (Peter Fales): : Thanks to the combined efforts of a number of net folks, I : finally succeeded in getting my WD2010 to accept the faster step rate. : : The hypothesis that step rate is only set in the ROM code and then : never touched unless there is a disk error seems to be correct. I : was able to get my disk to use a step rate of 14 (3.2 microseconds) : which showed a significant improvement over the default rate of 0 (35 : microseconds) according to Lenny's exerciser. ... : -- : Peter Fales AT&T, Room 5B-420 : 2000 N. Naperville Rd. : UUCP: ...att!peter.fales Naperville, IL 60566 : Domain: peter.fales@att.com work: (312) 979-8031 Uh, I'm coming in a little late and a lot stupid, but didn't earlier articles say all that was necessary was a reboot? I would love to know more since I put in my WD2010, changed (with iv) the step rate to 14, rebooted and nada--no significant disk speed change. What is a "RESTORE"? How does the controller work? Peter's article was a tad thin for me to trust hacking a driver in order to force a condition I don't understand yet. (By the way, I only have 5 bad blocks on my 67 Mb disk. Am I a candidate for few retries and hardly ever a restore?) Any help appreciated, right now I'm leaving my step rate at 14 and just hoping/waiting for a magical RESTORE to occur on it's own... From vn Fri Sep 8 06:15:41 1989 Subject: Re: RE: patch utility Newsgroups: comp.os.vms References: <2946@quanta.eng.ohio-state.edu> From article <2946@quanta.eng.ohio-state.edu:, by DAVISM@kcgl1.eng.ohio-state.edu (Michael T. Davis): : : In article <8908301323.AA09921@crdgw1.ge.com>, : SESSIONS%SPAREV.decnet@CRDGW1.GE.COM writes: : :>>Subj: Wanted: Patch utility for VMS :>>From: rochester!uhura.cc.rochester.edu!rbr4@pt.cs.cmu.edu (Roland Roberts) :>>Message-Id: <2903@ur-cc.UUCP> :>> :>>I'm looking for a "patch" utility for VMS that operates as the one on :>>Unix systems does. This would make my job of updating some of the GNU :>>software we keep a lot easier. Thanks for any info! :>> :>>roland :> :>I can just Jerry cringing at the bits after reading this one! :-) :> :>Roland, you must not have done your homework on this one, and exhibits :>what many on the network would consider as a waste of network bandwidth. :>A patch utility comes with VMS. It is used by vms to patch itself when :>the system manager runs vms upgrades. Find out more about it with :> :>$ help patch : : But this is NOT a UN*X-compatible patch utility. UN*X patch allows : the updating of SOURCE files; VMS PATCH -- and this is from VMS HELP -- is : for patching "...an executable image, shareable image, or device driver : image." (Note the use of the term "image".) : : Although not UN*X patch, a similar functionality may be found with : the use of DIFFERENCES/SLP (somewhat analogous to UN*X diff) and EDIT/SLP : (similarly analogous to UN*X patch). As far as I know, there is no UN*X- : compatible patch utility. I would be interested in knowing if one exists, : though. : Um, I ported Larry Wall's patch program to VMS. Also had to build a working pd diff program that could be used with it. I have both and can either post or mail to individuals depending upon interest... -- John Campbell ...!arizona!naucse!jdc CAMPBELL@NAUVAX.bitnet unix? Sure send me a dozen, all different colors.