INFO-VAX Sat, 24 Feb 2007 Volume 2007 : Issue 110 Contents: Re: Canadian OpenVMS Seminar (07.02.20) Re: Is it possible to boot OpenVMS from an IDE disk on an ES40? Re: Privs required for NCP SET and DEFINE Re: Quebec Health Care Virus Re: Quebec Health Care Virus Re: TSZ07 Re: TSZ07 Re: TSZ07 Re: TSZ07 ---------------------------------------------------------------------- Date: Sat, 24 Feb 2007 15:48:24 GMT From: rdeininger@mindspringdot.com (Robert Deininger) Subject: Re: Canadian OpenVMS Seminar (07.02.20) Message-ID: In article <45dc34e6$0$8758$ed2619ec@ptn-nntp-reader02.plus.net>, "John Wallace" wrote: > wrote in message >news:1172054139.583563.188340@s48g2000cws.googlegroups.com... >> 4) The Itanium chip can provide RAS (Reliability, Availability, >> Serviceability) while x86-64 systems currently do not. I heard one >> engineer >> say "Bill Gates isn't responsible for all instances of the >> blue-screen-of-death; the quirkiness of x86-64 and supporting chip- >> sets are >> partially to blame" >> > >Glad you had a good day. But... > >Does a claim become believed these days simply because it's repeated often >enough, or do sensible folks need actual evidence? Sensible folks need evidence, of course. But this IS comp.os.vms, so don't set your standards too high. You raise some interesting points. I'll attempt to point to some technical info, but alas, marketing fluff creeps into most technical documents to some extent these days. >I've heard this "missing >RAS features" assertion for years. Over the years, I've listened carefully >for any actual evidence. I've not yet seen or heard any such evidence; this >post is a plea for real concrete documented evidence. So far, I see more >evidence that the insistence on Itanium is down to (hidden) commercial >factors rather than real documented technical factors, which is of course a >perfectly valid way of doing business (it may look strange from outside but >we can't see the details of the back-room dealings). > >I don't do system level design myself, but I have spent many years helping >other folks find out why their kit is behaving unexpectedly, looking at >everything from timing diagrams to debugger listings and source code and... >I understand the difference between features in an architecture (if it's >missing from the architecture, you're likely stuffed), and (mis)features in >an implementation (lots of PC-class stuff ships if it mostly appears to >work, never mind the spec). I've read and mostly understood the AMD64 >architecture docs and the Opteron chip docs available from AMD. Before that, >I'd read and mostly understood, and worked with, the equivalent Alpha stuff >(architectures, chips, implementations) and other related stuff (other >people's chipset docs, for example). > >Since the OpenVMS on AMD64 discussions started, I've looked carefully for >important RAS things that couldn't architecturally be done on an AMD64 >implementation that could be (and were) done on an Alpha implementation (I'm >not familiar with Itanium at this level). I haven't looked at AMD64 at all, so I can't comment. Except to note that every CPU architecture I HAVE studied (including VAX, Alpha, and Itanium) has a long list of optional, planned-for-the-future, features. I can only assume AMD64 is similar. So it may be important to distinguish between what the AMD64 architecture allows, and what actual high-volume, low-cost implementations support in the real world. Again, this is only speculation about AMD64 on my part. >I've not yet spotted any important >capabilities missing from AMD64 so maybe I've been looking in the wrong >place. I'd welcome pointers to real examples. I'm not interested in examples >of broken consumer-class chipsets etc (eg similar to the broken IDE problem >in the early PWS/Alpha systems, and goodness knows what problems in current >consumer-class PC chipsets) - these are typically not unfixable >architectural issues, they are more likely to be implementation errors which >could be fixed given sufficient commercial motivation (which usually doesn't >exist in SoHo PCland). We don't write OS support for "architectures", we do it for real systems, with real CPUs (always buggy), real chipsets (always buggy), and real IO devices (always buggy). And every one of these hardware components is a compromise between cost, time-to-market, and feature set. (I'm counting performance as one of many desireable features.) The difference between the real systems we work with and the ideal ones described by specifications and architecture documents accounts for a great deal of time and cost in the OS world. >Although the commercial motivation to run "BSOD free" doesn't usually exist >in SoHo PCland, lots of folk are happy to run Proliant-class systems with >AMD64 at their heart, at various price points and various levels of >business-criticalness, and Proliant owners aren't famous for liking BSODs. >Which specific RAS features are those AMD64 boxes missing which are present >in Itanium-based systems ? I realise this may be rather more detail than the >typical HP audience needs, but if HP don't have this level of detail in a >white paper or whatever, perhaps because it would understandably be >unpopular with the Proliant folks, maybe Dell or someone else do (most >companies other than HP/Intel have no reason to be involved in secret >Itanium-related back-room dealings). Some documents I found that may be of some interest... I didn't find everything I wanted in a quick search of HP's web sites; some documents may not have been released yet (and I won't release internal versions unless I find them on the external web) and some I probably missed because HP's web sites and search capabilities are mostly horrible. 1. This is the full (external) spec for HP's "Mercury" IO bus master, which supports AGP, PCI, and PCI-X up to 133 MHz. This is the IO chip in the "zx1" chipset (for PA-RISC and Itanium): http://h21007.www2.hp.com/dspp/files/unprotected/linux/zx1-ioa-mercury_ers.pdf You can find a lot of facts about the RAS features this chip supports. Not every system takes advantage of all of this, and not every OS takes advantage of all of the system features. In broad terms, the design emphasis is on detecting as many transient errors as possible, fixing some of them on the fly (via hardware, firmware, or OS), isolating problems so they don't affect the whole system, preventing virtually all undetected data corruption, and logging enough error information to allow reliable identification of bad components for replacement. This means parity and ECC protection on data paths, and on-line correction of errors that are likely to be the most common. The most obvious example is single-bit errors in main memory. With today's memory densities, single-bit errors are a fact of life. Most systems WILL incurr many single-bit in a year of normal operation. They have to be corrected on the fly, with no impact to the application or the OS. (There will be a tiny slowdown while each error is corrected.) Double-bit errors are getting common enough to warrant the similar attention. (Memory errors are not the job of the mercury IO chip, but I mention them here because they are easy for many folks to understand and are part of the general discussion.) I didn't find the corresponding specs for the other chips in the set, nor did I find any of the current-generation "zx2" specs. The zx2 RAS features are similar in spirit to zx1, but more extensive. The white papers (below) give some highlights. 2. Here are a couple of white papers on zx2. There is a fair amount of overlap between these two papers, and some of the technical points seem garbled: http://h71028.www7.hp.com/ERC/downloads/c00767228.pdf http://h71028.www7.hp.com/ERC/downloads/c00767235.pdf 3. Here is a quasi-technical marketing blurb about HP's new entry-level Integrity servers that use the zx2 chipset. There is a section on high availability: http://h71028.www7.hp.com/ERC/downloads/4AA0-6159ENW.pdf 4. Here are a couple of Intel documents that describe the Itanium CPU family: http://h21007.www2.hp.com/dspp/files/unprotected/Itanium/24531804.pdf http://download.intel.com/design/Itanium/Downloads/24927802.pdf The second document is a detailed description of Itanium error handling. These two are architectural documents; there are additional documents that cover details of particular generations of CPUs. I did not have time to dig those up. See my cautions above about architectural vs. implementation features. We have to be aware that there are many ways to improve "reliability" or "availability" of a computer system, and some of them are counter-intuitive. For example, you can cut the expected "downtime" of a system in half without improving the hardware at all. Just make the OS boot twice as fast after a hardware-induced crash. You don't have to do anything to reduce the NUMBER of crashes per unit time. This might be a significant win for some applications ( a farm of servers running a search engine, perhaps) but be absolutely useless for others (a spacecraft control computer). Similar improvements in downtime can be achieved by reducing the time required to swap out faulty hardware components. All marketing fluff should be taken with a grain of salt, and fancy-sounding terms should be defined and understood before any real-world value is assumed. ------------------------------ Date: Sat, 24 Feb 2007 11:12:13 -0600 From: "Craig A. Berry" Subject: Re: Is it possible to boot OpenVMS from an IDE disk on an ES40? Message-ID: In article <1172227848.363049.45770@s48g2000cws.googlegroups.com>, "Camiel" wrote: > I created the image as follows: I took the original OpenVMS 8.3 > installation CD-ROM, and used Nero to extract an ISO image from it. > This should result in a flat file, that has all the data on the CD in > it. In my (admittedly limited) experience, Nero is worthless for creating images that are useable by anything but Nero. I had a VAX boot image created by Nero that neither SIMH nor LDDRIVER could make any sense at all out of. I had to obtain a copy of Nero, burn an actual CD from it, then take an image of the CD using a tool that didn't do so much interpretation of what a CD image should have on it. Then SIMH was happy. I used Mac OS X's Disk Utility to create the image from the CD. On Linux, you can probably just use the dd command. It may be that Nero has the ability to create an image correctly if you find a way to turn off all its advanced features and compression and so on, but it seems like it would be prudent to remove Nero from the equation first and only resort to disassembling the VMS boot sequence once you've reproduced the problem using a disk image created in one or more other ways. -- Posted via a free Usenet account from http://www.teranews.com ------------------------------ Date: Sat, 24 Feb 2007 18:52:08 +1100 From: Jim Duff Subject: Re: Privs required for NCP SET and DEFINE Message-ID: <45dfeea8$1@dnews.tpgi.com.au> Jeff Cameron wrote: > I hope someone can help me here, > > What minimum privilege or privileges are required to perform the following > NCP> commands: > > NCP> SET NODE HARDWARE ADDRESS > NCP> DEF NODE HARDWARE ADDRESS > > I currently have just TMPMBX and NETMBX and can run NCP and do a : > > NCP> SHOW NODE CHARACTERISTICS > > I'm configuring some replacement DECServers and need to change the e-Net > address so they can boot. > The system admin only wants to grant me those privileges I need to do the > job. > > Thanks in Advance. > Page 2-2 in the "DECnet for OpenVMS Network Management Utilities" manual, found here: http://tinyurl.com/2ne4bz (warning, large PDF document). At first glance, it looks like SYSPRV and OPER, which I doubt your admin will just casually grant you ;-) Jim. -- www.eight-cubed.com ------------------------------ Date: Sat, 24 Feb 2007 19:38:19 +0800 From: Paul Repacholi Subject: Re: Quebec Health Care Virus Message-ID: <87ps7z4wgk.fsf@k9.prep.synonet.com> Tad Winters writes: > Imagine this as a preventative measure: Remove all browsers. Remove > all email clients. Set firewalls to block all traffic outbound to > ports 80, Great, you have just shut off access to 99.9% of the worlds medical journals and health info... Have you considered gettin a job in managment? ------------ And now a word from our sponsor --------------------- For a secure high performance FTP using SSL/TLS encryption upgrade to SurgeFTP ---- See http://netwinsite.com/sponsor/sponsor_surgeftp.htm ---- ------------------------------ Date: Sat, 24 Feb 2007 16:05:24 GMT From: Tad Winters Subject: Re: Quebec Health Care Virus Message-ID: Paul Repacholi wrote in news:87ps7z4wgk.fsf@k9.prep.synonet.com: > Tad Winters writes: > >> Imagine this as a preventative measure: Remove all browsers. Remove >> all email clients. Set firewalls to block all traffic outbound to >> ports 80, > > Great, you have just shut off access to 99.9% of the worlds medical > journals and health info... It's merely a cost of using insecure technology. However, medical journals and health information exist outside of computers. Once upon a time, this kind of information was *all* available on paper... :-^) ------------------------------ Date: Sat, 24 Feb 2007 19:54:03 +0800 From: Paul Repacholi Subject: Re: TSZ07 Message-ID: <87lkin4vqc.fsf@k9.prep.synonet.com> bill@cs.uofs.edu (Bill Gunshannon) writes: > Are you sure? Then what is the wheel on the bottom that spins > inbetween that sensor? (See picture on website!) I just looked > again and there are no wires or anything coming from the tension arm > so I don't see how it could containt he tach sensor. Not the front one, the one at the rear that runs on the takeup hub. There is a tack under that black plastic `club' ------------------------------ Date: 24 Feb 2007 14:37:04 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: TSZ07 Message-ID: <54b0sgF1vcvbtU1@mid.individual.net> In article <87lkin4vqc.fsf@k9.prep.synonet.com>, Paul Repacholi writes: > bill@cs.uofs.edu (Bill Gunshannon) writes: > >> Are you sure? Then what is the wheel on the bottom that spins >> inbetween that sensor? (See picture on website!) I just looked >> again and there are no wires or anything coming from the tension arm >> so I don't see how it could containt he tach sensor. > > Not the front one, the one at the rear that runs on the takeup hub. > There is a tack under that black plastic `club' I don't think we are talking about the same tape drive. There is no front tensioner. I assume by "tensioner" you mean the arm with the wheel that presses the tape down on the take-up. It has nothing between it and the body of the drive except the pivot and a spring. I am certain the tach is the sensor on the bottom of the drive with the plastic wheel spinning inside it. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 24 Feb 2007 09:44:24 -0800 From: bob.birch@gmail.com Subject: Re: TSZ07 Message-ID: <1172339064.211896.229020@v33g2000cwv.googlegroups.com> On Feb 24, 6:37 am, b...@cs.uofs.edu (Bill Gunshannon) wrote: > In article <87lkin4vqc....@k9.prep.synonet.com>, > Paul Repacholi writes: > > > b...@cs.uofs.edu (Bill Gunshannon) writes: > > >> Are you sure? Then what is the wheel on the bottom that spins > >> inbetween that sensor? (See picture on website!) I just looked > >> again and there are no wires or anything coming from the tension arm > >> so I don't see how it could containt he tach sensor. > > > Not the front one, the one at the rear that runs on the takeup hub. > > There is a tack under that black plastic `club' > > I don't think we are talking about the same tape drive. There is no > front tensioner. I assume by "tensioner" you mean the arm with the > wheel that presses the tape down on the take-up. It has nothing > between it and the body of the drive except the pivot and a spring. > I am certain the tach is the sensor on the bottom of the drive with > the plastic wheel spinning inside it. > > bill > > -- > Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves > b...@cs.scranton.edu | and a sheep voting on what's for dinner. > University of Scranton | > Scranton, Pennsylvania | #include According to the service manual the velocity tach is mounted on the motors (page#28). There is only one packer (tension) arm. The tape in path and tape sensor/roller are mounted to the right side of the head (page#126). Book shows about 25 different failing conditions that can generate a motor fault (fault Msg #17). Anything from the take up reel, sensors, motors, etc. Even the drive servo parameters stored in memory. Service aid #117 shows you how to check the servo's using the front panel. I only have parts for the older drives not the M995, sorry. ------------------------------ Date: 24 Feb 2007 18:49:50 GMT From: bill@cs.uofs.edu (Bill Gunshannon) Subject: Re: TSZ07 Message-ID: <54bfmeF1tc1ivU1@mid.individual.net> In article <1172339064.211896.229020@v33g2000cwv.googlegroups.com>, bob.birch@gmail.com writes: > On Feb 24, 6:37 am, b...@cs.uofs.edu (Bill Gunshannon) wrote: >> In article <87lkin4vqc....@k9.prep.synonet.com>, >> Paul Repacholi writes: >> >> > b...@cs.uofs.edu (Bill Gunshannon) writes: >> >> >> Are you sure? Then what is the wheel on the bottom that spins >> >> inbetween that sensor? (See picture on website!) I just looked >> >> again and there are no wires or anything coming from the tension arm >> >> so I don't see how it could containt he tach sensor. >> >> > Not the front one, the one at the rear that runs on the takeup hub. >> > There is a tack under that black plastic `club' >> >> I don't think we are talking about the same tape drive. There is no >> front tensioner. I assume by "tensioner" you mean the arm with the >> wheel that presses the tape down on the take-up. It has nothing >> between it and the body of the drive except the pivot and a spring. >> I am certain the tach is the sensor on the bottom of the drive with >> the plastic wheel spinning inside it. >> >> bill >> >> -- >> Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves >> b...@cs.scranton.edu | and a sheep voting on what's for dinner. >> University of Scranton | >> Scranton, Pennsylvania | #include > > > According to the service manual the velocity > tach is mounted on the motors (page#28). > There is only one packer (tension) arm. > The tape in path and tape sensor/roller are > mounted to the right side of the head (page#126). That sounds closer to mine. :-) > > Book shows about 25 different failing conditions > that can generate a motor fault (fault Msg #17). Interesting. My error is "5F Motor Fault". Don't know what the #17 might be. Mine lists 2 fixes for that error, both involve replacing a piece of hardware. > Anything from the take up reel, sensors, motors, > etc. Even the drive servo parameters stored in > memory. > > Service aid #117 shows you how to check the > servo's using the front panel. I ran the motor calibration service aid (#525, I think it was) and after it failed a couple times I decided to watch what it actually printed on the display. Lit looks like the first two things it does are to tach the motors. Supply tachs around 300rpm. Take-up spins but the display always prints "0 rpm". Pretty good sign that the tach isn't working. :-) Everything else I have tried seems to work OK. Guess I need to trace that wire coming from the sensor (it kinda disappears under the blower housing) and see if I am lucky enough that the problem is going to be bad contacts where it hooks up to the logic board. Otherwise, I guess I need to determine if it is the logic board or the sensor. If it's the sensor ther eis always the possibility that I can repair it. I haven't pulled it off the motor yet but I am assuming it is just another led/photocell pair. Might be able to troubleshoot and repair it. > I only have parts > for the older drives not the M995, sorry. Thanks for the help. I looked at all the old Cipher parts I had (actually, my old Ciphers went to the physics department who are going to use things like the motors for building contest robots. :-) but none of them had a motor like this. I think maybe the old ones had a tach like Paul was describing as there does not appear to be any kind of a tach mechanism built onto the motors. Looks like some major re-design ont he newer ones. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ End of INFO-VAX 2007.110 ************************