1 INFO-VAX	Mon, 23 Oct 2000	Volume 2000 : Issue 592       Contents:! $ show printer => %cli-f-syntax ?  Re: Converting NT Alpha to VMS& Re: Extending LATNET over dial-up line! Re: Great service from Camintonn! ! Re: Great service from Camintonn!  Re: Handling oddball disks Re: Handling oddball disks Re: Handling oddball disks Re: Handling oddball disks Re: Handling oddball disks Re: Handling oddball disks Re: Handling oddball disks Re: OpenVMS in Oil companies Re: PDF under OpenVMS " Re: Stockholm Exchange OM and VMS? Re: User Guide for Vax (VMS) Re: User Guide for Vax (VMS) vile 9.2 - announcement   F ----------------------------------------------------------------------  % Date: Sun, 22 Oct 2000 13:20:12 -0700 5 From: "cstranslations" <cstranslations@email.msn.com> * Subject: $ show printer => %cli-f-syntax ?) Message-ID: <uq0UaWGPAHA.254@cpmsnbbsa07>   E I connecting a LA70 to a Alphastation 200 4/233 running OpenVMS 7.2-1 G (sys$print is defined, LRA0 seems to be the relavent device). I've down L loaded and applied the pcsi and vms721_update-v0100 ecos (not that either of# those are connected to my problem).   H I am getting output. It looks like fine. However - I am trying to adjustJ some of the printer settings - width (since a LA70 is limitted to 8.5x11),* truncate, and ff being the important ones.  J $ show printer lra0: (with or with out) any qualifiers seems to result in:' %CLI-F-SYNTAX, error parsing 'IDSTRING' : -CLI-E-ENTNF, specified entity not found in command tables  I $ set printer lra0: (with or with out) any qualifiers seems to result in: $ %CLI-F-SYNTAX, error parsing 'RESET': -CLI-E-ENTNF, specified entiry not found in command tables  I In the middle of a show device/full on lra0 I get a "status" message with 9 the hex value of 0078B5BD. According to f$message this is & %SHOW-I-NOMSG, message number 0078B5DB' which doesn't tell me much of anything.   L There has been a set printer command in every sysstartup_vms.com for as longI as I can remember (even it it is commented out by deault) so I'm thinking @ I'm doing something wrong or this has been seen. The pthread fixE incorporated into the v0100 ECO hasn't fixed the bnu/netscape/pthread G problem so the documentation CDs are mostly unusable (including the I/O L Users Manual). So - before I dig the 5.0 I/O users manual out of the back ofH the closet and essentially write my own "show printer" and "set printer"G commands is there anyone that has any ideas what might be "wrong" here.    Joe    ------------------------------  % Date: Sun, 22 Oct 2000 12:03:05 -0600 $ From: Lee Y T Mah <lytmah@cha.ab.ca>' Subject: Re: Converting NT Alpha to VMS ) Message-ID: <39F32BD9.52945F84@cha.ab.ca>   < Here is my experience at converting an AS400 from NT to VMS.; I am not familiar with the machine you are working with, so ; I can only give you the benefit of the fun I had converting > mine through trial and error, as I had no manual to work with.  ; This machine has the typical connections for a keyboard and 6 mouse.  In addition, there is a connection for the VGA= monitor(DB15 female), and two TTA DB9 female ports.  I hooked > up a PC monitor to the VGA port and after playing with the dip< switches and numerous boots finally got the monitor to go toH monochrome console prompt.  I installed console firmware 5.7 off the CD.  I set the environment variables:     set os vms     set boot_osflags 0,0 I then installed VMS 7.2-1. > You may also want to "set bootdef_dev" and other set commands.: However, the PC monitor was not satisfactory as a console,; and if a keyboard and mouse was not connected, bootup would 	 complain. ' I decided to take a different approach. 9 Required: VT420 terminal, DB9/MMJ adapter, MMJ/MMJ cable. C At the console prompt, I entered "set console serial", powered down E the machine, and removed all connections.  Then I plugged the adapter G into the right TTA port on the back of the AS400, connected the machine = and VT420 with the MMJ/MMJ cable, and powered up the machine. > The AS400 booted up cleanly.  The only difference was that theC formerly right TTA port became the OPA0 console port for the AS400.      BrianNFO wrote:   Q > I have an Alpha 4100 server currently running NT that I plan to convert to VMS. O >  I was wondering if anyone could point me to any documentation on this topic. O > I've been through a number of VMS installs over the years, but didn't know if Q > there were any required steps given this NT to VMS transition.  (I assume there  > are.)  > 	 > Thanks.  >  > Brian    -- Lee    Lee Y T Mah  Email:  lytmah@cha.ab.ca   ------------------------------  # Date: Mon, 23 Oct 2000 03:20:51 GMT 7 From: moroney@world.std.spaamtrap.com (Michael Moroney) / Subject: Re: Extending LATNET over dial-up line & Message-ID: <G2v5Aw.8wu@world.std.com>  O >> I know how LANs work.  I did, after all, write a VMS LAN device driver once.   D >Amazing. IMO, you have a very confused/confusing paradigm about howB >these things work and/or inter-relate. I suppose it may just be aH >"failure to communicate", though. I've misread meanings before (not the) >first time, probably won't be the last).   H I am by far not the best communicator, but I thought my posts were clear enough.   I >> Don't have to.  I know what to look for in SDA as well as knowing what . >> DECnet does if it can't change the address.  A >Then you've probably seen what happens when you start LAT before ' >DECnet-IV (even as late OpenVMS V7.2).   E You mean setting its address to the DECnet address before DECnet ever H starts?  Old versions of VMS (pre-5.5 I think) did this with SCS and LATE because the "can change address" feature wasn't created until 5.5 (or J whenever).  I think it was optional on LAT.  I checked a V7.2-1 system and it does not do this.   -Mike    ------------------------------  % Date: Sun, 22 Oct 2000 12:55:16 -0500 % From: Keith Brown <kbrown780@isd.net> * Subject: Re: Great service from Camintonn!' Message-ID: <39F32A04.A2295DD9@isd.net>    Bart Zorn wrote: > ! > I thougth I would let you know:  > L > I have a DECserver 700 at home. It needs a 1- or 4 MB simm module, but the* > one that I had fails (most of the time). > L > So I needed a 4 MB memory module. These used to be normal a few years ago,J > but nowadays the kids who work in the computer stores won't even believe! > that those things ever existed.  > K > I was at the trade show of the CETS2000 conference. I decided to find out  > what I could find out there. > L > I asked the guys at the Digital Networking Products Group, who, after all,N > still sell the DECserver. They leafed through their catalog and yes, I couldH > order a memory module. Costs a couple of hundred bucks (yuck!). I said< > thanks, but no thanks. A bit too much for my home systems. > J > With CPUoptions, I got a business card of the person who might know more > about DECserver memory.  > I > Then I went to Camintonn, a company with a long tradition of delivering N > memory modules for a lot of different Digital/Compaq systems. I explained myH > problem to Anna Wilkinson. She said that there must be some modules atJ > stock. If I came back the next day, she could sell me one for $ 15. ThatL > sounded good! However, the next day the message was even better. Anna toldF > me she didn't have the module, but that she would arrange to have itN > Fedex'ed to my hotel the next day, FREE of charge! The next day I received a3 > package containing not one, but two 4 MB modules!  > ' > Now my DECserver 700 runs fine again.  > J > Thank you very much for this really friendly service, Anna Wilkinson and > Camintonn! > 
 > Regards, >  > Bart Zorn   G I happen to run 4GB of Camintonn memory in an ES40 that we installed at G work about 6 months ago. No problems and half the cost of Compaq memory  :) --   Keith Brown  kbrown780@isd.net    ------------------------------  # Date: Sun, 22 Oct 2000 21:08:10 GMT  From: Dirk Munk <munk@home.nl>* Subject: Re: Great service from Camintonn!' Message-ID: <39F35739.3D6015C3@home.nl>    Keith Brown wrote: >  > Bart Zorn wrote: > > # > > I thougth I would let you know:  > > N > > I have a DECserver 700 at home. It needs a 1- or 4 MB simm module, but the, > > one that I had fails (most of the time). > > N > > So I needed a 4 MB memory module. These used to be normal a few years ago,L > > but nowadays the kids who work in the computer stores won't even believe# > > that those things ever existed.  > > M > > I was at the trade show of the CETS2000 conference. I decided to find out   > > what I could find out there. > > N > > I asked the guys at the Digital Networking Products Group, who, after all,P > > still sell the DECserver. They leafed through their catalog and yes, I couldJ > > order a memory module. Costs a couple of hundred bucks (yuck!). I said> > > thanks, but no thanks. A bit too much for my home systems. > > L > > With CPUoptions, I got a business card of the person who might know more > > about DECserver memory.  > > K > > Then I went to Camintonn, a company with a long tradition of delivering P > > memory modules for a lot of different Digital/Compaq systems. I explained myJ > > problem to Anna Wilkinson. She said that there must be some modules atL > > stock. If I came back the next day, she could sell me one for $ 15. ThatN > > sounded good! However, the next day the message was even better. Anna toldH > > me she didn't have the module, but that she would arrange to have itP > > Fedex'ed to my hotel the next day, FREE of charge! The next day I received a5 > > package containing not one, but two 4 MB modules!  > > ) > > Now my DECserver 700 runs fine again.  > > L > > Thank you very much for this really friendly service, Anna Wilkinson and > > Camintonn! > >  > > Regards, > > 
 > > Bart Zorn  > I > I happen to run 4GB of Camintonn memory in an ES40 that we installed at I > work about 6 months ago. No problems and half the cost of Compaq memory   H In our case 1/3 of the cost of Compaq memory (1 GB DIMM's). The chips on& the DIMM's are made by IBM, so ......    > :) > --
 > Keith Brown  > kbrown780@isd.net    ------------------------------  # Date: Sun, 22 Oct 2000 19:42:20 GMT ( From: Terry Kennedy <terry@gate.tmk.com># Subject: Re: Handling oddball disks ' Message-ID: <G2uK2K.2K0@spcuna.spc.edu>   7 David J. Dachtera <djesys.nospam@earthlink.net> writes: A > Which I guess begs the question: can DKDRIVER (or some suitable I > substitute) be made to work such that if the target device doesn't meet I > the (a,b,c,...,x,y,z) criteria, it will use some generally operable but = > (much!) less than optimal "lowest common denominator" mode?   G   The problem is that the devices often "lie" about their capabilities. J So you either need to trust the information you get back (which you can't)J or you need to build a table of devices (and optional revs) that are known& to have non-compliant implementations.  F   In retrospect, I'd have added SYSGEN parameters that told the driverE that some connected disks didn't do TCQ, Sync mode, and/or disconnect > properly and to not use those features on the specified disks.  G > When we are pitting OpenVMS against the opposition, these SCSI issues 9 > are frequently our weakest "Achilles's(sp? usg?) Heel".   G   However, my overall experience has been better than Glenn's (but he's G seen many more disks than I have). I use Seagate disks exclusively, and G I have rarely had problems, either on VMS or on more demanding environ-  ments.  F   There are some exceptions, however. The first is the TZ30, which is I itself a non-compliant device. Don't get me started on TZ30 firmware bugs , - I was involved with the TZ30/RQZX1 fiasco.  E   The next is a problem with jukebox devices - VMS doesn't understand F that the different LUNs are connected to the same SCSI target and thatG busy status on one is likely to generate a command reject on the other. E I suspect this is because the traditional DEC jukebox device actually = has a separate tape drive and robot (for example, the TL891).   G   Other than that, most problems fall into a) devices with busted firm- G ware, or b) DEC trying to protect their market by placing arbitrary re- E strictions of only working with known DEC drives on their controllers D (the aformentioned RQZX1, and the KZQSA come to mind). But that's a ) marketing stupidity, not a technical one.   4         Terry Kennedy             http://www.tmk.com5         terry@tmk.com             Jersey City, NJ USA    ------------------------------  % Date: Sun, 22 Oct 2000 16:53:16 -0500 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net> # Subject: Re: Handling oddball disks - Message-ID: <39F361CC.D674A6DB@earthlink.net>    Terry Kennedy wrote: > 9 > David J. Dachtera <djesys.nospam@earthlink.net> writes: C > > Which I guess begs the question: can DKDRIVER (or some suitable K > > substitute) be made to work such that if the target device doesn't meet K > > the (a,b,c,...,x,y,z) criteria, it will use some generally operable but ? > > (much!) less than optimal "lowest common denominator" mode?  > I >   The problem is that the devices often "lie" about their capabilities. L > So you either need to trust the information you get back (which you can't)L > or you need to build a table of devices (and optional revs) that are known( > to have non-compliant implementations.  , Does the term "fallback" mean anything here?  H That is, if ddcu: says it supports (k,r,x) but doesn't act like it does,G or logs errors on the attempt, fall back to (lowest common denominator) @ mode. If it still logs errors, then (MntVerify) with profuse andG profusely verbose ERRLOG entries about what failed, what the driver did B to attempt to compensate, and the subsequent errors leading to the MntVerify condition.   I > > When we are pitting OpenVMS against the opposition, these SCSI issues ; > > are frequently our weakest "Achilles's(sp? usg?) Heel".  > I >   However, my overall experience has been better than Glenn's (but he's I > seen many more disks than I have). I use Seagate disks exclusively, and I > I have rarely had problems, either on VMS or on more demanding environ-  > ments.  E Can you list some of the more VMS-compatible Seagate drives and their H formatted/unformatted capacities? If someone could do that, I could makeD an effort to compile hobbyist data on how to use them MicroVAXes, in- small ALphas, in StorageWorks canisters, etc.    G >   There are some exceptions, however. The first is the TZ30, which is K > itself a non-compliant device. Don't get me started on TZ30 firmware bugs . > - I was involved with the TZ30/RQZX1 fiasco.  C I have a TZ30 in a MicroVAX 3100. Don't use it much, but so far, no & trouble. What lurks below the surface?   G >   The next is a problem with jukebox devices - VMS doesn't understand H > that the different LUNs are connected to the same SCSI target and thatI > busy status on one is likely to generate a command reject on the other.   D Well, on a former site, OpenVMS-Alpha V6.2-1H3 and V7.1-2 did a veryD good job with StorageTek's 9710 jukebox. The robot was id. 0 and the drives were 1 thru 6.   G > I suspect this is because the traditional DEC jukebox device actually ? > has a separate tape drive and robot (for example, the TL891).   G Dunno. The craziest I ever got with that was to try and connect a TZ877 ? to a VAXstation 4000/VLC. Needless to say, that was a lesson in 	 futility.    I >   Other than that, most problems fall into a) devices with busted firm- I > ware, or b) DEC trying to protect their market by placing arbitrary re- G > strictions of only working with known DEC drives on their controllers E > (the aformentioned RQZX1, and the KZQSA come to mind). But that's a + > marketing stupidity, not a technical one.   D Sounds like you and Glenn are/were involved with OVMS engineering at some point.   H Can either of you list the criteria (those portions of the SCSI "spec.")F to which DKDRIVER/MKDRIVER expect strict adherence, and how to inquire7 of a vendor whether their device(s) meet such criteria?    --   David J. Dachtera  dba DJE Systems  http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/   F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.r   ------------------------------  # Date: Sun, 22 Oct 2000 23:42:17 GMTd( From: Terry Kennedy <terry@gate.tmk.com># Subject: Re: Handling oddball disksg' Message-ID: <G2uv6H.FoK@spcuna.spc.edu>s  7 David J. Dachtera <djesys.nospam@earthlink.net> writes: J >>   The problem is that the devices often "lie" about their capabilities.M >> So you either need to trust the information you get back (which you can't)-M >> or you need to build a table of devices (and optional revs) that are known ) >> to have non-compliant implementations.i >". > Does the term "fallback" mean anything here?  I   Sure. But what's the fallback when a device says "yes, I support tagged G command queueing" and you give it 63 write requests, and then it eithersH says "I lied - can you give me those again?" or it says "Yup, 63 writes,H all committed - but to other random places on the disk"? Those happen to! be very common problems with TCQ.   G   Regarding sync mode, one popular CD-ROM drive in the "old days" wouldtJ say "yup, I speak sync" and then if you asked it to do something, it wouldL sit and lock the bus until it was power cycled. Bus and target resets didn't do anything.  J > That is, if ddcu: says it supports (k,r,x) but doesn't act like it does,I > or logs errors on the attempt, fall back to (lowest common denominator)0B > mode. If it still logs errors, then (MntVerify) with profuse andI > profusely verbose ERRLOG entries about what failed, what the driver didmD > to attempt to compensate, and the subsequent errors leading to the > MntVerify condition.     See above.  J >> > When we are pitting OpenVMS against the opposition, these SCSI issues< >> > are frequently our weakest "Achilles's(sp? usg?) Heel". >> pJ >>   However, my overall experience has been better than Glenn's (but he'sJ >> seen many more disks than I have). I use Seagate disks exclusively, andJ >> I have rarely had problems, either on VMS or on more demanding environ-	 >> ments.x >tG > Can you list some of the more VMS-compatible Seagate drives and theirsJ > formatted/unformatted capacities? If someone could do that, I could makeF > an effort to compile hobbyist data on how to use them MicroVAXes, in/ > small ALphas, in StorageWorks canisters, etc.n  D   I've never had one that I've been unhappy with, starting with the D ST31200N on VAXstation 3100's and currently using current-generationF Seagate drives on DS10's. Note that many recent DEC/Compaq drives have, been Seagate drives with re-badged firmware.  C   I can't say "Seagate drive X works on all VMS boxes", because thenH capabilities of the VMS boxes have changed - for example, the VAXstationH 3100's (at least the older ones) didn't do sync mode. Plus, I don't wantF anyone trying it and blaming me for data corruption problems. The bestB anyone can say is that drive X works on system Y in environment Z.  H >>   There are some exceptions, however. The first is the TZ30, which isL >> itself a non-compliant device. Don't get me started on TZ30 firmware bugs/ >> - I was involved with the TZ30/RQZX1 fiasco.  >oE > I have a TZ30 in a MicroVAX 3100. Don't use it much, but so far, no ( > trouble. What lurks below the surface?  J   That's the environment it was designed for, so it should be fine. But itJ was definitely designed to fit in a specific product space, rather than asH a general SCSI peripheral. That's understandable if you consider that itJ was the follow-on to the TK50Z, which was itself originally intended as anJ add-on for the VS2000/MV2000, which didn't even admit that it *had* a SCSI bus.  G   A number of people have tried the TZ30 with generic host adapters andc@ have usually found that it is either invisible or hangs the bus.  L   For starters, it has a blank manufacturer field. Its sync mode negotiation* is weird. And it goes downhill from there.  H >>   The next is a problem with jukebox devices - VMS doesn't understandI >> that the different LUNs are connected to the same SCSI target and that J >> busy status on one is likely to generate a command reject on the other. > F > Well, on a former site, OpenVMS-Alpha V6.2-1H3 and V7.1-2 did a veryF > good job with StorageTek's 9710 jukebox. The robot was id. 0 and the > drives were 1 thru 6.r  I   Well, that's the kind I said would work. The types you'll have problems G with are where the drive and robot are integrated, at different LUNs on:G the same SCSI id. For example, where the drive is MKA600 and the loader 7 is JKA601 (at the console level) or GKA601 (under VMS).   H >> I suspect this is because the traditional DEC jukebox device actually@ >> has a separate tape drive and robot (for example, the TL891). >aI > Dunno. The craziest I ever got with that was to try and connect a TZ877 A > to a VAXstation 4000/VLC. Needless to say, that was a lesson ino > futility.e     What happened?  J >>   Other than that, most problems fall into a) devices with busted firm-J >> ware, or b) DEC trying to protect their market by placing arbitrary re-H >> strictions of only working with known DEC drives on their controllersF >> (the aformentioned RQZX1, and the KZQSA come to mind). But that's a, >> marketing stupidity, not a technical one. >oF > Sounds like you and Glenn are/were involved with OVMS engineering at
 > some point.e  F   I believe Glenn was. I was an end-user who helped out on a number ofF products, almost all of which were in the PDP-11 space (for example, IH did the English translations in the RQZX1 as well as re-thinking some ofF the firmware logic, though I didn't do the code itself). Note that theH RQZX1 is a combo MSCP/TMSCP controller, so all the "SCSI-ness" is hidden inside the controller firmware.0  J > Can either of you list the criteria (those portions of the SCSI "spec.")H > to which DKDRIVER/MKDRIVER expect strict adherence, and how to inquire9 > of a vendor whether their device(s) meet such criteria?   G   Glenn could relate additional specific instances of non-conformity if  he's so inclined.s  F   The "SCSI spec" is actually a group of standards (for the differing G versions, as well as being split into more manageable parts in the mostpG recent implementation). It's a large book, and you need to compare what F it says to what vendors have implemented. This requires getting a copyH of the appropriate manuals from the drive vendor. And of course the ven-G dor may not know (or may not admit) that they aren't compliant with theh standard in some areas.a  E   There has been a lot of good work on the VMS SCSI drivers in recentdE years. As long as a drive correctly implements the standard, does nothG have missing features, and (sometimes) has its mode page or options setw& a particular way, it should work fine.  F   In the case of the jukebox-on-same-ID problem I described, the driveG firmware (the generic firmware) definitely has a problem - in the prev-eD ious firmware, I could get the drive to lock up (the front panel LEDG display would spontaneously change language and the drive would lock upeH needing a power cycle to get it back). Even if the VMS drivers are doingG something funny (and in this case, I'm pretty sure they are), the drivehG should not do this. Given that the drive goes "off into the weeds" likecI this, it's of questionable benefit to do anything in the VMS driver untilBF the drive's vendor gets their act together, firmware-wise. At least, aH working set of drive firmware would return a reasonable error message toE the driver, saying "you said X and I don't like it", which would makeoH fixing the problem a lot easier - right now, it would be like saying "so: what did I say that upset you?" and not getting an answer.  F   By the way, the 2 DS10's I have both have genuine Compaq devices - 24 9GB LVD drives in each, and a DLT8000 on one of 'em.  J   Screwed-up drive firmware is _not_ just a VMS problem. I did SCSI driverI development for BSDI's BSD/OS, and I can *assure* you that we saw lots ofuI problems there. In fact, BSD/OS defaults to TCQ off because broken driveseJ outnumber working ones. And I can tell you horror stories about host adap-J ter firmware as well (which is why I like the NCR/Symbios/LSI Logic ones -/ you get to write your own controller firmware).o     The BSD/OS 4.1 manual:< http://www.bsdi.com/products/internet/release-notes/rn41.pdf has this to say about TCQ:   "Tagged queueing  D In BSD/OS 4.1, it is possible to read and write large files at full C disk-transfer speed through the SCSI subsystem. The tagged queueingfB feature of SCSI 2 is utilized to achieve this. The firmware in theB drive to implement tagged queueing is difficult and it is unfortu-D nately not uncommon to find it broken. To make matters worse, drivesC with incorrect firmware will typically appear to operate correctly, A but will silently read and write incorrect data. For this reason  + tagged queueing is not enabled by default. n  E There is no way to determine if the tagged queueing feature in a par-iD ticular drive's firmware is flawed or not, other than by running it F and seeing if data corruption occurs. This test is not something that F should be done on a system with live data, as it is possible that all C data on the system could be lost! In most cases, upgraded firmware  E for the drive will fix the problems. If you are unsure as to the cor- C rectness of the firmware in the drives you are using, contact your   drive vendor."  H   SCSI is maturing, though - with the consolidation in the industry com-G bined with customers using mostly IDE drives on PC-class systems, we'rerI seeing a much better grade of SCSI implementations, overall. Part of this H is that nobody wants to rewrite drive firmware from scratch for new pro-H ducts - they're re-using proven firmware on newer devices (with features added).   4         Terry Kennedy             http://www.tmk.com5         terry@tmk.com             Jersey City, NJ USA    ------------------------------  % Date: Sun, 22 Oct 2000 21:29:15 -0500-, From: "Glenn C. Everhart" <Everhart@GCE.com># Subject: Re: Handling oddball diskse' Message-ID: <39F35C2B.5D25F5ED@GCE.com>H  < Probably it is possible to automate handling putting in such= patches if they are necessary. I did not because I wanted the ? procedure used only by those who are clueful and know what they : are doing...and how to recover if they screw something up.  < Supporting a driver that does its utmost to get things right? automatically is tough enough. Supporting one where people haveo& been fiddling by hand is much harder.   < If you know what you are doing, my post gives some info that< will let you try a few more options before having to give up> on a device. It is NOT a cure all. There are just WAY too many8 ways devices that claim SCSI compliance can act weirdly,; screw up bigtime, hang the bus, or other paralogisms. Seemst< to me that requiring some binary editing by hand will select= for those who will know enough to put the unmodified dkdriverr= back if the edits fail. Automating it could make it tough fori< a support person to know what strange things might have been8 done. You can use such patches to break dkdriver even on  a good disk if you are careless.  7 I've seen how tough support issues can get. I would notu- automate this. I think it is unwise to do so.l Glenn Everhart   David J. Dachtera wrote: >  > "Glenn C. Everhart" wrote: > > K > > I have been getting some oddball SCSI disk brands now and then and havel > > found thatG > > they worked erratically. Concluding that this was likely due to theR > > drive not doing K > > tagged queueing right, I tried using scsi_mode to set offset 03 of pagef > > 0a to 1rC > > to disable it. Woe is me. My 3000-300LX box doesn't seem to runi > > scsi_mode correctlyd > > (for whatever reaason).p > >hG > > So I decided it made more sense to arrange that dkdriver should note > > attempt toL > > do tagged queueing on "generic" disks (i.e., the pc junk I was trying to	 > > use).  > >b: > > This might be of wider interest so here goes with how. > [snip] >  > Hi, Glenn, > 5 > Is this something that can be entirely "automated"?o > H > That is, will VFE accept image data in a .COM proc., and will the sameB > set of editor commands work for any variation of (SYS$)DKDRIVER? > F > It would be nice if hobbyists could implement this without having toI > muck about too much in the bowels of the driver just to enable use of a1+ > broader range of "non-certified" devices.e > G > Alternatively, could you modify various versions of DKDRIVER and make 6 > them available for download (quietly, if necessary)? >  > Recommendation:t > G > OVMS Engineering should consider quietly adding this feature to theiro" > driver code and not tell anyone. > J > This might help quiet the critics who claim that "ClosedVMS" is so lame,H > it can't even handle third-party disks without complaining. Might evenE > help get the OpenVMS "foot" a little farther into the door on those / > sites that hate everything else about Compaq.b >  > -- > David J. Dachteray > dba DJE Systemsr > http://www.djesys.com/ > < > Unofficial Affordable OpenVMS Home Page and Message Board:! > http://www.djesys.com/vms/soho/n > H > This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings > is to be expected. > B > Feel free to exercise your rights of free speech and expression. > H > However, attacks against individual posters, or groups of posters, are > strongly discouraged.e   ------------------------------  % Date: Sun, 22 Oct 2000 21:37:27 -0500 , From: "Glenn C. Everhart" <Everhart@GCE.com># Subject: Re: Handling oddball diskse' Message-ID: <39F35E17.1C661C22@GCE.com>   < The number of ways scsi devices can mishandle the SCSI specs9 boggles the mind. I would not dream of trying to say whatg> DKdriver relies on. It relies on the whole bloody spec. If for; example some device doesn't handle IDENTIFY messages right,e= mishandles SDTR or WDTR, maybe doesn't interpret LUNs at all,r@ dkdriver is likely to be interfered with. DKdriver makes valiant= attempts to work anyway if something it can use a default for 9 doesn't work, but there are way too many SNAFUs out thered# (and too many FUBARs) to enumerate.m  = Vendors tend not to know their own screwups. Firmware writerss< are sometimes clueless. I recall a major scsi adaptor vendor? tech director complaining to me about drive firmware that couldnC never have operations timed out. Seems the firmware writers figured C out that they should handle cylinder proximity in doing operations,A> but never heard of fairness counts. As a result heavy activity9 on one cylinder could delay operations on other cylindersb- forever. Timeouts of minutes were not enough!e  @ Think about the foregoing and realize dkdriver does BLOODY well.   David J. Dachtera wrote: >  > Terry Kennedy wrote: > >e; > > David J. Dachtera <djesys.nospam@earthlink.net> writes:dE > > > Which I guess begs the question: can DKDRIVER (or some suitablewM > > > substitute) be made to work such that if the target device doesn't meetdM > > > the (a,b,c,...,x,y,z) criteria, it will use some generally operable butrA > > > (much!) less than optimal "lowest common denominator" mode?w > > K > >   The problem is that the devices often "lie" about their capabilities. N > > So you either need to trust the information you get back (which you can't)N > > or you need to build a table of devices (and optional revs) that are known* > > to have non-compliant implementations. > . > Does the term "fallback" mean anything here? > J > That is, if ddcu: says it supports (k,r,x) but doesn't act like it does,I > or logs errors on the attempt, fall back to (lowest common denominator)iB > mode. If it still logs errors, then (MntVerify) with profuse andI > profusely verbose ERRLOG entries about what failed, what the driver didKD > to attempt to compensate, and the subsequent errors leading to the > MntVerify condition. > K > > > When we are pitting OpenVMS against the opposition, these SCSI issueso= > > > are frequently our weakest "Achilles's(sp? usg?) Heel".: > >pK > >   However, my overall experience has been better than Glenn's (but he's K > > seen many more disks than I have). I use Seagate disks exclusively, andgK > > I have rarely had problems, either on VMS or on more demanding environ-t
 > > ments. > G > Can you list some of the more VMS-compatible Seagate drives and their J > formatted/unformatted capacities? If someone could do that, I could makeF > an effort to compile hobbyist data on how to use them MicroVAXes, in/ > small ALphas, in StorageWorks canisters, etc.e > I > >   There are some exceptions, however. The first is the TZ30, which istM > > itself a non-compliant device. Don't get me started on TZ30 firmware bugs 0 > > - I was involved with the TZ30/RQZX1 fiasco. > E > I have a TZ30 in a MicroVAX 3100. Don't use it much, but so far, noi( > trouble. What lurks below the surface? > I > >   The next is a problem with jukebox devices - VMS doesn't understandsJ > > that the different LUNs are connected to the same SCSI target and thatK > > busy status on one is likely to generate a command reject on the other.y > F > Well, on a former site, OpenVMS-Alpha V6.2-1H3 and V7.1-2 did a veryF > good job with StorageTek's 9710 jukebox. The robot was id. 0 and the > drives were 1 thru 6.  > I > > I suspect this is because the traditional DEC jukebox device actuallytA > > has a separate tape drive and robot (for example, the TL891).  > I > Dunno. The craziest I ever got with that was to try and connect a TZ877iA > to a VAXstation 4000/VLC. Needless to say, that was a lesson ino > futility., > K > >   Other than that, most problems fall into a) devices with busted firm- K > > ware, or b) DEC trying to protect their market by placing arbitrary re-aI > > strictions of only working with known DEC drives on their controllerseG > > (the aformentioned RQZX1, and the KZQSA come to mind). But that's a - > > marketing stupidity, not a technical one.t > F > Sounds like you and Glenn are/were involved with OVMS engineering at
 > some point.H > J > Can either of you list the criteria (those portions of the SCSI "spec.")H > to which DKDRIVER/MKDRIVER expect strict adherence, and how to inquire9 > of a vendor whether their device(s) meet such criteria?n >  > -- > David J. Dachterao > dba DJE Systemsm > http://www.djesys.com/ > < > Unofficial Affordable OpenVMS Home Page and Message Board:! > http://www.djesys.com/vms/soho/e > H > This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings > is to be expected. > B > Feel free to exercise your rights of free speech and expression. > H > However, attacks against individual posters, or groups of posters, are > strongly discouraged.    ------------------------------  % Date: Sun, 22 Oct 2000 21:43:32 -0500i, From: "Glenn C. Everhart" <Everhart@GCE.com># Subject: Re: Handling oddball diskse' Message-ID: <39F35F84.185886B3@GCE.com>   < As for the LUN problem mentioned in David's post, I will add> that different LUNs on a SCSI ID are supposed to be completelyA independent devices, and if a busy on one lun of an ID interferese< with another lun of that ID, the device is FLAT OUT NOT SCSI CONFORMANT.a  ; Many of these exist, because decoding LUNs is expensive and>= "PCs don't need it". Tape drives and CD drives with this kindr: of broken firmware are abundant. If it bothers you disable? autoconfig and configure the ID manually. sysman io set excludes! is the way to disable autoconfig.e  = Some of the guesses about SCSI bus arbitration here are wrong ? and should be omitted from the discussion. Study the SCSI spec, = and realize it is not a 10 minute activity. There are lots ofa& little twisty passages, all different.   Terry Kennedy wrote: > 9 > David J. Dachtera <djesys.nospam@earthlink.net> writes:dL > >>   The problem is that the devices often "lie" about their capabilities.O > >> So you either need to trust the information you get back (which you can't)eO > >> or you need to build a table of devices (and optional revs) that are knownt+ > >> to have non-compliant implementations.e > >t0 > > Does the term "fallback" mean anything here? > K >   Sure. But what's the fallback when a device says "yes, I support taggedtI > command queueing" and you give it 63 write requests, and then it eitherbJ > says "I lied - can you give me those again?" or it says "Yup, 63 writes,J > all committed - but to other random places on the disk"? Those happen to# > be very common problems with TCQ.. > I >   Regarding sync mode, one popular CD-ROM drive in the "old days" wouldnL > say "yup, I speak sync" and then if you asked it to do something, it wouldN > sit and lock the bus until it was power cycled. Bus and target resets didn't > do anything. > L > > That is, if ddcu: says it supports (k,r,x) but doesn't act like it does,K > > or logs errors on the attempt, fall back to (lowest common denominator)yD > > mode. If it still logs errors, then (MntVerify) with profuse andK > > profusely verbose ERRLOG entries about what failed, what the driver did F > > to attempt to compensate, and the subsequent errors leading to the > > MntVerify condition. >  >   See above. > L > >> > When we are pitting OpenVMS against the opposition, these SCSI issues> > >> > are frequently our weakest "Achilles's(sp? usg?) Heel". > >>L > >>   However, my overall experience has been better than Glenn's (but he'sL > >> seen many more disks than I have). I use Seagate disks exclusively, andL > >> I have rarely had problems, either on VMS or on more demanding environ- > >> ments.n > > I > > Can you list some of the more VMS-compatible Seagate drives and theirnL > > formatted/unformatted capacities? If someone could do that, I could makeH > > an effort to compile hobbyist data on how to use them MicroVAXes, in1 > > small ALphas, in StorageWorks canisters, etc.c > E >   I've never had one that I've been unhappy with, starting with thetF > ST31200N on VAXstation 3100's and currently using current-generationH > Seagate drives on DS10's. Note that many recent DEC/Compaq drives have. > been Seagate drives with re-badged firmware. > E >   I can't say "Seagate drive X works on all VMS boxes", because the J > capabilities of the VMS boxes have changed - for example, the VAXstationJ > 3100's (at least the older ones) didn't do sync mode. Plus, I don't wantH > anyone trying it and blaming me for data corruption problems. The bestD > anyone can say is that drive X works on system Y in environment Z. > J > >>   There are some exceptions, however. The first is the TZ30, which isN > >> itself a non-compliant device. Don't get me started on TZ30 firmware bugs1 > >> - I was involved with the TZ30/RQZX1 fiasco.t > >rG > > I have a TZ30 in a MicroVAX 3100. Don't use it much, but so far, nol* > > trouble. What lurks below the surface? > L >   That's the environment it was designed for, so it should be fine. But itL > was definitely designed to fit in a specific product space, rather than asJ > a general SCSI peripheral. That's understandable if you consider that itL > was the follow-on to the TK50Z, which was itself originally intended as anL > add-on for the VS2000/MV2000, which didn't even admit that it *had* a SCSI > bus. > I >   A number of people have tried the TZ30 with generic host adapters andkB > have usually found that it is either invisible or hangs the bus. > N >   For starters, it has a blank manufacturer field. Its sync mode negotiation, > is weird. And it goes downhill from there. > J > >>   The next is a problem with jukebox devices - VMS doesn't understandK > >> that the different LUNs are connected to the same SCSI target and thateL > >> busy status on one is likely to generate a command reject on the other. > >eH > > Well, on a former site, OpenVMS-Alpha V6.2-1H3 and V7.1-2 did a veryH > > good job with StorageTek's 9710 jukebox. The robot was id. 0 and the > > drives were 1 thru 6.  > K >   Well, that's the kind I said would work. The types you'll have problemshI > with are where the drive and robot are integrated, at different LUNs oneI > the same SCSI id. For example, where the drive is MKA600 and the loaderS9 > is JKA601 (at the console level) or GKA601 (under VMS).e > J > >> I suspect this is because the traditional DEC jukebox device actuallyB > >> has a separate tape drive and robot (for example, the TL891). > > K > > Dunno. The craziest I ever got with that was to try and connect a TZ877yC > > to a VAXstation 4000/VLC. Needless to say, that was a lesson in)
 > > futility./ >  >   What happened? > L > >>   Other than that, most problems fall into a) devices with busted firm-L > >> ware, or b) DEC trying to protect their market by placing arbitrary re-J > >> strictions of only working with known DEC drives on their controllersH > >> (the aformentioned RQZX1, and the KZQSA come to mind). But that's a. > >> marketing stupidity, not a technical one. > > H > > Sounds like you and Glenn are/were involved with OVMS engineering at > > some point.i > H >   I believe Glenn was. I was an end-user who helped out on a number ofH > products, almost all of which were in the PDP-11 space (for example, IJ > did the English translations in the RQZX1 as well as re-thinking some ofH > the firmware logic, though I didn't do the code itself). Note that theJ > RQZX1 is a combo MSCP/TMSCP controller, so all the "SCSI-ness" is hidden! > inside the controller firmware.  > L > > Can either of you list the criteria (those portions of the SCSI "spec.")J > > to which DKDRIVER/MKDRIVER expect strict adherence, and how to inquire; > > of a vendor whether their device(s) meet such criteria?i > I >   Glenn could relate additional specific instances of non-conformity ifg > he's so inclined.o > G >   The "SCSI spec" is actually a group of standards (for the differingsI > versions, as well as being split into more manageable parts in the mosttI > recent implementation). It's a large book, and you need to compare whateH > it says to what vendors have implemented. This requires getting a copyJ > of the appropriate manuals from the drive vendor. And of course the ven-I > dor may not know (or may not admit) that they aren't compliant with the  > standard in some areas.- > G >   There has been a lot of good work on the VMS SCSI drivers in recenthG > years. As long as a drive correctly implements the standard, does not.I > have missing features, and (sometimes) has its mode page or options seti( > a particular way, it should work fine. > H >   In the case of the jukebox-on-same-ID problem I described, the driveI > firmware (the generic firmware) definitely has a problem - in the prev-.F > ious firmware, I could get the drive to lock up (the front panel LEDI > display would spontaneously change language and the drive would lock upyJ > needing a power cycle to get it back). Even if the VMS drivers are doingI > something funny (and in this case, I'm pretty sure they are), the drivenI > should not do this. Given that the drive goes "off into the weeds" liketK > this, it's of questionable benefit to do anything in the VMS driver untilrH > the drive's vendor gets their act together, firmware-wise. At least, aJ > working set of drive firmware would return a reasonable error message toG > the driver, saying "you said X and I don't like it", which would makepJ > fixing the problem a lot easier - right now, it would be like saying "so< > what did I say that upset you?" and not getting an answer. > H >   By the way, the 2 DS10's I have both have genuine Compaq devices - 26 > 9GB LVD drives in each, and a DLT8000 on one of 'em. > L >   Screwed-up drive firmware is _not_ just a VMS problem. I did SCSI driverK > development for BSDI's BSD/OS, and I can *assure* you that we saw lots oftK > problems there. In fact, BSD/OS defaults to TCQ off because broken drives L > outnumber working ones. And I can tell you horror stories about host adap-L > ter firmware as well (which is why I like the NCR/Symbios/LSI Logic ones -1 > you get to write your own controller firmware).  >  >   The BSD/OS 4.1 manual:> > http://www.bsdi.com/products/internet/release-notes/rn41.pdf > has this to say about TCQ: >  > "Tagged queueing > E > In BSD/OS 4.1, it is possible to read and write large files at full E > disk-transfer speed through the SCSI subsystem. The tagged queueing D > feature of SCSI 2 is utilized to achieve this. The firmware in theD > drive to implement tagged queueing is difficult and it is unfortu-F > nately not uncommon to find it broken. To make matters worse, drivesE > with incorrect firmware will typically appear to operate correctly,hB > but will silently read and write incorrect data. For this reason, > tagged queueing is not enabled by default. > G > There is no way to determine if the tagged queueing feature in a par-KE > ticular drive's firmware is flawed or not, other than by running it?G > and seeing if data corruption occurs. This test is not something thataG > should be done on a system with live data, as it is possible that allhD > data on the system could be lost! In most cases, upgraded firmwareG > for the drive will fix the problems. If you are unsure as to the cor-nD > rectness of the firmware in the drives you are using, contact your > drive vendor." > J >   SCSI is maturing, though - with the consolidation in the industry com-I > bined with customers using mostly IDE drives on PC-class systems, we'rePK > seeing a much better grade of SCSI implementations, overall. Part of thisnJ > is that nobody wants to rewrite drive firmware from scratch for new pro-J > ducts - they're re-using proven firmware on newer devices (with features	 > added).e > 6 >         Terry Kennedy             http://www.tmk.com7 >         terry@tmk.com             Jersey City, NJ USA-   ------------------------------  # Date: Mon, 23 Oct 2000 04:09:48 GMTa( From: Terry Kennedy <terry@gate.tmk.com># Subject: Re: Handling oddball disks5' Message-ID: <G2v7KC.H1M@spcuna.spc.edu>a  , Glenn C. Everhart <Everhart@gce.com> writes:> > As for the LUN problem mentioned in David's post, I will add@ > that different LUNs on a SCSI ID are supposed to be completelyC > independent devices, and if a busy on one lun of an ID interferes > > with another lun of that ID, the device is FLAT OUT NOT SCSI
 > CONFORMANT.e  C   Let's try again. I was writing for a general audience and was notiB giving the technical details. And I was talking about tape drives.  F   Consider the following - you can't tell if a tape drive is rewindingE without asking it, since it could have been commanded by the operator  from the drive's control panel.d  C   You do a dismount/unload on the tape device, which returns immed-eB iately, even though the rewind is happening. The command procedureC you're using then issues a "robot unload" command (robot is the DEC D product MRU, BTW). This involves commands to both the drive part andA the jukebox part - a redundant rewind/offline to the drive and a oD move medium to the jukebox. The rewind/offline gets a command rejectB - operation in progress and the move medium pends because the tapeD is still in the drive. The driver has a short timeout on move mediumB and generates a device reset, which affects the whole ID, not justC the jukebox LUN. This reset bollixes up the drive part, causing thetC logging area of the tape medium to be corrupted, if it happens when B the logging area is being updated. If it happens while the tape is3 in the process of ejecting, you get a loader fault.   E   The device should definitely do a better job of handling the reset, D but I have to think there's a MKDRIVER/GKDRIVER/MRU issue here, too.  = > Many of these exist, because decoding LUNs is expensive and ? > Some of the guesses about SCSI bus arbitration here are wrong A > and should be omitted from the discussion. Study the SCSI spec,i? > and realize it is not a 10 minute activity. There are lots of ( > little twisty passages, all different.  C   Are you talking to me, or was this just tacked onto your reply toM my post?  4         Terry Kennedy             http://www.tmk.com5         terry@tmk.com             Jersey City, NJ USAo   ------------------------------  % Date: Wed, 18 Oct 2000 22:30:05 +0100 . From: Roger@natron.demon.co.uk (Roger Barnett)% Subject: Re: OpenVMS in Oil companies - Message-ID: <295803613wnr@natron.demon.co.uk>)  S In article: <39e44012.156575633@news.newsguy.com>  A.Greig@virgin.net (Alan Greig) h writes:  > E > On 10 Oct 2000 13:58:31 -0500, young_r@eisner.decus.org (Rob Young)  > wrote: > : > >	senior consultants?  You mean senior unix consultants? >  > EDS to be precise.    7 Would that be the same EDS who maintain DecSet on VMS ?i   -- o
 Roger Barnettt   ------------------------------   Date: 23 Oct 2000 04:44:37 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog) Subject: Re: PDF under OpenVMS, Message-ID: <8t0fnl$780@gap.cco.caltech.edu>  V In article <39F0AAD9.7913@ups.edu>, "William S. LaCounte" <vmsmanager@ups.edu> writes:= >I have been considering getting an HP 2100M for use at home.nD >I picked this model because it has Postscript and I didn't need the+ >network connection such as with the 4050N.r >lH >Is the Postscript in the 2100M real Postscript (Adobe) or is it a clone >and/or emulator?d >n  G It's an emulator.  I've not been able to get DCPS to work reliably withtG a 2100M.  Pages always get stuck and you have to hit the reset button -jC then they come out.  PITA.  DCPS does work ok, after a fix from Ken1K Fairfield is installed, with a 2100 TN.  Or to be more accurate, we have 2 tJ here and one of them works fine.  The other has some bizarre problem whereC it won't hold settings.  Luckily fixing that printer is not part oft my job.   G DCPS has its strong points but working with an arbitrary remote printerwG isn't one of them.   The old MSAP printer function in Pathworks/Mac wasdD much more reliable, just plug in the PPD, and there was always a PPD available,  and you were done.     David Mathog mathog@seqaxp.bio.caltech.edu ? Manager, sequence analysis facility, biology division, Caltech i   ------------------------------  % Date: Sun, 22 Oct 2000 14:45:48 -0400e( From: Jonas Lindholm <jlindholm@rcn.com>+ Subject: Re: Stockholm Exchange OM and VMS?t' Message-ID: <39F335DC.E4AC00AF@rcn.com>k   No VMS involved.   /Jonas LindholmO    richard_maher@my-deja.com wrote:   > Hi,  >hF > Does anyone know why the Stockholm exchange's trading system crashed: > twice yesterday for a total of 2hours? Was VMS involved? >i > Regards Richard Maher  >i( > Sent via Deja.com http://www.deja.com/ > Before you buy.r   ------------------------------  % Date: Sun, 22 Oct 2000 20:51:29 +0200l% From: "Kirk Acid" <kirk.acid@lion.cc> % Subject: Re: User Guide for Vax (VMS) 5 Message-ID: <kIGI5.40$FW1.2627@nreader1.kpnqwest.net>   H Thanks for your help, i tried out all... (i wanted to know how to set an5 ip-addr., how to use ftp and how to install netscape)c    9 SHOW SYSTEM works, ive a VAX/VMS V5.5-2  (is that good?)o  6 UCX SHOW VERSION             unrecognized command verb6 TCPIP SHOW VERSION           unrecognized command verb6 MULTINET SHOW/VERSION        unrecognized command verb  @ RUN TCPWARE:NETCU           error aktivating image TCPWARE:NETCUK                                                        error in device name  or inappropiate device typeeE                                                         for operation   2 RUN SYS$SYSTEM:IPCP         error aktivating imageH                                                           image file not foundn  . show network               network unavailable    6 ..what does that now mean ??  is there no tcp-stack ??   Thanks, Andreas Safranek   ------------------------------  % Date: Sun, 22 Oct 2000 14:37:38 -0500l7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>t% Subject: Re: User Guide for Vax (VMS)m- Message-ID: <39F34202.335BDE69@earthlink.net>    Kirk Acid wrote: > J > Thanks for your help, i tried out all... (i wanted to know how to set an7 > ip-addr., how to use ftp and how to install netscape)e > ; > SHOW SYSTEM works, ive a VAX/VMS V5.5-2  (is that good?)e  7 Old, but still supported as a "mature" "prior version".   h8 > UCX SHOW VERSION             unrecognized command verb8 > TCPIP SHOW VERSION           unrecognized command verb8 > MULTINET SHOW/VERSION        unrecognized command verb > B > RUN TCPWARE:NETCU           error aktivating image TCPWARE:NETCUM >                                                        error in device nameg > or inappropiate device typeoG >                                                         for operationu > 4 > RUN SYS$SYSTEM:IPCP         error aktivating imageJ >                                                           image file not > foundn > 0 > show network               network unavailable > 8 > ..what does that now mean ??  is there no tcp-stack ??  D If the other poster's comment about CMUIP_ROOT:IPNCP instead of IPCPC also produces no results, than no - you have no IP stack. If you'retE coming to VMS from the UN*X or NT worlds, you need to understand thattE TCP/IP does not "come with" VMS. It's an add-on, just like it was fork4 Windows 3.1. VMS's "native" network stack is DECnet.  F There's been a link floating around to the current CMU/IP, but I don'tE have it handy just now. CMU/IP is unsupported freeware, available for H VAX only and is somewhat outdated, but is still useful in large measure.  H If this is a hobbyist box and not a production (commercial) machine, youG might want to look into the Hobbyist License(s) for OpenVMS and layerede: products (including DECwindows/MOTIF and TCP/IP Services):  ! http://www.montagar.com/hobbyist/u  F Commercial licenses for OpenVMS and layered products get a bit pricey,F even for something as small, limited and slow as a MicroVAX 2000. YourF local Compaq reseller can be of service there. If this is a production@ box, you may want to consider moving to a bigger MicroVAX or, if? possible, moving to a small Alpha box. All VAXes are now out ofrB production; so, the only place to find them is on the used market.   -- h David J. Dachtera  dba DJE Systems  http://www.djesys.com/  : Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/l  F This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected.  @ Feel free to exercise your rights of free speech and expression.  F However, attacks against individual posters, or groups of posters, are strongly discouraged.a   ------------------------------   Date: 23 Oct 2000 02:15:30 GMT/ From: Thomas Dickey <dickey@saltmine.radix.net>   Subject: vile 9.2 - announcement* Message-ID: <8t0702$onq$4@news1.Radix.Net>   hello --  % I've just put vile 9.2 up for ftp at:i       http://www.vile.cx/e     http://dickey.his.com/vile/e*     ftp://dickey.his.com/vile/vile-9.2.tgz   and it is mirrored at'  .     ftp://ftp.phred.org./pub/vile/vile-9.2.tgz  7 PC binaries are also available for OS/2, DOS and WinNT.a  D Vile is a text editor which is extremely compatible with vi.  It hasG extended capabilities in many areas, including:  multi-file editing andeH viewing, mouse support, infinite undo, additional operators, rectangularI operations.  Vile has an optional Perl interface for UNIX and NT.  It canTI also be built as "xvile", which is fully X-aware, or "winvile" for Win32,5G with scrollbars, menus, etc.  It runs under VMS, BeOS, OS/2, DOS, Win95VG or NT.  Binaries for some PC operating systems are available.  (OS/2 isbG currently native or EMX console mode port, NT is both console and GUI).u   Highlights since 9.1:i  "     + lots of bug fixes, of course  D     + improve performance of syntax highlighting with new line-based       attribution mechanism.  ?     + improve performance of syntax highlighting with configureoA       option for compiling-in any of the syntax filters.  Use theeH       configure --with-builtin-filters option.  Both internal (built-in))       and external filters are supported.t  B     + add command attribute-directly, to invoke internal filter on@       the current buffer.  External files are still used for theC       keywords, but this can eliminate the subprocess and pipes fort        filters that are built-in.  ?     + add key binding functions for the different editing modesa0       (insert, command, minibuffer and default),B       making it simpler to bind a space or tab to a given function?       without having it confused for a function while in insertI       mode.   
 Bug fixes:  B     + suppress logic in termcap/terminfo driver that resets colorsC       when the terminal does not support color.  Otherwise, reverse 7       video and other non-color attributes do not work.   D     + correct modetbl entry for &sless function, which was returningA       a string rather than a boolean (this was broken between 8.2p       and 8.3).   C     + correct logic for &left and &middle functions, which returnede(       one too many characters after 8.3d  @     + rewrite logic for majormode "after" and "before" keywords,'       fixing a potential infinite loop.K  B     + correct missing check for backslash within a character rangeD       in regatom(), which caused patterns such as "[^\[\]]" to matchC       any character other than left bracket which was followed by aI       right bracket.  C     + correct a case in minibuffer editing which did not completelyDD       restore the buffer position when an error was found.  This ledD       to passing an empty buffer with an associated nonzero position+       to fill_partial(), which dumped core.   A     + several fixes to ensure that autocolor does not repaint the 0       screen in the middle of operations such as       highlight-selection.  B     + correct behavior of implybuffer mode when the specified file>       is being appended to.  Given ":w >>foo", it was making a       buffer named ">>foo".   C     + correct computation of 'diff' variable in tcapattr(), and add C       a check for coincidence between strings that are used to turnaD       off corresponding video attributes.  The first error made vileB       turn off the wrong attributes under some conditions, and theC       second would cause it to omit turning back on attributes thats&       it had inadvertently turned off.  D     + rephrase loop in purge_line_attribs() to handle the case where@       the ending line-pointer is at the end of the buffer.  ThisB       makes the ^A-NG command (clear-attributes-til) work when the"       cursor is on the first line.  A     + modify logic for name-completion to force the cursor to thev=       end of the input buffer before attempting to complete. fC       Otherwise, partial completions could be written in the middlec       of the buffer.  D     + modify logic in kbd_reply() to set last_eolchar from the given=       eolchar, e.g., '=', rather than the current contents ofsD       execstr, since that may contain an arbitrary character such asA       the first one of an identifier.  That made commands such asl         setl autowrite=false6       in a macro not work, since 'f' (false) was used.  A     + recover if a 'source' command results in runaway recursion,p8       e.g., if foo.rc contains the line "source foo.rc".  # Several Perl-specific improvements:e  A     + Vileserv now uses the registry, so 'perl "use Vileserv"' ine=       your .vilerc automagically adds the commands startserv,r"       stopserv, and vileserv-help.  C     + Vileserv tries to be smarter about finding your perl binary.  ;       The Vile variable %vileserv-perl-path can be used foru       customization.  @     + Vileserv tries to be smarter about the socket path that itC       uses.  The environment variable VILESOCK, as well as the Vilet@       variable %vileserv-socket-path can be used.  Also, vileget=       supports an option for overriding the socket path.  The ;       default location is still ~/.vilesock.  With a littleSC       scheming, you can now run and control multiple XVile sessionshB       on one host, or use Vileserv on multiple hosts with a shared       home dir.k  >     + Vileget now uses the -d option to change XVile's working?       directory.  This is an interface change from version 1.1,k,       where the -c option was used for this.  B     + Vileget now uses the -c and -C options for passing arbitraryD       Vile commands to a running XVile.  See the vileget manual pageA       ('perldoc vileget') for more info on this.  Please note the 8       necessary Vile variable %vileserv-accept-commands.  >     + modify perl.xs to allow perl operators to be used with a       range.  >     + added gdb.pm, which runs gdb in a vile window and tracks7       changes in editor.  (Must be used with shell.pm.)   A     + modified to build with Perl 5.6.0, and some workarounds forr3       functionality that changes with that version.a  $ Several Win32-specific improvements:  0     + add reset-rgb-palette command for winvile.  .     + add set-rgb-palette command for winvile.  :     + win32 console vile now has "true" autoscroll support  &     + implement type-ahead for winvile  ?     + modify winvile to continuously show the geometry during aa
       resize.u  @     + fix winvile ":sh" command, which used to pop up a separateB       window, but does not as of 9.1 In 9.1, ":sh" on a win32 host?       is executed as "$shell {-c|/c} $shell".  As it turns out,l=       cmd.exe's intrepretation of the /c switch is to run thes?       specified command and exit immediately.  Fix by launchingv!       $shell via CreateProcess().g  >     + modify filter keyword-file search to avoid concatenating;       $HOMEDRIVE when $HOME already specifies the device inr       home_dir().   E     + winvile's right mouse menu includes these new context-sensitiveo       commands:rH         cmd name  bound to                     txt slctn  txt slctn mustF                                                  rqd?    be in curbuf?G         --------  --------                     ---------  ------------- '         undo      undo-changes-backward-&         redo      redo-changes-forward@         cut       cut-to-clipboard                 X           X4         copy      copy-unnamed-reg-to-clipboard    X&         paste     paste-from-clipboard@         delete    delete-text-selection            X           X  C     + added a winvile `about' box (available from the System Menu).s  B     + initialize the winvile "Save As" dialog with the name of the       current open file.  D     + added cut-to-clipboard (windows Cut) and delete-text-selection<       (windows Delete) to [win]vile.  The former is bound toD       Shift+Delete, the latter to Alt+Delete.  Both commands require       a current text selection.f       + enable tilde-expansion  D     + correct glob test for "~" which can be expanded as user's home?       directory.  The test allowed expansion of tilde at points D       other than the beginning of a path component, which can happen       on win32.   C     + ensure that a console window is created for the ":sh" command"8       when winvile is invoked from a GUI rather than the       command-line.a  9     + allow pasting of one line of text into mini-buffer.t  @     + winopen, winopen-nocd, winsave, and winsave-nocd accept an>       optional directory argument, which specifies the initial=       directory opened by the Open/Save Win32 common dialogs.v  D     + added the state variable $favorites, which returns the path to@       the Windows Favorites directory.  Added a "Favorites" menuA       selection to winvile's RMB menu, which executes the commandh       "winopen $favorites".,  C     + correct char_no() function to use record-separator length, sow@       $curchar is evaluated properly for dos files, e.g., for ^G
       commande    Other new features/improvements:  G     + lots of small improvements to syntax filters, including a rewrite/       of the perl filter.a       Majormodes:b  D     + add reset-majormode command, which tells vile to recompute the4       appropriate $majormode for the current buffer.  H     + modify majormode suffix matching to use the ignorecase mode valuesJ       for those systems that are normally case-sensitive, making this work?       for names such as "FOO.BAT" which happen to be uppercase.r       Other Modes:  :     + add highlight mode, which when disabled prevents the:       corresponding buffers from being syntax-highlighted.  C     + add insert-exec mode to control logic in ins_any_time() which >       interprets control characters which are bound to GOAL or@       MOTION commands rather than inserting them without quoting=       (see 9.0a and 9.0b changes).  This restores the defaultrB       behavior, since some users had control characters bound to a'       function which was then executed.   ;     + add pin-tagstack mode, which prevents the editor fromsB       switching windows during a tag/push operation (i.e., all tag,       ops are pinned to the current window).  B     + add unique-buffers mode, which does dev/inode checking to be.       sure files aren't edited more than once.  B     + modify implybuffer mode so that if the buffer already exists;       and is not modified, it will be automatically reread.i       Syntax Filters:a  '     + add syntax filters for sed, imakei  C     + implement abbreviations for syntax keywords, using '*' as thei       default delimiter.  @     + filters now attribute multi-line regions when appropriate,%       e.g., multi-line comments in C.r  =     + improve decoding of ANSI escape sequences in manfilt.c,m-       including parsing of foreground colors.   B     + show unterminated quotes in m4, sh, make and perl filters as       an error.j  !     Macros and Scripting Support:e  D     + add command unset-variable, which resets the given variable to;       a null or default value.  This is useful only for thew/       $-variables, since modes require a value.e  @     + add uppercase "TRUE" and "FALSE" to fsm_bool_choices[], so@       assignments to boolean modes work properly within a macro.  ?     + add &dquery function which prompts for input with a given        default value.  C     + implement function &error, which returns true if its argumentsD       was an ERROR token.  Modify built-in functions to return ERROR       if an argument was ERROR.e  C     + add built-in function &filter, to tell if the given majormode-       has a built-in filter.  @     + add variable $filename-expr, to specify the actual patternD       used for %F in [Error Expressions].  On DOS and Win32, this isA       initialized to a more complex pattern, to accommodate drive_       letters.  >     + add variable $xshell-flags to allow customising $xshell.  /     + make the ~local directive work for modes.   B     + add ~trace directive, which sets or reports the value of the>       $debug variable.  Use this to trace into internal buffer       [Trace].  B     + add example macro AddError to vile.hlp which illustrates how-       to add a string to [Error Expressions].   A     + add macros/color-ls.rc, example using improved manfilt.c tot*       display color ls output in a buffer.  A     + modify macros/manpage.rc to use lynx to render html files. hA       This uses the development version of lynx (2.8.4dev.3, with5/       the -stdin and -with_backspaces options).   D     + modify macros/manpage.rc to unset the filename associated with?       the buffer so it does not display.  This ensures that thee       ruler is always visible.  C     + add macros/shifts.rc, which implements left/right shifting of 9       words in the current line to align with the cursor.t       Building/Porting:   6     + implement a curses/ncurses terminal driver.  Use@       --with-screen=curses or --with-screen=ncurses to configure?       this.  No mouse is supported in this configuration.  This 6       version builds only with SVr4 curses or ncurses.  C     + add configure --with-ncurses option, e.g., for OS/2 EMX which &       has an unusable termcap library.       Other Changes:  D     + modify 'setv' logic to provide the current value of a variable       when setting it.  ?     + implement name-completion for user variables, e.g., %foo.r  B     + shorten the confirmation questions/messages that result from?       modtime checking.  with very long buffernames the currenteB       messages extend past the 80 column boundary, making the tail2       end of the question invisible in some cases.  6     + improve performance of majormode initialization.  ?     + modify color support in xvile to allow the pre-8.3s color ?       scheme as a special case:  setting bcolor to fcolor makes @       xvile use the bcolorN resources on syntax-highlighted textA       rather than the color selected by bcolor (which is actually 4       taken from the fcolorN resource in this case).  D     + rewrote filters/makefile.wnt to generate lists and rules usingB       scripts reading genmake.mak, to facilitate building internal       or external filters.  D     + for several select cases, when a long path causes message line;       text to exceed the current window width, that path is ;       shortened on the left until the message text fits (iftD       possible).  Those select cases include failure to save a file,@       reading in a new file, and writing out (or appending to) a       file.   @     + add %c and %l format types to finderr.c, which use 0-based*       offsets rather than 1-based offsets.  A     + modify handling of motion commands in minibuffer editing to.C       use new table data that indicate commands that cannot be usedd$       in minibuffer editing motions.  B     + improve color comparisons in xvile to compare RGB componentsA       when their difference is relatively small.  Add a check for B       the default resource value of fcolor0, forcing that to black@       if xvile's foreground does not look different from white. :       This makes some of the color palette commands, e.g.,         :set cs=blacki       work properly.  ?     + annotate the verbose form of which-source and which-exec,s?       showing the corresponding variable for each path which isa9       tested, e.g., "$PATH" when checking items in $PATH.d  D     + added pushd, popd, dirs commands with accompanying [DirStack].  >     + accept -i option as an alias for -I, which has the added?       benefit of allowing vile to be used as a $SHELL value fore;       script, since that passes a -i option to the "shell".d   -- o= Thomas E. Dickey <dickey@radix.net> <dickey@herndon4.his.com>: http://dickey.his.com/ ftp://dickey.his.com   ------------------------------   End of INFO-VAX 2000.592 ************************