INFO-VAX Mon, 21 Apr 2008 Volume 2008 : Issue 222 Contents: Re: Divining the full pathname of a file, all logicals translated Re: Divining the full pathname of a file, all logicals translated Re: Divining the full pathname of a file, all logicals translated Re: Divining the full pathname of a file, all logicals translated HSD52 dead reduced raidset Re: HSD52 dead reduced raidset Re: Intel Itanium RAS Comparison with X86 Re: Intel Itanium RAS Comparison with X86 Re: Intel Itanium RAS Comparison with X86 Re: Intel Itanium RAS Comparison with X86 Re: Intel Itanium RAS Comparison with X86 Re: Intel Itanium RAS Comparison with X86 Re: Intel Itanium RAS Comparison with X86 Re: Intel Itanium RAS Comparison with X86 Re: Intel Itanium RAS Comparison with X86 Re: Intel Itanium RAS Comparison with X86 Re: Intel Itanium RAS Comparison with X86 Re: Intel Itanium RAS Comparison with X86 Max drive size for HSZ22 ? Re: Max drive size for HSZ22 ? Re: OT: IBM looking at Macintosh Re: OT: IBM looking at Macintosh Re: OT: IBM looking at Macintosh Re: OT: IBM looking at Macintosh Re: Question on fast SCSI interface for Q-22. TL892 (two TZ89s) one "In-Flex" Re: TL892 (two TZ89s) one "In-Flex" Re: UIC full display Question Re: VMS advertising ! RE: VMS advertising ! ---------------------------------------------------------------------- Date: Sun, 20 Apr 2008 17:59:44 -0500 From: Muddflapp Mohican Subject: Re: Divining the full pathname of a file, all logicals translated Message-ID: If the database contains filenames that were not parsed with no_conceal, then the online filename and the database filename need to be parsed with no_conceal to see if they match and if they do, don't generate an exception. Or maybe a table could be created using "Show Logical */table=*" that could be used to verify that such-and-such device is the same as such-and-such-other device. I didn't know about an f$fid_to_name(), but I can see that it would probably return the filename using the disk logical that the disk was mounted with. To see what the disk was mounted with use f$getdvi(disk,"logvolnam"). Rich Jordan wrote: > On Apr 11, 10:01 pm, AEF wrote: >> On Mar 24, 4:27 pm, Rich Jordan wrote: >> [...] >> >>> OBTW the comment about people unfamiliar with VMS syntax; I expect >>> they'd know enough about dev:[dir1.dir2.dir3]file.name to be able to >>> follow it since we'd be telling them. I'd prefer not to give them >>> variances that might be confusing (extra "][" and missing ".") so it >>> makes sense to use the most basic and consistent syntax in the stored >>> information. >>> Thanks! >>> Rich >> Please, what are you trying to do? What is the purpose of this list? >> What are the users looking for when they use this list? What are they >> going to do with the file-spec when they find the one they want? Are >> they expected to retrieve the file from disk or tape? If so, why do >> they need the list? And how are they going to do anything with it if >> they don't have even a clue as to VMS file-specs? Etc. >> >> My apologies if I'm missing something obvious, but I have no clue as >> to what the point of all this is. >> >> If the OP is not following this thread anymore, I' asking anyone else >> who is to explain to me what the whole point of this is. >> >> As usual, without the original motivation it is difficult to come up >> with reasonably "optimized" (for lack of a better word I can't think >> of offhand) solution. >> >> Thanks! >> >> AEF > > Auditing changes to or moves of designated files for compliance to > certain government regulations. > > A physical change of location (hidden by logicals) is still an > auditable event requiring documentation. Hence the need to know the > physical path at the time the audit database is generated, in order to > compare it to the "current" state when an audit report is run. A hash > of each file is retained, along with file create/modify timestamps and > FID; the FID is only meaningful on a given logical drive unit so the > drive name needs to be retained also, unmasked from any logicals. > > The auditors are (as expected) well trained in suboptimal operating > systems like windows, but are not VMS-aware. Providing basic VMS file > specification information is not a problem but avoiding potentially > confusing variants such as paths with the embedded ][ is just a good > thing to do. Normalizing the stored pathnames also makes later > comparison and parsing more efficient and less likely to generate a > 'false positive' path change event. > > The auditors may never see the actual database. They will see a > report generated comparing the current 'state' of the system against > the archived state recorded in the database. The pathnames in that > report will come from one or the other (or both) locations when an > exception is noted. ------------------------------ Date: Sun, 20 Apr 2008 18:17:30 -0500 From: Muddflapp Mohican Subject: Re: Divining the full pathname of a file, all logicals translated Message-ID: Hi again. What do you use to create a hash code for files in the [sys$ldr] directory? My thought was that they are mostly opened for exclusive access when the system is booted up and you would get a "file open by another user" type of error. Rich Jordan wrote: > On Apr 11, 10:01 pm, AEF wrote: >> On Mar 24, 4:27 pm, Rich Jordan wrote: >> [...] >> >>> OBTW the comment about people unfamiliar with VMS syntax; I expect >>> they'd know enough about dev:[dir1.dir2.dir3]file.name to be able to >>> follow it since we'd be telling them. I'd prefer not to give them >>> variances that might be confusing (extra "][" and missing ".") so it >>> makes sense to use the most basic and consistent syntax in the stored >>> information. >>> Thanks! >>> Rich >> Please, what are you trying to do? What is the purpose of this list? >> What are the users looking for when they use this list? What are they >> going to do with the file-spec when they find the one they want? Are >> they expected to retrieve the file from disk or tape? If so, why do >> they need the list? And how are they going to do anything with it if >> they don't have even a clue as to VMS file-specs? Etc. >> >> My apologies if I'm missing something obvious, but I have no clue as >> to what the point of all this is. >> >> If the OP is not following this thread anymore, I' asking anyone else >> who is to explain to me what the whole point of this is. >> >> As usual, without the original motivation it is difficult to come up >> with reasonably "optimized" (for lack of a better word I can't think >> of offhand) solution. >> >> Thanks! >> >> AEF > > Auditing changes to or moves of designated files for compliance to > certain government regulations. > > A physical change of location (hidden by logicals) is still an > auditable event requiring documentation. Hence the need to know the > physical path at the time the audit database is generated, in order to > compare it to the "current" state when an audit report is run. A hash > of each file is retained, along with file create/modify timestamps and > FID; the FID is only meaningful on a given logical drive unit so the > drive name needs to be retained also, unmasked from any logicals. > > The auditors are (as expected) well trained in suboptimal operating > systems like windows, but are not VMS-aware. Providing basic VMS file > specification information is not a problem but avoiding potentially > confusing variants such as paths with the embedded ][ is just a good > thing to do. Normalizing the stored pathnames also makes later > comparison and parsing more efficient and less likely to generate a > 'false positive' path change event. > > The auditors may never see the actual database. They will see a > report generated comparing the current 'state' of the system against > the archived state recorded in the database. The pathnames in that > report will come from one or the other (or both) locations when an > exception is noted. ------------------------------ Date: Sun, 20 Apr 2008 21:46:00 -0700 (PDT) From: AEF Subject: Re: Divining the full pathname of a file, all logicals translated Message-ID: On Apr 14, 11:40 am, Rich Jordan wrote: > On Apr 11, 10:01 pm, AEF wrote: > > > > > On Mar 24, 4:27 pm, Rich Jordan wrote: > > [...] > > > > OBTW the comment about people unfamiliar with VMS syntax; I expect > > > they'd know enough about dev:[dir1.dir2.dir3]file.name to be able to > > > follow it since we'd be telling them. I'd prefer not to give them > > > variances that might be confusing (extra "][" and missing ".") so it > > > makes sense to use the most basic and consistent syntax in the stored > > > information. > > > > Thanks! > > > > Rich > > > Please, what are you trying to do? What is the purpose of this list? > > What are the users looking for when they use this list? What are they > > going to do with the file-spec when they find the one they want? Are > > they expected to retrieve the file from disk or tape? If so, why do > > they need the list? And how are they going to do anything with it if > > they don't have even a clue as to VMS file-specs? Etc. > > > My apologies if I'm missing something obvious, but I have no clue as > > to what the point of all this is. > > > If the OP is not following this thread anymore, I' asking anyone else > > who is to explain to me what the whole point of this is. > > > As usual, without the original motivation it is difficult to come up > > with reasonably "optimized" (for lack of a better word I can't think > > of offhand) solution. > > > Thanks! > > > AEF > > Auditing changes to or moves of designated files for compliance to > certain government regulations. > > A physical change of location (hidden by logicals) is still an > auditable event requiring documentation. Hence the need to know the So if a disk dies and you restore on another disk, that's auditable? > physical path at the time the audit database is generated, in order to > compare it to the "current" state when an audit report is run. A hash > of each file is retained, along with file create/modify timestamps and > FID; the FID is only meaningful on a given logical drive unit so the > drive name needs to be retained also, unmasked from any logicals. > > The auditors are (as expected) well trained in suboptimal operating > systems like windows, but are not VMS-aware. Providing basic VMS file Ah, so what we have here is auditing by the blind. A few short lessons in VMS seem in order here. Yes, I know, it's not up to you, and you need to do these silly things. And what's to prevent anyone from faking the report? Faking the modification dates, or the disk names? How would they even know you changed disks if your reported had the logical names. Just tell them the logical names are the disk names? How would they know? So these Blind Watchdogs are goind to save us from file manipulation shenanigans. Whatever. > specification information is not a problem but avoiding potentially > confusing variants such as paths with the embedded ][ is just a good > thing to do. Normalizing the stored pathnames also makes later > comparison and parsing more efficient and less likely to generate a > 'false positive' path change event. Tell then the logical names are the disks names and that would be yet more efficient! :-) > > The auditors may never see the actual database. They will see a > report generated comparing the current 'state' of the system against > the archived state recorded in the database. The pathnames in that > report will come from one or the other (or both) locations when an > exception is noted. And how are these Blind Auditors going to know the report is not fudged? Again, I lay no blame upon you. I'm just saying the entire situation seems a bit absurd to me. Thanks for clearing this up. AEF ------------------------------ Date: Sun, 20 Apr 2008 21:59:00 -0700 (PDT) From: AEF Subject: Re: Divining the full pathname of a file, all logicals translated Message-ID: On Apr 14, 11:40 am, Rich Jordan wrote: > On Apr 11, 10:01 pm, AEF wrote: > > > > > On Mar 24, 4:27 pm, Rich Jordan wrote: > > [...] > > > > OBTW the comment about people unfamiliar with VMS syntax; I expect > > > they'd know enough about dev:[dir1.dir2.dir3]file.name to be able to > > > follow it since we'd be telling them. I'd prefer not to give them > > > variances that might be confusing (extra "][" and missing ".") so it > > > makes sense to use the most basic and consistent syntax in the stored > > > information. > > > > Thanks! > > > > Rich > > > Please, what are you trying to do? What is the purpose of this list? > > What are the users looking for when they use this list? What are they > > going to do with the file-spec when they find the one they want? Are > > they expected to retrieve the file from disk or tape? If so, why do > > they need the list? And how are they going to do anything with it if > > they don't have even a clue as to VMS file-specs? Etc. > > > My apologies if I'm missing something obvious, but I have no clue as > > to what the point of all this is. > > > If the OP is not following this thread anymore, I' asking anyone else > > who is to explain to me what the whole point of this is. > > > As usual, without the original motivation it is difficult to come up > > with reasonably "optimized" (for lack of a better word I can't think > > of offhand) solution. > > > Thanks! > > > AEF > > Auditing changes to or moves of designated files for compliance to > certain government regulations. > > A physical change of location (hidden by logicals) is still an > auditable event requiring documentation. Hence the need to know the Say what? What is the point of this? If the files don't change, who gives a f---? What's important is the path via which the files are accessed. If they're accessed from logical_name:[*...] then all that counts is if files under that set of paths changes or not. What possible difference could changing the physical disk make, and if you move to another disk, just document that. "I moved the files from disk A to disk B and they are still under logical name C." THAT would be EFFICIENT! You can still compare the files and run a new report and comparing reports and files (or hashes or whatever) would be easier and more efficient. What is the objections to a scheme like this? > physical path at the time the audit database is generated, in order to > compare it to the "current" state when an audit report is run. A hash > of each file is retained, along with file create/modify timestamps and > FID; the FID is only meaningful on a given logical drive unit so the > drive name needs to be retained also, unmasked from any logicals. What is the point of the FID unless the files are actually accessed via it? This whole thing seems needlessly complicated and taken to the level at which there are more important problems of trust to worry about. Again, I'm not blaming you for any of this. Thanks for clearing up the motivation of all this. AEF UPPERCASE AND PROUD OF IT! > > The auditors are (as expected) well trained in suboptimal operating > systems like windows, but are not VMS-aware. Providing basic VMS file > specification information is not a problem but avoiding potentially > confusing variants such as paths with the embedded ][ is just a good > thing to do. Normalizing the stored pathnames also makes later > comparison and parsing more efficient and less likely to generate a > 'false positive' path change event. > > The auditors may never see the actual database. They will see a > report generated comparing the current 'state' of the system against > the archived state recorded in the database. The pathnames in that > report will come from one or the other (or both) locations when an > exception is noted. ------------------------------ Date: Sun, 20 Apr 2008 16:40:55 -0500 From: Muddflapp Mohican Subject: HSD52 dead reduced raidset Message-ID: Hi. I have a dual redundant hsd50 controller (SCSI over DSSI). One of the storagesets was a 4 x 18GB raidset that went into reduced mode. There was not a large enough hot (or cold) spare available at the time. When I replaced the 4th drive, one of the remaining 3 drives was howling and spun down before the 4th drive could be added. Is there a secret HSD toolset that can resurrect a dead reduced raidset? All 3 drives of the 4 disk reduced raidset will spin up. The third drive will only stay spinning until it gets hot and starts howling. I have replaced the 4th 18G drive and currently sits as a spareset. The controller runs HSOF 5.7 under OpenVMS VAX V6.2 ------------------------------ Date: Sun, 20 Apr 2008 20:10:18 -0400 From: "Richard B. Gilbert" Subject: Re: HSD52 dead reduced raidset Message-ID: Muddflapp Mohican wrote: > > Hi. > > I have a dual redundant hsd50 controller (SCSI over DSSI). > One of the storagesets was a 4 x 18GB raidset that went into reduced mode. > There was not a large enough hot (or cold) spare available at the time. > When I replaced the 4th drive, one of the remaining 3 drives was howling > and spun down before the 4th drive could be added. > > Is there a secret HSD toolset that can resurrect a dead reduced raidset? YES! It's called BACKUP. *SOME* RAID configurations will protect you against loss of data caused by the failure of a single disk drive. No RAID configuration is, in any way, a substitute for regular disk backups! I have this uneasy feeling that you neglected to make regular backups. If I'm right, lots of luck in looking for a new job! I might add that there is much to be said for having both hot spares and cold spares. If all your drives are the same size, one spare may be enough. If not, the problem gets a little messier. ------------------------------ Date: Sun, 20 Apr 2008 15:13:47 -0400 From: JF Mezei Subject: Re: Intel Itanium RAS Comparison with X86 Message-ID: <480b9606$0$7273$c3e8da3@news.astraweb.com> Main, Kerry wrote: >> > Slightly different versions of RAS are kicking around: >> > 1. RAS =3D reliability, availability, serviceability (most common) >> > 2. RAS =3D reliability, availability, scalability >> > >> > Fwiw, I like to refer to RASS which is 1. Or 2. + Security To me, RAS is marketing hype. I think that the motherboard/system design has far more to do with "RAS" than the chip itself. > DOD certainly is a big OpenVMS Customer. Whether you believe or not > is up to you. Not everyone buys into the hype technology of the day. It may not have anything to do about "buying hype technology of the day". It may be more to do with some VMS customers stuck with VMS because porting their apps would just cost too much. If you need to recertify sopme application and this costs in the millions, they are better off continuing those old apps on VMS as long as possible. But you must ask yoursefl whetther the new apps are going to VMS or of they are going to modern platforms. > Yeah, and let me guess - the people saying this are under 30 (maybe 35) > and are promoting platforms like Windows and Linux that have 5-20 security > patches released each and every month. And that does not include the > fixes auctioned off privately at sites like this: Oh, this is so easy to reply to.... 1- People under 30 (maybe 35) don't know about VMS, why ??? BECAUSE OF LACK OF MARKETING. When will it ever sink into the VMS management/engineering heads that widespread marketing IS IMPORTANT not because it will drive sales up in mom-pop shops, but because it will gets into the mindset of the very people who don't know about VMS now and may consider it. 2- Read a really good interview some time ago with the head of the mozilla project. She said that real security people don't compare products (in that case firefox vs Internet Explorer) by the count of patches, but rather by the length of time a known vulnerability exists before it is patched. If I were you, I would stop using that patch analogy. Consider that VMS has had known security vulnerabilities for years now in its TCPIP product. No patches in sight. For modern platforms with real development resources, security vulnerabilities are measured in days/weeks before the patch is available. For VMS, we don't even know if they will ever be fixed. Sorry, but that is a real sign to me that development resources have been reduced to a bare minimum. If HP chooses to actively ignore what is being said in comp.os.vms, it is its decision. But if as a result of this, they also ignore serious descriptions of security vulnerabilities, then the resposability falls back on HP. ------------------------------ Date: Sun, 20 Apr 2008 15:26:51 -0400 From: bradhamilton Subject: Re: Intel Itanium RAS Comparison with X86 Message-ID: <480B98FB.4070906@comcast.net> Bill Gunshannon wrote: [...] > > On a side note, I am once again serving with DOD (til mid August > this time) and we constantly hear the talk of "99.999% uptime > required" and "critical systems with lives depending on them". > And not a sign or mention of VMS anywhere, go figure. :-) > > Somebody tell me again how DOD is one of VMS's biggest customers! OK, but permit me to turn the question around a little bit: With the uptime and life-saving requirements listed above, how does Windows accomplish these goals? I realize that you can't go into detail without killing me :-) but there must be general principles and rules that illustrate the stability of Windows in these critical environments. The reason I ask is because of a similar situation that I see in the healthcare field. Many of you are probably acquainted with GE Healthcare systems. You may have seen their logo on MRI or CAT scan equipment, and there are other devices that they manufacture, as well. Since these are critical clinical systems, they have strict uptime and reliability requirements as well, since people's lives may depend on the information they render. I work on the "business" side of the healthcare industry, and we too, have a system manufactured by GE. Luckily, our system is not clinical but accounting-oriented. It's Windows-based, and a POS. M$ SQL is used as the DB holding the information, and as often as not the information is not available, slow in coming, or occasionally corrupted in some fashion. Never mind the fact that our client PC's, which access the server, suffer from the usual maladies common to the Windows platform. I sure hope that the DoD systems are indeed more reliable than their civilian counterparts. :-) > bill > ------------------------------ Date: Sun, 20 Apr 2008 15:50:04 -0400 From: JF Mezei Subject: Re: Intel Itanium RAS Comparison with X86 Message-ID: <480b9ea7$0$12317$c3e8da3@news.astraweb.com> bradhamilton wrote: > I sure hope that the DoD systems are indeed more reliable than their > civilian counterparts. :-) To the disbelief of the rest of the world, in 2004, the american public re-elected a government who killed over 100,000 innocent iraqis. Politically, precision is only important prior to the attack when politicians brag about high tech weapons who will only destroy specific targets and not kill any innocent civilians. Once the attack has commenced, control of the USA media ensures that all the system problems that result in loss of civilian life are not reported, so politicans get away with in in the USA. And in reality, the application is far more important than the operating system. And having experienced people who know the strengths and weakenesses of the OS will result in an application that is robust and stable. ------------------------------ Date: 20 Apr 2008 23:06:43 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Intel Itanium RAS Comparison with X86 Message-ID: <6720k3F2lem77U1@mid.individual.net> In article , "Main, Kerry" writes: > >> -----Original Message----- >> From: Bill Gunshannon [mailto:billg999@cs.uofs.edu] >> Sent: April 20, 2008 12:18 PM >> To: Info-VAX@Mvb.Saic.Com >> Subject: Re: Intel Itanium RAS Comparison with X86 >> >> In article >> > t>, >> "Main, Kerry" writes: >> > >> >> -----Original Message----- >> >> From: P. Sture [mailto:paul.sture.nospam@hispeed.ch] >> >> Sent: April 20, 2008 5:23 AM >> >> To: Info-VAX@Mvb.Saic.Com >> >> Subject: Re: Intel Itanium RAS Comparison with X86 >> >> >> >> In article , >> >> "Tom Linden" wrote: >> >> >> >> > On Fri, 18 Apr 2008 16:02:41 -0700, Main, Kerry >> >> >> wrote: >> >> > >> >> > I know it isn't Row Address Strobe. Usually I can decode the >> acronym >> >> > from the context, but this one has me stumped, guess I am getting >> >> dumb. >> >> > >> >> > " >> >> > Mainframe-Class RAS in the Processor >> >> > The Intel Itanium processor was designed from its inception to >> >> > deliver mainframe-class availability. It incorporates leading RAS >> >> > capabilities for detecting, correcting and containing the kinds of >> >> > unavoidable hard and soft errors that can bring down systems or >> >> > corrupt data (Table 1 on next page). >> >> > " >> >> > >> >> > I discovered I couldn't cut and paste the above quote from Opera, >> but >> >> > Firefox let me, FWIW. >> >> >> >> I'm 99% sure they are referring to this meaning of RAS (and not >> Remote >> >> Access Server): >> >> >> >> >> >> >> >> "Reliability, Availability, and Serviceability for the Always-on >> >> Enterprise" >> >> >> >> -- >> >> Paul Sture >> >> >> >> Sue's OpenVMS bookmarks: >> >> http://eisner.encompasserve.org/~sture/ovms-bookmarks.html >> > >> > Slightly different versions of RAS are kicking around: >> > 1. RAS =3D3D reliability, availability, serviceability (most common) >> > 2. RAS =3D3D reliability, availability, scalability >> > >> > Fwiw, I like to refer to RASS which is 1. Or 2. + Security >> >> On a side note, I am once again serving with DOD (til mid August >> this time) and we constantly hear the talk of "99.999% uptime >> required" and "critical systems with lives depending on them". >> And not a sign or mention of VMS anywhere, go figure. :-) >> >> Somebody tell me again how DOD is one of VMS's biggest customers! > > DOD certainly is a big OpenVMS Customer. Whether you believe or not > is up to you. Not everyone buys into the hype technology of the day. Belief has nothing to do with it. When one works in the DOD environment and can point to only one project still using VMS and that after more than 3 years of actually searching, just how big a customer can they be? When you work for the agency responsible for validating information systems within DOD and that agencty does not even have a procedure for validating VMS systems but treats each one as a unique and exceptional case, you draw the conclusion. > > > Yeah, and let me guess - the people saying this are under 30 (maybe 35) No, actually my peers alone range in age from their 20's to nearly 60. The people making policy tend to be at the higher end of the spectrum. > and are promoting platforms like Windows and Linux that have 5-20 security > patches released each and every month. And that does not include the > fixes auctioned off privately at sites like this: > > http://www.darkreading.com/document.asp?doc_id=3D128411&WT.svl=3Dnews1_1 You really are a "one hit wonder". Can't get off this and can't seem to grasp the concept that there are perfectly secure Windows systems in use all over. And we all know the rate at which Linux is growing. Seems the only system conspicuous in its absence in the industry today is VMS. > > I'll bet the bad guys from other countries are loving these under > 30 types. Not sure where you found these supposed "under 30 types" but they sure aren't the guys I work with in DOD every day. (For those of you who are used to me being just someone in a University CS department and having a hard time understanding where I am coming from, I am currently back on active duty with the Army again for a while and at the place responsible for all Army, and quite a bit of other DOD groups, IT training, so I am not just wearing, or talking thru my academic hat!!) :-) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 20 Apr 2008 23:14:13 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Intel Itanium RAS Comparison with X86 Message-ID: <672125F2lem77U2@mid.individual.net> In article , "Tom Linden" writes: > On Sun, 20 Apr 2008 09:17:53 -0700, Bill Gunshannon > wrote: > >> Somebody tell me again how DOD is one of VMS's biggest customers! > > Well, they are my biggest! Well, you'll pardon me for saying this but if DOD VMS PL/I users make up the majority of your business your a lot smaller than I thought. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Sun, 20 Apr 2008 19:47:06 -0400 From: "Richard B. Gilbert" Subject: Re: Intel Itanium RAS Comparison with X86 Message-ID: JF Mezei wrote: > Main, Kerry wrote: > >>>> Slightly different versions of RAS are kicking around: >>>> 1. RAS =3D reliability, availability, serviceability (most common) >>>> 2. RAS =3D reliability, availability, scalability >>>> >>>> Fwiw, I like to refer to RASS which is 1. Or 2. + Security > > > To me, RAS is marketing hype. I think that the motherboard/system design > has far more to do with "RAS" than the chip itself. > > >> DOD certainly is a big OpenVMS Customer. Whether you believe or not >> is up to you. Not everyone buys into the hype technology of the day. > > It may not have anything to do about "buying hype technology of the > day". It may be more to do with some VMS customers stuck with VMS > because porting their apps would just cost too much. If you need to > recertify sopme application and this costs in the millions, they are > better off continuing those old apps on VMS as long as possible. But you > must ask yoursefl whetther the new apps are going to VMS or of they are > going to modern platforms. > > >> Yeah, and let me guess - the people saying this are under 30 (maybe 35) >> and are promoting platforms like Windows and Linux that have 5-20 security >> patches released each and every month. And that does not include the >> fixes auctioned off privately at sites like this: > > > Oh, this is so easy to reply to.... > > 1- People under 30 (maybe 35) don't know about VMS, why ??? BECAUSE OF > LACK OF MARKETING. When will it ever sink into the VMS > management/engineering heads that widespread marketing IS IMPORTANT not > because it will drive sales up in mom-pop shops, but because it will > gets into the mindset of the very people who don't know about VMS now > and may consider it. > Marketing is important only if you want to sell the product! HP doesn't want to market VMS. I think they just wish it would go away quietly!! ------------------------------ Date: Sun, 20 Apr 2008 19:49:23 -0400 From: JF Mezei Subject: Re: Intel Itanium RAS Comparison with X86 Message-ID: <480bd69e$0$7307$c3e8da3@news.astraweb.com> Bill Gunshannon wrote: > Belief has nothing to do with it. When one works in the DOD > environment and can point to only one project still using VMS > and that after more than 3 years of actually searching, just > how big a customer can they be? That is because of the "I can tell you, but then i'll have to shoot you" policy. Anyone who finds a VMS application is immediatly shot :-) VMS is like field mice in a farm. You know they are out there, but you can never actually find one. :-) :-) All part of VMS' decades long stealth marketing. Of course, with cats (linux/windows) prowling, the number of mice is decreasing and nobody is doing anything about it. And since you don't know the number of mice around, you can't quantify the loss of mice and how many there are left. ------------------------------ Date: 20 Apr 2008 23:59:38 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Intel Itanium RAS Comparison with X86 Message-ID: <6723n9F2m5d48U1@mid.individual.net> In article <480B98FB.4070906@comcast.net>, bradhamilton writes: > Bill Gunshannon wrote: > [...] >> >> On a side note, I am once again serving with DOD (til mid August >> this time) and we constantly hear the talk of "99.999% uptime >> required" and "critical systems with lives depending on them". >> And not a sign or mention of VMS anywhere, go figure. :-) >> >> Somebody tell me again how DOD is one of VMS's biggest customers! > > OK, but permit me to turn the question around a little bit: > > With the uptime and life-saving requirements listed above, how does > Windows accomplish these goals? I keep trying, but most people here are just not willing to accept the possibility even when it is shoved down their throats. > I realize that you can't go into detail > without killing me :-) Of course I can. a lot of the information is publicly available. As a matter of fact, organizations like DISA, NIST and even the NSA would really like to see more people actualy follow the guidelines. > but there must be general principles and rules > that illustrate the stability of Windows in these critical environments. > http://iase.disa.mil/stigs/index.html I apply a lot of this on the systems I manage at the University. I tend to be a bit less draconian in the University environment than what I do on DOD systems but even that has made the systems secure, stable and reliable without adversely affecting the users ability to do what they need to do. > The reason I ask is because of a similar situation that I see in the > healthcare field. Many of you are probably acquainted with GE > Healthcare systems. You may have seen their logo on MRI or CAT scan > equipment, and there are other devices that they manufacture, as well. > Since these are critical clinical systems, they have strict uptime and > reliability requirements as well, since people's lives may depend on the > information they render. And, considering that these machines are intended for one specific use and are not general purpose PC's, I would expect that the more draconian settings would be both acceptable and appropriate. I would be willing to bet that the the PC's that run systems like this are more often than not set up no different than the average home system. > > I work on the "business" side of the healthcare industry, and we too, > have a system manufactured by GE. Luckily, our system is not clinical > but accounting-oriented. It's Windows-based, and a POS. M$ SQL is used > as the DB holding the information, and as often as not the information > is not available, slow in coming, or occasionally corrupted in some > fashion. Never mind the fact that our client PC's, which access the > server, suffer from the usual maladies common to the Windows platform. If politics doesn't get in the way, start applying the guidelines you will find at the web site I posted above and see the difference. Of course, your users may start complaining about not being able to install that really cool screensaver they found on the web. And they may start asking why they can't find the Control Panel but that's just the price you have to pay. :-) > > I sure hope that the DoD systems are indeed more reliable than their > civilian counterparts. :-) The DOD systems are just fine. But then, as much as people here refuse to accept it, so are the systems in my civilian job. :-) Not a single virus since Windows98 days. No BSOD that wasn't hardware related since early Win2K. No problems at all on Server versions. But nobody is going to take my word for it cause it's much more fun to bash MS than to just fix things. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: 21 Apr 2008 00:13:37 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Intel Itanium RAS Comparison with X86 Message-ID: <6724hhF2m5d48U2@mid.individual.net> In article <480bd69e$0$7307$c3e8da3@news.astraweb.com>, JF Mezei writes: > Bill Gunshannon wrote: > >> Belief has nothing to do with it. When one works in the DOD >> environment and can point to only one project still using VMS >> and that after more than 3 years of actually searching, just >> how big a customer can they be? > > That is because of the "I can tell you, but then i'll have to shoot you" > policy. Anyone who finds a VMS application is immediatly shot :-) More bullcrap. The one system I found was thru a publicly posted job vacancy announcement. It was for a Fortran programmer with VMS experience. A legacy simulation system. What does that sound like? Maintenance or development? Or maybe, a conversion? bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Sun, 20 Apr 2008 20:27:00 -0400 From: bradhamilton Subject: Re: Intel Itanium RAS Comparison with X86 Message-ID: <480BDF54.3090103@comcast.net> Bill Gunshannon wrote: > In article <480B98FB.4070906@comcast.net>, > bradhamilton writes: [...] >> I realize that you can't go into detail >> without killing me :-) > > Of course I can. a lot of the information is publicly available. As > a matter of fact, organizations like DISA, NIST and even the NSA would > really like to see more people actualy follow the guidelines. > >> but there must be general principles and rules >> that illustrate the stability of Windows in these critical environments. >> > > http://iase.disa.mil/stigs/index.html Thanks! Just to get this back OT :-) there's a OpenVMS checklist document there. Of course, the doc is two years old, and only covers VMS up to V7.3-N, but I suppose that means that VMS exists in DoD, perhaps just not as visibly as other platforms. :-) > I apply a lot of this on the systems I manage at the University. I tend > to be a bit less draconian in the University environment than what I do > on DOD systems but even that has made the systems secure, stable and > reliable without adversely affecting the users ability to do what they > need to do. > >> The reason I ask is because of a similar situation that I see in the >> healthcare field. Many of you are probably acquainted with GE >> Healthcare systems. You may have seen their logo on MRI or CAT scan >> equipment, and there are other devices that they manufacture, as well. >> Since these are critical clinical systems, they have strict uptime and >> reliability requirements as well, since people's lives may depend on the >> information they render. > > And, considering that these machines are intended for one specific > use and are not general purpose PC's, I would expect that the more > draconian settings would be both acceptable and appropriate. I > would be willing to bet that the the PC's that run systems like this > are more often than not set up no different than the average home > system. Most average "home" systems are "set up" with the defaults, which means "wide open". I would expect (and hope) that any Windows system in a hospital, especially those tasked with critical clinical functions or monitoring, would be as locked-down as possible. >> I work on the "business" side of the healthcare industry, and we too, >> have a system manufactured by GE. Luckily, our system is not clinical >> but accounting-oriented. It's Windows-based, and a POS. M$ SQL is used >> as the DB holding the information, and as often as not the information >> is not available, slow in coming, or occasionally corrupted in some >> fashion. Never mind the fact that our client PC's, which access the >> server, suffer from the usual maladies common to the Windows platform. > > If politics doesn't get in the way, start applying the guidelines you will > find at the web site I posted above and see the difference. Of course, > your users may start complaining about not being able to install that > really cool screensaver they found on the web. And they may start asking > why they can't find the Control Panel but that's just the price you have > to pay. :-) Politics, no. I would get the former question a lot more frequently than the latter question. :-) >> I sure hope that the DoD systems are indeed more reliable than their >> civilian counterparts. :-) > > The DOD systems are just fine. But then, as much as people here refuse > to accept it, so are the systems in my civilian job. :-) Not a single > virus since Windows98 days. No BSOD that wasn't hardware related since > early Win2K. No problems at all on Server versions. But nobody is > going to take my word for it cause it's much more fun to bash MS than > to just fix things. Since M$ is so ubiquitous (and Intel HW almost as) it would behoove most of us to know how to secure these systems, whether the platform be Windows or Linux. Years ago, I could turn up my nose at non-VMS systems; these days, anything that pays the bills will do. I even reboot my W2K PC at work regularly, because the applications work faster and better when I do so. It would be nice to have newer, more reliable systems, but I'll do the best with what I have. ------------------------------ Date: 21 Apr 2008 01:47:05 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: Intel Itanium RAS Comparison with X86 Message-ID: <672a0pF2mgbtnU1@mid.individual.net> In article <480BDF54.3090103@comcast.net>, bradhamilton writes: > Bill Gunshannon wrote: >> In article <480B98FB.4070906@comcast.net>, >> bradhamilton writes: > [...] >>> I realize that you can't go into detail >>> without killing me :-) >> >> Of course I can. a lot of the information is publicly available. As >> a matter of fact, organizations like DISA, NIST and even the NSA would >> really like to see more people actualy follow the guidelines. >> >>> but there must be general principles and rules >>> that illustrate the stability of Windows in these critical environments. >>> >> >> http://iase.disa.mil/stigs/index.html > > Thanks! Just to get this back OT :-) there's a OpenVMS checklist > document there. Of course, the doc is two years old, and only covers > VMS up to V7.3-N, but I suppose that means that VMS exists in DoD, > perhaps just not as visibly as other platforms. :-) Actually, I think what it says is that there was a time when VMS was popular enough in DOD that the effort needed to create and test those was considered necessary. Which also says something about the fact that they are not being kept up to date. > >> I apply a lot of this on the systems I manage at the University. I tend >> to be a bit less draconian in the University environment than what I do >> on DOD systems but even that has made the systems secure, stable and >> reliable without adversely affecting the users ability to do what they >> need to do. >> >>> The reason I ask is because of a similar situation that I see in the >>> healthcare field. Many of you are probably acquainted with GE >>> Healthcare systems. You may have seen their logo on MRI or CAT scan >>> equipment, and there are other devices that they manufacture, as well. >>> Since these are critical clinical systems, they have strict uptime and >>> reliability requirements as well, since people's lives may depend on the >>> information they render. >> >> And, considering that these machines are intended for one specific >> use and are not general purpose PC's, I would expect that the more >> draconian settings would be both acceptable and appropriate. I >> would be willing to bet that the the PC's that run systems like this >> are more often than not set up no different than the average home >> system. > > Most average "home" systems are "set up" with the defaults, which means > "wide open". I would expect (and hope) that any Windows system in a > hospital, especially those tasked with critical clinical functions or > monitoring, would be as locked-down as possible. I would too, but everyone else here seems to insist that they are not. I only point out that they can be. > >>> I work on the "business" side of the healthcare industry, and we too, >>> have a system manufactured by GE. Luckily, our system is not clinical >>> but accounting-oriented. It's Windows-based, and a POS. M$ SQL is used >>> as the DB holding the information, and as often as not the information >>> is not available, slow in coming, or occasionally corrupted in some >>> fashion. Never mind the fact that our client PC's, which access the >>> server, suffer from the usual maladies common to the Windows platform. >> >> If politics doesn't get in the way, start applying the guidelines you will >> find at the web site I posted above and see the difference. Of course, >> your users may start complaining about not being able to install that >> really cool screensaver they found on the web. And they may start asking >> why they can't find the Control Panel but that's just the price you have >> to pay. :-) > > Politics, no. > > I would get the former question a lot more frequently than the latter > question. :-) > >>> I sure hope that the DoD systems are indeed more reliable than their >>> civilian counterparts. :-) >> >> The DOD systems are just fine. But then, as much as people here refuse >> to accept it, so are the systems in my civilian job. :-) Not a single >> virus since Windows98 days. No BSOD that wasn't hardware related since >> early Win2K. No problems at all on Server versions. But nobody is >> going to take my word for it cause it's much more fun to bash MS than >> to just fix things. > > Since M$ is so ubiquitous (and Intel HW almost as) it would behoove most > of us to know how to secure these systems, whether the platform be > Windows or Linux. Years ago, I could turn up my nose at non-VMS > systems; these days, anything that pays the bills will do. I even > reboot my W2K PC at work regularly, because the applications work faster > and better when I do so. It would be nice to have newer, more reliable > systems, but I'll do the best with what I have. Believe it or not, you will not only be more secure if you apply the sytuff you will find at DISA but you may also find the systems more stable and running better. It has somewhat to do with all the extra crap that Wndows runs by default that is totally unnecessary and is eliminated by the scripts. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Sun, 20 Apr 2008 19:56:21 -0700 From: "Tom Linden" Subject: Re: Intel Itanium RAS Comparison with X86 Message-ID: On Sun, 20 Apr 2008 16:14:13 -0700, Bill Gunshannon wrote: > In article , > "Tom Linden" writes: >> On Sun, 20 Apr 2008 09:17:53 -0700, Bill Gunshannon >> >> wrote: >> >>> Somebody tell me again how DOD is one of VMS's biggest customers! >> >> Well, they are my biggest! > > Well, you'll pardon me for saying this but if DOD VMS PL/I users make up > the majority of your business your a lot smaller than I thought. > > bill > I didn't say majority, I said biggest -- PL/I for OpenVMS www.kednos.com ------------------------------ Date: Sun, 20 Apr 2008 16:52:55 -0500 From: Muddflapp Mohican Subject: Max drive size for HSZ22 ? Message-ID: Hi. I have an AlphaServer 4100 running OpenVMS Alpha 7.3 connected to an dual redundant HSZ22. I don't know how to tell what the controller version number might be. I have to use a PC with two serial cables and run an old DEC program to be able to make changes to the controller. What is the largest disk size and largest raidset size that will work with the HSZ22 ? P.S. I can use a 300GB disk inside the SBB, but the SBB is connected to a "normal" scsi controller on the Alpha and not the HSZ22. I know that the maximum disk size for an HSD50 (HSO5 5.7) (scsi to dssi) controller will support 36G. Using 73G disks causes two devices to show up under OpenVMS VAX V6.2 (Dua17 & Dka17) I know that on a VAXstation 4000-96 running OpenVMS VAX V6.2 with upto date patches will support a directly connected drive maximum size of 36GB. Connecting a 73GB disk directly to this will actually mount and read data but as soon as you INIT, Create/Dir, or Create file, the system crashes unless your running a new OS Version. ------------------------------ Date: Sun, 20 Apr 2008 20:18:41 -0400 From: "Richard B. Gilbert" Subject: Re: Max drive size for HSZ22 ? Message-ID: Muddflapp Mohican wrote: > > Hi. > > I have an AlphaServer 4100 running OpenVMS Alpha 7.3 connected to an dual > redundant HSZ22. I don't know how to tell what the controller version > number > might be. Try "SHOW THIS" and "SHOW OTHER" both SHOULD be at the same firmware rev. ------------------------------ Date: 20 Apr 2008 21:01:11 GMT From: billg999@cs.uofs.edu (Bill Gunshannon) Subject: Re: OT: IBM looking at Macintosh Message-ID: <671p8nF2mc9e8U1@mid.individual.net> In article , "Tom Linden" writes: > On Sun, 20 Apr 2008 09:12:26 -0700, Bill Gunshannon > wrote: > >> IBM supports lots of different OSes. They have never bought any of them. >> IBM owns the OSes it created. I am aware of no OS currently owned by IBM >> that originated in some other company. Add to that the fact that IBM >> shows >> no sign of porting any of their current non-OS software, like DB2, to >> VMS. >> Thye are willing to support (and have the resources to support) other >> people's products in order to keep their customers happy, but that does >> not mean they are going to buy something like VMS to save it. Much more >> likely that they will have their salesmen spend the needed additional >> time >> with the customer pointing out the direction VMS is headed and pushing >> them >> to port to an all IBM solution. That's called marketing. > > The only reason IBM would buy OpenVMS would be for the customer base, but > that opportunity disappeared ca. 1992. Which is kinda the point I was trying to get accross. Every couple of weeks we see these messages implying that somehow, IBM is going to come riding in on big white horse to save the day. It just ain't gonna happen. Even if (and I don't think there is a snowballs chance in hell of it happening) IBM were to buy VMS it would likely be, as stated above, strictly for the customer bnase (if there actually was one) and it would mark the end of the product just as surely as HO is doing now. This subject always reminds me of the place in "Jesus Christ, Superstar" where Judas sings, "You know what your supporters feel, You'll escape in the final reel." Of course, everyone knows He didn't. :-) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include ------------------------------ Date: Sun, 20 Apr 2008 18:13:19 -0400 From: JF Mezei Subject: Re: OT: IBM looking at Macintosh Message-ID: <480bc01c$0$7276$c3e8da3@news.astraweb.com> Bill Gunshannon wrote: > Which is kinda the point I was trying to get accross. Every couple of weeks > we see these messages implying that somehow, IBM is going to come riding in > on big white horse to save the day. It just ain't gonna happen. When Compaq bought Digital, Pfeiffer had given much hope Compaq would leverage Alpha and VMS. Then Pfeiffer was ousted and Curly set out to complete Palmer's job. Then comes HP, and there was some HP that HP, having more experience with enterprise systems, might do something good with VMS (especially since HP initially had a vested interest in making that IA64 contraption succesful). It fairly quickly became apparent that this wasn't to be the case. Then Carly was ousted, and this "solid" Hurd fellow comes in, and again, there is hope that his reorganisations and leadership might give VMS another chance, and that Hurd might have no problem killing off IA64 since it wasn't his puppy. But this hasn't happened. Last summer, the news that HP is happy with Cerner abandonning VMS, and the fact that HP calculators got way more exposure for their birthday than the token exposure VMS got. (and that happened only after we complained nothing had been done by HP, not even a press release. HP is a solid company with plenty of ink profits to hide the loss of VMS. That was not the case for Digital nor for Compaq. The loss of VMS wouldn't even change HP's financials. HP has no reason to kill VMS at this point in time. But the minute it no longer makes money, the plug will be pulled. At that point, HP will be able to point to decades of decline in VMS and declare that the corpse is to far gone to resurrect (and correctly so). HP isn't about to sell VMS, because it still generates support revenus. And since HP is competing for #1 spot in support against IBM, HP would not sell VMS to IBM since it would cause HP to lose some support revenus and IBM to gain some. Furthermore, HP is the only one with an economic interest in that Itanium thing. IBM wouldn't be interested in some OS tied to a sinking ship. Consider that even within the VMS group, we've often seen the arguments that "we don't need to upgade VAX-VMS because customers aren't interested in upgrades". Won't be long before they start doing this to Alpha, after which, they can just argue that the number of IA64 customers is too small to justify firther upgrades. (unless IA64 is put ouf of its misery beforehand). This is it guys. There is really no way out of this. The writing is on the wall. The train is approaching the end of the line, but it is going so slowly that when it will hit that "derail" block at the end, it won't make any noise and nobody will really notice. ------------------------------ Date: Sun, 20 Apr 2008 21:38:45 -0700 (PDT) From: AEF Subject: Re: OT: IBM looking at Macintosh Message-ID: <37cd94d6-bdac-47ad-9df7-b9bcac212888@59g2000hsb.googlegroups.com> On Apr 20, 12:12 pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote: > In article , > AEF writes: > > > > > On Apr 19, 12:05 pm, billg...@cs.uofs.edu (Bill Gunshannon) wrote: > >> In article <$yqIL4$wm...@eisner.encompasserve.org>, > >> koeh...@eisner.nospam.encompasserve.org (Bob Koehler) writes: > > >> > In article <66q19aF2ks2a...@mid.individual.net>, billg...@cs.uofs.edu (Bill Gunshannon) writes: > > >> >> What could possibly make IBM want to do anything at all with VMS? > > >> > IBM knows good stuff when they see it. And they know how to market. > > >> And? Has IBM ever expressed an interest in being the owner of VMS? > >> I didn't think so. > > >> And, of course, even if they did, the point still remains that VMS is not > >> now and probably never will be for sale. > > >> bill > > >> -- > >> Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves > >> billg...@cs.scranton.edu | and a sheep voting on what's for dinner. > >> University of Scranton | > >> Scranton, Pennsylvania | #include > > > C'mon, Bill, be fair. The question wasn't whether IBM was likely or > > interested in VMS. The question was > > Actually, the original statement was, "It would be a hoot if IBM started > to port all its software to VMS", which is once again this stranger notion > that IBM, "despite HP's best efforts in the other direction" was going > to come along and save VMS. Reality time, people, VMS's fate lies in I meant the original statement that Bob Koehler was answering. So it's still apples and oranges on your side. I make no comment on your comments except that you unfairly attack Bob's answer by assuming he was addressing some other question. If this is still not clear to you -- okay, maybe you're just pushing my buttons. Fine. I'm done. AEF -- UPPERCASE AND PROUD OF IT! > the hands of HP alone. IBM isn't going to save it. Unisys isn't going > to save it. No one is going to ride up at the last minute to save it. > It's up to HP and we already know what their direction is. > > > > > > >> >> What could possibly make IBM want to do anything at all with VMS? > > > and the answer was quite appropriate. As you say, that is apparently > > not enough for them to show interest, and your last point, while it > > may well be true, does not invalid Bob's answer in the least. So I'm > > not saying your points are wrong. I'm just saying that Bob's answer > > was a good answer. Now if the question were, instead, > > > "What would be enough for IBM to actually attempt a purchase of VMS?" > > > then your criticisms would be quite appropriate. But that wasn't the > > question. The fact that IBM apparently does support at least some VMS > > installations means that it already does have something to do with > > VMS. So the premise of the (original) question isn't even right in the > > first place. > > IBM supports lots of different OSes. They have never bought any of them. > IBM owns the OSes it created. I am aware of no OS currently owned by IBM > that originated in some other company. Add to that the fact that IBM shows > no sign of porting any of their current non-OS software, like DB2, to VMS. > Thye are willing to support (and have the resources to support) other > people's products in order to keep their customers happy, but that does > not mean they are going to buy something like VMS to save it. Much more > likely that they will have their salesmen spend the needed additional time > with the customer pointing out the direction VMS is headed and pushing them > to port to an all IBM solution. That's called marketing. > > > AEF UPPERCASE AND PROUD OF IT! > > You could always buy a new keyboard where the capslock wasn't stuck. > I know of no ne who actually writes in all caps, although ee cummings > dir write in all lowercase. :-) > > bill > > -- > Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves > billg...@cs.scranton.edu | and a sheep voting on what's for dinner. > University of Scranton | > Scranton, Pennsylvania | #include ------------------------------ Date: Mon, 21 Apr 2008 00:50:45 -0400 From: JF Mezei Subject: Re: OT: IBM looking at Macintosh Message-ID: <480c1d45$0$7265$c3e8da3@news.astraweb.com> AEF wrote: >> > AEF UPPERCASE AND PROUD OF IT! Warning: see a doctor immediatly if you stay in uppercase for more than 4 hours at a time. ------------------------------ Date: Sun, 20 Apr 2008 13:24:49 -0700 (PDT) From: "nnc@eta.chalmers.se" Subject: Re: Question on fast SCSI interface for Q-22. Message-ID: <09063c4a-f6df-4923-8f6e-f3a8459a700b@a70g2000hsh.googlegroups.com> On Apr 17, 2:55 am, Chris Scheers wrote: > n...@eta.chalmers.se wrote: > > I'd like your "educated opinions" upon which SCSI-adapter that would > > be "the fastest" for the Q-22 bus... > > > I've seen some indications that CMD's CQD 440 would be a candidate, > > but on "bitsavers", I can only find a manual for CQD 420. What would > > be the difference upon these two? I guess CQD 220 is slower? > > > Reason for my questions: I've been given (privately) a Compaq HSZ-80 > > storage array, and it would be quite amusing to have a PDP (11/93) > > entirely hooked up on this (besides an old alpha-station etc). > > > This storage is connecting using "Ultra SCSI-II" on > > "Differential" (HVD) signalling, so diff (HVD) is sort of a > > requirement of mine for the Q-bus interface I could spend some hobby > > money upon getting this hardware, but as all hobby budgets, there is a > > limit... > > > But, the "greedy" part of mine wants to find out which interface would > > be "the fastest", just for the h... of it! I'm primarilly running RSX > > operating system, but others would be a fun alternative. With the > > storage, I could have plenty of disc partitions for different OS:es! > > > Best regards, G=F6ran =C5 > > It doesn't make any difference. The Q-22 bus is slower than a narrow > async SCSI connection (5MB/sec). > > Use a DWZZA-AA to convert between SE and HVD and off you go. > > -- > ----------------------------------------------------------------------- > Chris Scheers, Applied Synergy, Inc. > > Voice:817-237-3360 Internet: ch...@applied-synergy.com > Fax: 817-237-3074 I'm convinced that it doe's make a difference! Yes, the Q-22 bus set's one bottleneck, but a slow controller to perform MSCP / SCSI "conversion" is also a bottleneck in the same chain of data flow (as a slow disc also would be...). So, my question is if anyone has "real life" throughput figures and/or experience using this or that controller at hand, given that the other parts of data flow not is the limiting part... I'm currently throwing eyes upon a CQD-440/TM, that, according to writing, is Fast SCSI-2, with Differential Mode driver, but if anyone has experience of xxx I might rethink... That is: SCSI transfer disc --> adapter buffer memory is at SCSI- speed, MSCP overhead is at adapter processor speed, and maximum DMA transfer adapter ---> working memory is at Q-22 speed. Best regards, G=F6ran ------------------------------ Date: Sun, 20 Apr 2008 16:57:03 -0500 From: Muddflapp Mohican Subject: TL892 (two TZ89s) one "In-Flex" Message-ID: <7omdnWBlYrWLXJbVnZ2dnUVZ_tajnZ2d@earthlink.com> Hi. What does the "In-Flex" message mean on the TL892 tape library ? The tape library uses SCSI-HVD and has two TZ89s. Drive 0: Idle Drive 1: In-Flex Loader: Idle 0*****-*****9 ------------------------------ Date: Mon, 21 Apr 2008 01:30:47 -0400 From: "William Webb" Subject: Re: TL892 (two TZ89s) one "In-Flex" Message-ID: <8660a3a10804202230x1f6e2868rad6e0308d7a47274@mail.gmail.com> It means Call Field Service.and get the drive replaced. WWWebb On Sun, Apr 20, 2008 at 5:57 PM, Muddflapp Mohican wrote: > Hi. > > What does the "In-Flex" message mean on the TL892 tape library ? > > The tape library uses SCSI-HVD and has two TZ89s. > > Drive 0: Idle > Drive 1: In-Flex > Loader: Idle > > 0*****-*****9 > ------------------------------ Date: Sun, 20 Apr 2008 16:27:22 -0500 From: Muddflapp Mohican Subject: Re: UIC full display Question Message-ID: I think what you want is: $ mcr authorize add /identifier/value=[200,11420] PDZA010 I hope this message produces text only and not html or mime. It's been several years since I've posted to this forum. I'm using a mail client called SeaMonkey. Chuck Aaron wrote: > What would cause one id under the same account to show as different > uic description value? I am wondering why the 200,11420 is listing twice > and not showing napis,pdza010 like the one above. Any ideas? > > Thank you in advance, > Chuck > > Username: PDZA005 Owner: NAPIS > Account: NASPEC UIC: [200,5] ([NAPIS,PDZA005]) > > Username: PDZA010 Owner: NAPIS > Account: NASPEC UIC: [200,11420] ([200,11420]) ------------------------------ Date: Sun, 20 Apr 2008 18:10:31 -0500 From: Muddflapp Mohican Subject: Re: VMS advertising ! Message-ID: Sign me up for an iVAX! I also want a 3GHZ VAXstation 4000-'08 or VAX 4000-'08 ('08 meaning the year 2008) They should all support fiber-channel, gigabit ethernet, scsi, dssi, ide, fc, sata drives of any size. Bob Koehler wrote: > In article <3bbc708b-1495-4732-9abf-a17ddb9b6940@59g2000hsb.googlegroups.com>, AEF writes: >> Yet more support for how cool VAX is as a name. VAX. And VAX/VMS. How >> can you beat that for a name? VAX ... VAX/VMS ... > > So if HP wants to be successfull they need to bring out a line of > IA-32-64 based processors with a VMS port and call them iVAX, or > iVAX-11 or VAX-64 or some such. > > Would you want iVAX-VMS on your next computer? > > OBTW, they also need to make sure thier latest ink eaters are > supported by HP DCPS for VAX-64/iVMS or whatever. > ------------------------------ Date: Sun, 20 Apr 2008 21:16:47 -0400 From: "Peter Weaver" Subject: RE: VMS advertising ! Message-ID: <052801c8a34d$5f9ec8b0$2802a8c0@CHARONLAP> > Sign me up for an iVAX! > I also want a 3GHZ VAXstation 4000-'08 or VAX 4000-'08 ('08 > meaning the year 2008) > They should all support fiber-channel, gigabit ethernet, scsi, > dssi, ide, fc, sata drives of any size. > That is not iVAX,that is CHARON-VAX. Actually for CHARON-VAX you have to drop the DSSI. CHARON-VAX also works with iSCSI if you want to add that to your list. Peter Weaver www.WeaverConsulting.ca www.OpenVMSvirtualization.com www.VAXvirtualization.com www.AlphaVirtualization.com ------------------------------ End of INFO-VAX 2008.222 ************************