INFO-VAX Thu, 14 Jun 2007 Volume 2007 : Issue 321 Contents: Re: 8086 vs patches Re: 8086 vs patches Re: 8086 vs patches Re: 8086 vs patches Re: Another opportunity Re: Another opportunity Re: Another opportunity Re: Another opportunity Re: Another opportunity RE: Another opportunity Re: Another opportunity Re: Another opportunity Re: Another opportunity Re: Another opportunity Re: Another opportunity Re: Another opportunity Re: Another opportunity Re: Anyone know why the Alpha market is so so quiet? Re: Anyone know why the Alpha market is so so quiet? Re: Anyone know why the Alpha market is so so quiet? Re: Anyone know why the Alpha market is so so quiet? Re: Anyone know why the Alpha market is so so quiet? Re: BACKUP Suggestions (/STAT and error handling) 8.3 Re: BYPASS privilege !! Re: BYPASS privilege !! Re: BYPASS privilege !! ES45 Mod 2 Service Bulletin Re: help running OpenVMS on Itanium 2 2620 WinXP variant Re: help running OpenVMS on Itanium 2 2620 WinXP variant Re: host based routing software? Re: More TCPIP nonsense Re: More TCPIP nonsense Re: More TCPIP nonsense Re: OT: Question to Bob Re: Question for the Group Re: Question for the Group Re: Question for the Group Re: Question for the Group Re: Question for the Group Re: SMTP.CONFIG: Reject-Mail-From: for part of an address? Re: SMTP.CONFIG: Reject-Mail-From: for part of an address? RE: Story Time Re: VMS analogue of FBSD and linux hier(7) man pages Re: VMS analogue of FBSD and linux hier(7) man pages Re: VMS analogue of FBSD and linux hier(7) man pages Re: VMS analogue of FBSD and linux hier(7) man pages Re: VMS analogue of FBSD and linux hier(7) man pages Re: VMS analogue of FBSD and linux hier(7) man pages Re: VMS analogue of FBSD and linux hier(7) man pages Re: VMS analogue of FBSD and linux hier(7) man pages Re: VMS analogue of FBSD and linux hier(7) man pages Re: Why partitioned disks on VMS would be useful Re: Why partitioned disks on VMS would be useful Re: Why partitioned disks on VMS would be useful Re: Why partitioned disks on VMS would be useful ---------------------------------------------------------------------- Date: Wed, 13 Jun 2007 14:58:12 -0500 From: Ron Johnson Subject: Re: 8086 vs patches Message-ID: On 06/13/07 11:32, Richard B. Gilbert wrote: > Ron Johnson wrote: >> On 06/13/07 08:17, Bob Koehler wrote: >> >>> Ron Johnson writes: >>> >>>> I'm sure it is, in a radiation-hardened form. Same for the 80386 & >>>> 80486. >>>> >>> >>> I think there are stocks of rad hardended 386 and 486, but I'm not so >>> sure anything earlier than 486 is still being fabbed and not even too >>> sure about those. Rad hardened RISC chips are fairly common now. >> >> >> MIPS, I'd wager. Maybe PPC? >> >>> A supply of earlier chips for maintenance will not go on forever >>> as aircraft systems do get upgraded. >> >> >> I wonder if that's one of the reasons why the F-14 was retired and the >> F-15 will be. >> > > I'd look to things like "metal fatigue" and just plain wear and tear for > the reasons. Airplanes, like cars and many other things, reach the far > end of the bathtub curve. The failure rate rises sharply and it becomes > uneconomical to continue to use them. > > I don't know what we're using to replace them The F-22 and (eventually) the F-35. > but I'd bet that they are > faster, more maneuverable, better armed, etc, etc. And a *lot* more expensive. And we won't have near as many of them. Actually, it's a lot like VMS vs. Linux/Windows, except in reverse. > It's a good bet that > even brand new F-14s and F-15s couldn't compete! Apparently, the Eurofighter can smoke the F-15 in a dogfight. Of course, it's 25 years newer... -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Wed, 13 Jun 2007 15:04:55 -0500 From: Ron Johnson Subject: Re: 8086 vs patches Message-ID: On 06/13/07 11:43, etmsreec@yahoo.co.uk wrote: > A few years ago (maybe four, maybe five) NASA, it was claimed, were > having problems with the Space shuttle as it was still dependant in > some way on 486 processors. This would make sense given the time that > the shuttle was designed I guess? The Shuttle was designed back when the 8080 was the only microprocessor. And I guarantee you it didn't use any. Refits in the early 90s probably pulled out big-but-slow ancient-but-man-rated computers and replaced them with rad-hardened 16MHz 80386 chips that had been continuously tested for 3 years. Chips from the same lot are probably still in the shuttles. And doing a perfectly adequate job. > I'm told that railway signalling was still being controlled by > Pentiums, not PII, not PIII etc a few years ago when Paddington > station in London was being resignalled. Even the 80486 is surely fast enough to do railway switching. There's no GUI involved, just a lot of bytes to read and process. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Wed, 13 Jun 2007 21:24:54 -0400 From: Dave Froble Subject: Re: 8086 vs patches Message-ID: Richard B. Gilbert wrote: > Ron Johnson wrote: >> On 06/13/07 08:17, Bob Koehler wrote: >> >>> Ron Johnson writes: >>> >>>> I'm sure it is, in a radiation-hardened form. Same for the 80386 & >>>> 80486. >>>> >>> >>> I think there are stocks of rad hardended 386 and 486, but I'm not so >>> sure anything earlier than 486 is still being fabbed and not even too >>> sure about those. Rad hardened RISC chips are fairly common now. >> >> >> MIPS, I'd wager. Maybe PPC? >> >>> A supply of earlier chips for maintenance will not go on forever >>> as aircraft systems do get upgraded. >> >> >> I wonder if that's one of the reasons why the F-14 was retired and the >> F-15 will be. >> > > I'd look to things like "metal fatigue" and just plain wear and tear for > the reasons. Airplanes, like cars and many other things, reach the far > end of the bathtub curve. The failure rate rises sharply and it becomes > uneconomical to continue to use them. > > I don't know what we're using to replace them but I'd bet that they are > faster, more maneuverable, better armed, etc, etc. It's a good bet that > even brand new F-14s and F-15s couldn't compete! > Don't be too sure about that. A small number of F22 Raptors are being purchased. But they are very expensive, so will not be sufficient to replace all the older aircraft. The F22 has some nice features, stealth, super cruise, but it's my understanding the weapon load is smaller. There's no stealth if you have all that ordinance hanging off the wings. It's not as fast (top speed) as the F-15, as far as I know. Then again, the F-15 isn't too useful at Mach 2.5, so that isn't a hugh issue. Some older F-15 A and C models may be retired, but the newer E models will be around for some time. It's really a different aircraft, and more versitile. The A and C models are solely for air to air combat, and frankly, there isn't anyone left to fight in that role. Suicide jackets are what the state of the art has advanced to. In addition to congressmen needing some new business for their constitutants, the major reason is most likely the increased maintenance costs of aging aircraft. -- David Froble Tel: 724-529-0450 Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc. 170 Grimplin Road Vanderbilt, PA 15486 ------------------------------ Date: Wed, 13 Jun 2007 21:12:22 -0500 From: Ron Johnson Subject: Re: 8086 vs patches Message-ID: On 06/13/07 20:24, Dave Froble wrote: [snip] > > Don't be too sure about that. > > A small number of F22 Raptors are being purchased. But they are very > expensive, so will not be sufficient to replace all the older aircraft. > > The F22 has some nice features, stealth, super cruise, but it's my > understanding the weapon load is smaller. There's no stealth if you > have all that ordinance hanging off the wings. It's not as fast (top > speed) as the F-15, as far as I know. Then again, the F-15 isn't too > useful at Mach 2.5, so that isn't a hugh issue. But it's really impressive, and helps you a) catch up with, or b) escape from, a bad guy. > Some older F-15 A and C models may be retired, but the newer E models > will be around for some time. It's really a different aircraft, and > more versitile. The A and C models are solely for air to air combat, > and frankly, there isn't anyone left to fight in that role. You'd be surprised. The Eurofighter is a fine modern airplane that can defeat the F-15. Also, the Ruskies are making some fine airplanes (which - being good capitalists - they sell to anyone) and have forged strong ties with the ChiCom air force. Sure, "we" can see no purpose in fighting us (it would destroy China's economy, for example), but countries don't always fight for rational reasons. > Suicide > jackets are what the state of the art has advanced to. > > In addition to congressmen needing some new business for their > constitutants, the major reason is most likely the increased maintenance > costs of aging aircraft. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Wed, 13 Jun 2007 15:06:23 -0400 From: JF Mezei Subject: Re: Another opportunity Message-ID: <85d1$46704032$cef8887a$397@TEKSAVVY.COM> Stephen Hoffman wrote: > DIGITAL announced it was getting out of the workstation market. DIGITAL also announced it was going out of business and wishing to sell its remains to anyone. IA64 will fail because it has gotten out of the low end market. > The "fun" for many years was that DIGITAL bet very heavily on OSI. > And DIGITAL lost that bet, and ended up playing catch-up in the market. Digital was in fact a leader in OSI. But when that flopped, DEC should have been able to turn around and get a good DECNET-quality TCPIP on VMS ASAP. (or just get Multinet to be an official part of VMS, or buy TGV). ------------------------------ Date: 13 Jun 2007 14:35:33 -0500 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Another opportunity Message-ID: In article , koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article <5d7lceF342pf9U2@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: >> In article <1181640747.768522.7710@r19g2000prf.googlegroups.com>, >> IanMiller writes: >>> paragraph 3.6.1 is talking about Trusted Operating Systems with >>> mandatory access control. This has not been seen in VMS land since >>> SEVMS. >> >> I thought regular VMS had "mandatory access control"? I guess I >> was wrong. :-( But it still fits into the general model proposed >> by this paper. >> > > The "mandatory access control" available in SEVMS and specified in > vertain government applications is not the kind of file control > seen in VMS, UNIX, Windows, or other general purpose OS. It includes > concepts like write-up (to higher security level) and read-down (to > lower security level). In fact, raw VMS has no "mandatory access control" of any sort, as "mandatory access control" is defined as control that cannot be modified by the owner of the file. MVS, at least with some of the three available security packages, does provide "mandatory access control", although not with the Bell-Lapadula semantics described by Bob Koehler. ------------------------------ Date: Wed, 13 Jun 2007 14:43:21 -0500 From: Ron Johnson Subject: Re: Another opportunity Message-ID: On 06/13/07 11:44, Richard B. Gilbert wrote: [snip] >> >> If DCL had been constantly improved like bash 1.0 was an >> improvement > > > How would you "improve' DCL. Since they added IF/THEN/ELSE a few > years ago, it's been just about perfect. :-) WHILE, FOR, CASE and "lists" would help a lot. And I'm sure I could think of some excellent uses of user-defined functions. > I know someone who claims to have a DCL program that occupies > some 400 pages of "greenbar paper" when printed. Many of us have > written DCL that "writes" DCL. It's a hell of a lot more > "readable" than the abominations that Unix uses. True. And lexicals make many things easier than in bash. But bash lets you do a *lot* on just one line, once you know the language. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Wed, 13 Jun 2007 16:45:15 -0400 From: "Richard B. Gilbert" Subject: Re: Another opportunity Message-ID: <4670575B.5040605@comcast.net> Ron Johnson wrote: > On 06/13/07 11:44, Richard B. Gilbert wrote: > [snip] > >>> >>> If DCL had been constantly improved like bash 1.0 was an >>> improvement >> >> >> >> How would you "improve' DCL. Since they added IF/THEN/ELSE a few >> years ago, it's been just about perfect. :-) > > > WHILE, FOR, CASE and "lists" would help a lot. And I'm sure I > could think of some excellent uses of user-defined functions. > >> I know someone who claims to have a DCL program that occupies >> some 400 pages of "greenbar paper" when printed. Many of us have >> written DCL that "writes" DCL. It's a hell of a lot more >> "readable" than the abominations that Unix uses. > > > True. And lexicals make many things easier than in bash. > > But bash lets you do a *lot* on just one line, once you know the language. > But bash, or any Unix shell uses a command line that LOOKS as if you had slapped your keyboard with your coffee cup! Anything I can't do on one line, I'm inclined to put in a command file! ------------------------------ Date: Wed, 13 Jun 2007 15:55:10 -0500 From: Ron Johnson Subject: Re: Another opportunity Message-ID: On 06/13/07 15:45, Richard B. Gilbert wrote: > Ron Johnson wrote: >> On 06/13/07 11:44, Richard B. Gilbert wrote: >> [snip] >> >>>> >>>> If DCL had been constantly improved like bash 1.0 was an >>>> improvement >>> >>> >>> >>> How would you "improve' DCL. Since they added IF/THEN/ELSE a few >>> years ago, it's been just about perfect. :-) >> >> >> WHILE, FOR, CASE and "lists" would help a lot. And I'm sure I >> could think of some excellent uses of user-defined functions. >> >>> I know someone who claims to have a DCL program that occupies >>> some 400 pages of "greenbar paper" when printed. Many of us have >>> written DCL that "writes" DCL. It's a hell of a lot more >>> "readable" than the abominations that Unix uses. >> >> >> True. And lexicals make many things easier than in bash. >> >> But bash lets you do a *lot* on just one line, once you know the >> language. >> > > But bash, or any Unix shell uses a command line that LOOKS as if you had > slapped your keyboard with your coffee cup! Anything I can't do on one > line, I'm inclined to put in a command file! In that regard, Perl is much worse than bash. Which is why I don't like Perl... Python, though, IMNSHO, is an excellent "fit" for someone migrating from VMS -> Unix. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Wed, 13 Jun 2007 18:58:42 -0400 From: "Main, Kerry" Subject: RE: Another opportunity Message-ID: > -----Original Message----- > From: Ron Johnson [mailto:ron.l.johnson@cox.net] > Sent: June 12, 2007 6:39 PM > To: Info-VAX@Mvb.Saic.Com > Subject: Re: Another opportunity >=20 > On 06/12/07 17:21, Rich Alderson wrote: > [snip] > > DEC didn't produce a good TCP/IP stack on *any* architecture, and > DECNET is > > the reason. There are still 36-bit bigots who hate VMS who believe > that > > DECNET should have won the networking wars (and at least one who > thinks that > > the skunkworks ANF-10 should have beat out DECNET. >=20 > Reminds me of the people who haven't quite accepted that the North > won the War. >=20 > -- You mean the one where Canada beat the US? :-) Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: 13 Jun 2007 21:01:59 -0400 From: Rich Alderson Subject: Re: Another opportunity Message-ID: david20@alpha2.mdx.ac.uk writes: > >On 06/12/07 17:21, Rich Alderson wrote: >>> DEC didn't produce a good TCP/IP stack on *any* architecture, and DECNET >>> is the reason. There are still 36-bit bigots who hate VMS who believe >>> that DECNET should have won the networking wars (and at least one who >>> thinks that the skunkworks ANF-10 should have beat out DECNET. > DEC's Unix Ultrix produced in 1984 must surely have had a TCPIP stack. > But VMS didn't get one from DEC until about 1989 and then it seemed to be > a very minimal stack to provide limited connectivity to Ultrix (UCX). Ultrix (which I used for several years) included the BSD networking software, not produced by DEC, and does not constitute an argument against my point. ;-) -- Rich Alderson | /"\ ASCII ribbon | news@alderson.users.panix.com | \ / campaign against | "You get what anybody gets. You get a lifetime." | x HTML mail and | --Death, of the Endless | / \ postings | ------------------------------ Date: Wed, 13 Jun 2007 20:35:05 -0500 From: Ron Johnson Subject: Re: Another opportunity Message-ID: On 06/13/07 17:58, Main, Kerry wrote: >> -----Original Message----- >> From: Ron Johnson [mailto:ron.l.johnson@cox.net] >> Sent: June 12, 2007 6:39 PM >> To: Info-VAX@Mvb.Saic.Com >> Subject: Re: Another opportunity >> >> On 06/12/07 17:21, Rich Alderson wrote: >> [snip] >>> DEC didn't produce a good TCP/IP stack on *any* architecture, and >> DECNET is >>> the reason. There are still 36-bit bigots who hate VMS who believe >> that >>> DECNET should have won the networking wars (and at least one who >> thinks that >>> the skunkworks ANF-10 should have beat out DECNET. >> Reminds me of the people who haven't quite accepted that the North >> won the War. >> >> -- > > You mean the one where Canada beat the US? > > :-) I said North, not Hosers. Eh? -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Thu, 14 Jun 2007 05:22:09 +0200 From: Michael Kraemer Subject: Re: Another opportunity Message-ID: Stephen Hoffman schrieb: > DIGITAL announced it was getting out of the workstation market. And that was when ? Certainly not at the time the AlphaStation 500 was released. DEC/Compaq produced gfx capable machines long after that. And wasn't there a little upheaval of customers when the death of VMS workstations was announced ? >>> My alphastation has a gfx card which isn't supported by VMS out >>> of the box. > > Which graphics controller? A ZLXp-L2. Gfx didn't start because open3d isn't there. (I don't need 3D at this point, just a normal GUI). Tru64 works fine. Maybe the two divisions within DEC should have talked more to each other. > >> This appears to be another HP development since under COMPAQ and DEC >> VMS was well known for it's continued support for decades old hardware >> with the latest versions of the OS. > > Old systems classically dropped off the support list. That's not true, AFAIK. The AlphaStation should still be supported, as are even older boxes like the Turbochannel alphas. At least with VMS 7.3-x, which is what hobbyists got about 2 years ago. > Tru64 UNIX retired all DEC 3000 boxes and slews of controllers, which > caused a minor uproar. AFAIK Tru64 supports Turbochannel boxes way into its 5.x releases. >>> On the next box I tried, a PWS500, >>> VMS didn't like the CD-ROM (an IDE drive), so I had to plug >>> one of those rare 512-byte SCSI drives. > > Which CD-ROM? Which Personal Workstation? (Some of these Personal > Workstation boxes didn't have junk I/O capable of booting IDE disks. > I've yet to meet identical IDE disks.) The one that came with the machine, a Toshiba XM-6302B (according to the console). I wouldn't make a strong point about it, since I'm accustomed to the fact that "ancient" OSs often require 512-byte capable SCSI CD-ROMs, so consequently I have stockpiled a couple of such devices. It's a minor nuisance, but I find it remarkable that another OS from the same vendor has better support for the very same hardware. > There are Itanium boxes that would boot OpenVMS for US$500 on eBay. > Add a real license for US$900 per core or a hobbyist license, and off > you go. Well, I'm not inclined to board the itanic (and am probably in sync with some of the posters here on this one). The alphas I have are pretty good machines, at least for a hobbyist, somewhat cheaper than the itanic above (still first generation I presume). > Old gear goes away. That's the nature of the business. One of VMS' stronger points was backward compatibility. At least it used to be in the past. > What you buy > now is worthless junk in five years. Sometimes less. I don't see them as an investment. > >> Hardware peripherals depend upon the age of the box and what is >> supported in >> hardware as well as in software. Some of the earlier PWS boxes >> couldn't boot >> VMS from IDE CD drives. > > Those boxes were never supported for OpenVMS, either. They sorta > worked, and were not explicitly locked out. Directions on how to work > around this got posted, too. The PWSs surely were/are supported. As for the IDE, see above. > The "fun" for many years was that DIGITAL bet very heavily on OSI. And > DIGITAL lost that bet, and ended up playing catch-up in the market. OK, shit happens. But it's beyond my comprehension that a company of DECs size and capability would need about a decade to catch up. > IP is not rocket science, but it's certainly a large and never-ending > empirical effort -- very little of IP actually works the way implied by > the RFCs. And IP is perpetually moving forward, so you're always > chasing and re-porting, or extending. Also the nature of the business. Oh come on, other companies (with much less resources) have accomplished that. Even other divisions at DEC themselves (shall I mentioned Tru64 again ?). > I suspect Mr. Kraemer wants a generic IDE CD-ROM and to continue to > use an ancient graphics widget on his existing Personal Workstation, > while also looking to upgrade the older gear to current software. Well, from the 4+ boxes (VAX and alpha) I've tried to install VMS, none went smoothly (as e.g. compared to Tru64 on the same box). I don't use exotic hardware and all of them appear to be officially supported by the OS available to hobbyists. I find this remarkable, and in view of proposed "marketing" campaigns to attract newbies, the owners of VMS would have some homework to do before, IMHO. ------------------------------ Date: Thu, 14 Jun 2007 05:50:35 +0200 From: Michael Kraemer Subject: Re: Another opportunity Message-ID: david20@alpha2.mdx.ac.uk schrieb: > > It's much too long since I setup VMS on a VAX system so I can't really > comment on how well integrated TCPIP is into it's installation procedures. > On Alpha the installation/upgrade procedure asks whether to install/upgrade > DEC TCPIP services in the same way it asks whether you want to install/upgrade > DECNET Phase IV or DECNET Phase V. That's similar to the VAX, but a VAX needs additional steps before TCPIP works. > >>On my VS4000s I had to edit sys$system:modparams.dat >>to add a MIN_INTSTKPAGES=12, otherwise it wouldn't run. >>(this was nowhere described, it took me several hours to figure it out). >>Plus run some autogen stuff. >>Plus the three UCX PAKs (no other OS I know of needs such dongles >>just to be able to communicate with the rest of the world). > > DECNET also requires a license PAK. TCP/IP on most other systems does not need PAKs. >>Of course you can't just ftp the license.com since ftp is not yet >>working. Brilliant. > > > Apart from systems which were designed to install via FTP (and which therefore > start up a restricted FTP process) is there any system which allows ftp access > during installation ? Even systems which install via ftp don't, as far as I am > aware, allow you to just ftp up a file in the middle of the installation. I tried to point out that it's a major nuisance in general to type those silly authorization codes and checksums (sth which is not necessary on most other systems). One can partially avoid this by just running the license file as a DCL script. This would require to ftp this file before, but hey, TCPIP needs a PAK. No PAK, no TCPIP; no TCPIP, can't ftp the PAKs. Vicious circle so to say. Or did I miss sth here ? > > Version 8.2 and later of OPENVMS don't require the Open3D license for 3D > support and don't support installation of the Open3D layered product which is > probably why it isn't on the hobbyist CD. Unfortunately OpenVMS 8.2 also > dropped support for some graphics cards. > see > http://h71000.www7.hp.com/doc/82FINAL/6674/6674pro_retired.html#retirementch > > and > > http://h71000.www7.hp.com/doc/82FINAL/6674/6674pro_hardware2.html#graphicsboards Well, 7.3-2 (alpha) was all I had as hobbyist when I tried it last time. > This appears to be another HP development since under COMPAQ and DEC VMS was > well known for it's continued support for decades old hardware with the > latest versions of the OS. Mr. Hoffmann seems to have a different view on this one. > Hardware peripherals depend upon the age of the box and what is supported in > hardware as well as in software. Some of the earlier PWS boxes couldn't boot > VMS from IDE CD drives. Well, Tru64 could, but I think VMS always requires 512-byte SCSI. On VAXen it's even more confusing. Some drives work, some don't. > I'm not sure what extra level of integration you are looking for. As it is in any Unix system. Part of the OS. No extra installation, no extra PAK. On installation, prompt IP name and number, as it is done by the installation wizards on Tru64 or AIX. ------------------------------ Date: Wed, 13 Jun 2007 22:58:51 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Another opportunity Message-ID: <07061322585169_202003EE@antinode.org> From: Michael Kraemer > [...] but I think VMS always requires 512-byte SCSI. Many people seem to believe that VMS requires a CD-ROM drive which has a 512-byte-block jumper, but I do not. I no longer (exclusively) use the oldest hardware on the planet, but I've used some Toshiba CD-ROM drives (XM5401B, XM-5701B, XM-6201B), and, I believe, some others (NEC?) which had no block-size jumper, at least with Alphas, and perhaps with VAXes, too. The drive does, I believe, need to respond properly to a SCSI command which sets the block size, and the computer needs to be smart enough to send the command, but it seems that many drives and computers qualify. Lately, I've been putting SCSI DVD-ROM drives into everything I can ("TOSHIBA DVD-ROM SD-M1711", probably pulled from Sun systems), and these _do_ have a block-size jumper (which was already installed), and I haven't tried using one without it, so I don't have an easy way to check this again. Note that the last time I used the XM-6201B, it was with a Sun-clone Tatung Ultra COMPstation, so even "Sun-bootable" is not the restriction it was when SPARC was a new thing. I _do_ remember (dimly) being unable to boot some old SPARCstation something-or-other because of the block-size restriction, but clearly, it hasn't been a problem with Sun hardware/firmware for a long time, either. > On VAXen it's even more confusing. Some drives work, some don't. I've noticed this on non-VAXes, too. And not only with CD-ROM drives. Wasn't someone compiling a list of which CD-ROM drives work on what? I claim that a list of which drives fail on what would be shorter. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Thu, 14 Jun 2007 00:56:43 -0400 From: Stephen Hoffman Subject: Re: Another opportunity Message-ID: A ZLXp-L2 PixelVision on what I must assume is a Personal Workstation 500a series box (though possibly loaded with the -au firmware), and the gear itself is around a decade or so old. You're correct; you'll have to replace at least the graphics controller if you want to move forward. You're far enough back that you'll not be able to use a recent-generation controller; those typically require an EV6-class processor, and the 500-series boxes were EV56. The PBXGB-AA and -CA are among the best choices here; they're seriously fast controllers. (The older controllers don't drive LCDs all that well, unfortunately.) A number of the Personal Workstation boxes had the SIO for the junk I/O interface, and OpenVMS never got that to boot. Most of these were in the -a series, but it would not surprise me the -au series had a few too. (I never did figure out how to identify these, other than by looking at the console output.) OpenVMS I64 doesn't have a separate license PAK for TCP/IP Services. Once it got all got sorted out, OpenVMS and Tru64 Unix shared graphics drivers for a number years, and also shared chunks of the IP stack. Tru64 dropped a boatload of graphics controllers, and the TURBOchannel stuff. Then came the announcement of the Tru64 Unix retirement. CD media loaded in IDE disk drives always have 2048-byte blocks. It's only SCSI that has traditionally had to deal with 512-byte CD drives. That may well have been addressed in the SCSI driver stack, I haven't looked. Not able to comment on your installation issues without some details of the boxes. I've certainly seen my share of install-time errors, usually on creative configurations -- certainly the OpenVMS operating system installation and configuration and ECO processing does not compare well with other environments. Older boxes fall off support. Old controllers fall of support. Whole tracts of VAX systems fell off the support list a while back (in a couple of waves), as did specific Alpha systems and specific hardware. Current OpenVMS has the IP stack selectively installed from the installation menu; it's reasonably well integrated, and there's no separate installation step. With the OpenVMS I64 OE licensing, there's no separate PAK for IP. IP is not as well integrated as various other boxes; OpenVMS has selected a rather more disjoint path toward its configuration and integrated/installed and optional components. Most boxes have IP, Apache, firewall, and other tools built in, and many ship with compilers (c/php/perl/python/etc) and programming tools integrated. Adverse reactions to Itanium aside, that's the only platform with new hardware that's sold for use with OpenVMS now. The older (and officially unsupported) dual-900 MHz boxes performed on par with an AlphaStation XP1000 box, based on my interactive use. Newer Itanium processors -- the officially-supported boxes were the post-McKinley Madison and Montecito generations, and such -- are faster. -- www.HoffmanLabs.com Services for OpenVMS ------------------------------ Date: Thu, 14 Jun 2007 00:29:01 -0500 (CDT) From: sms@antinode.org (Steven M. Schweda) Subject: Re: Another opportunity Message-ID: <07061400290106_20200346@antinode.org> From: Stephen Hoffman > A number of the Personal Workstation boxes had the SIO for the junk I/O > interface, and OpenVMS never got that to boot. Most of these were in > the -a series, but it would not surprise me the -au series had a few > too. (I never did figure out how to identify these, other than by > looking at the console output.) It's worse than that. I have a genuine PWS 500a (with the Intel SIO chip and its attendant problems), but when I installed a Qlogic SCSI card (ISP1040B chip, KZPBA-CX or similar), it started putting on airs, and calling itself a 500au. I use the (useless) USB ports as a guide to which is which. So far as I know, they correlate well with the Cypress chip. I quit trusting the model number, no matter whence it came. ------------------------------------------------------------------------ Steven M. Schweda sms@antinode.org 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 ------------------------------ Date: Wed, 13 Jun 2007 14:21:44 -0400 From: "John Smith" Subject: Re: Anyone know why the Alpha market is so so quiet? Message-ID: <2a12c$467035af$cef8821f$2882@TEKSAVVY.COM-Free> Bill Gunshannon wrote: > In article , > "John Smith" writes: >> >> How many of your off-VMS onto-Linux customers have come back to you >> at the end of the migration and said "We never should have switched"? > > How many CEO's who killed successful Processor families in favor of as > yet non-existant Processor families came back later to admit they had > made a mistake? The first rule of comporate management is never admit > a mistake, the other sharks can smell the blood in the water. > > bill None of those CEO's who killed processors, burned boats, sold off their application and tools based, or refused to sell snake oil, survived long enough to admit they made a mistake. Like I said elsewhere, corporations have *zero* obligations to customers beyond what is expressly set forth in writing in a warranty or contract. -- OpenVMS - The never-advertised operating system with the dwindling ISV base. ------------------------------ Date: Wed, 13 Jun 2007 22:01:44 -0400 From: Dave Froble Subject: Re: Anyone know why the Alpha market is so so quiet? Message-ID: John Smith wrote: > 4) What about staff retention - have they mentioned that their staff may > want to have relevant *marketable* experience with the technologies that can > get them new jobs if the company downsizes/outsources them? I'm sure that > has to be in the minds of everyone in the IT divisions except perhaps the > CIO. I see this argument used all the time. Frankly, I don't understand it. Is it part of an employer's responsibility to train employees for their next job? You train employees for the job that you wish them to do. There is no other requirements. David Froble Tel: 724-529-0450 Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com DFE Ultralights, Inc. 170 Grimplin Road Vanderbilt, PA 15486 ------------------------------ Date: Wed, 13 Jun 2007 22:08:19 -0400 From: JF Mezei Subject: Re: Anyone know why the Alpha market is so so quiet? Message-ID: <5f6b5$4670a31a$cef8887a$19776@TEKSAVVY.COM> Dave Froble wrote: > I see this argument used all the time. Frankly, I don't understand it. > Is it part of an employer's responsibility to train employees for > their next job? When CIOs read their trade rags to learn what *they* should be doing, they learn of places like Google who strive to provide environments that will attract the youngest and brightest people to work for them. This is different from the VMS community when VMS experts with tons of experience are willing to work for food and there is so little demand for their skills that they must find work in other technologies. In an area where trade rags dictate corporate policies, trade rags tell CIOs that it is important to choose the "soupe du jour" technologies in order to appeal to potential employees that are so rare and hard to find. They are told that the youngest and brightest are not interested in learning/working with legacy technologies that will be useless for their next job. They are told that it is imperative to adopt the latest and greatest "soupe du jour" in order to attract employees to their shop and that if they do not do this, nobody will want to work for them. These situations where it is so hard to find young and experienced employees are not very widespread, but they are the ones that get the attention because they are high profile employers such as Google and Yahoo. But the media coverage causes the heard of sheep to follow as if it were also their problem. ------------------------------ Date: Wed, 13 Jun 2007 23:19:12 -0400 From: "Richard B. Gilbert" Subject: Re: Anyone know why the Alpha market is so so quiet? Message-ID: <4670B3B0.8070103@comcast.net> Dave Froble wrote: > John Smith wrote: > >> 4) What about staff retention - have they mentioned that their staff may >> want to have relevant *marketable* experience with the technologies >> that can >> get them new jobs if the company downsizes/outsources them? I'm sure that >> has to be in the minds of everyone in the IT divisions except perhaps the >> CIO. > > > I see this argument used all the time. Frankly, I don't understand it. > Is it part of an employer's responsibility to train employees for their > next job? > > You train employees for the job that you wish them to do. There is no > other requirements. > I think it's smart to both train your employees and cross train them. An employee who knows VMS, Solaris, and Windows is a hell of a lot more valuable than an employee who knows only one of those systems. My job title was "VMS System Manager" but I learned to remove viruses and worms (mostly WELCHIA32) from PCs and to patch them to prevent reinfection. I know I patched more than 100 desktop PCs to bring them up to W2k SP4 plus all the latest patches. I did a few W/NT4 systems to whatever SP was current and a few W/XP. I also learned to install Solaris 8/X86 and to "fsck" the file systems when people dumped power on them instead of shutting them down properly. I knew my way around the network closets and how to patch a particular wall jack to a switch port. I learned how to shut down and start up a Novell Server. I learned about disaster recovery and "business resumption" and wrote the Disaster Recovery and Business Resumption plans. We all had our areas of expertise but we all pitched in to get the job done. We rotated "on call" and we needed to know at least enough to be able to troubleshoot a problem to the point where we could call the right person to fix it. Remember that an employee's "next job" will, ideally, be a more responsible job in the same company. That's how you retain good people. Failing to retain good people can be very expensive! It costs to hire people and it costs to train them. Every good employee you lose is money down the toilet. ------------------------------ Date: Thu, 14 Jun 2007 01:15:31 -0400 From: JF Mezei Subject: Re: Anyone know why the Alpha market is so so quiet? Message-ID: <5b4a8$4670cef7$cef8887a$27911@TEKSAVVY.COM> Richard B. Gilbert wrote: > Remember that an employee's "next job" will, ideally, be a more > responsible job in the same company. That's how you retain good people. This used to be the case. Then large corporation instituted "corporate wide" rules with regards to pay scales etc and this makes it much harder for an employee to see real salary increases within the same company unless he drops his technical job to go to management. But by moving to a different compeny, he can generally get totally new benefits, salary, learn new technologies and also escape from his previous employer's pay scale limitations. ------------------------------ Date: Wed, 13 Jun 2007 20:52:02 -0500 From: David J Dachtera Subject: Re: BACKUP Suggestions (/STAT and error handling) 8.3 Message-ID: <46709F42.9CDB5E9F@spam.comcast.net> JF Mezei wrote: > > Based on Backup, alpha, 8.3 > > Having BACKUP display a summary at the end would be very useful. > > Total files backed up, $ SEARCH the /LISTING file for "]",";"/match=and/noout/log > total blocks used in those files, Found at the end of the /LISTING file. > total blocks allocated in those files, Is that important? (It might vary depending on the clustersize of the target volume in case of a restore to a volume other than where they came from. > total files skipped due to nobackup, $ SEARCH the /LISTING file for "NOBACKUP"/noout/log > total files that were open for writing $ SEARCH the /LISTING file for " another "/noout/log > time elapsed Use F$DELTA_TIME() on the /LISTING file's CDT and RDT before the RDT gets changed by something else. > and performance (blocks per second). Convert the ET to seconds and divide the Total blocks by the number of seconds. > Also, if backup ever aborts due to an error, it should provide the above > statistics no matter what, as well as the name of the file last > succesfully saved $ TYPE/TAIL=1 on the /LISTING file > (and the name/file id) of file where error was > encountered.) Should be reported by BACKUP in the error message(s). -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Wed, 13 Jun 2007 14:25:55 -0400 From: JF Mezei Subject: Re: BYPASS privilege !! Message-ID: <12634$467036b6$cef8887a$30475@TEKSAVVY.COM> Bob Koehler wrote: > I can't answer this one, but I can tell you that I ran a VMS > system with SYSTEM disuser'ed for yeaqrs with no ill affects. I ran with mine not disusered, but with nointeractive, no dialup, no batch etc. However, when I restructured my startup procedures to have spawned subprocesses and batch jobs, it was very inconvenient to have those restrictions and I re-enabled SYSTEM. ------------------------------ Date: Wed, 13 Jun 2007 23:41:54 GMT From: Tad Winters Subject: Re: BYPASS privilege !! Message-ID: JF Mezei wrote in news:12634$467036b6 $cef8887a$30475@TEKSAVVY.COM: > Bob Koehler wrote: >> I can't answer this one, but I can tell you that I ran a VMS >> system with SYSTEM disuser'ed for yeaqrs with no ill affects. > > > I ran with mine not disusered, but with nointeractive, no dialup, no > batch etc. > > However, when I restructured my startup procedures to have spawned > subprocesses and batch jobs, it was very inconvenient to have those > restrictions and I re-enabled SYSTEM. > I ran with no restrictions on SYSTEM on several systems for years. I had set the password to some random long string to which I paid no attention when I set it. I would generally submit (re)start procedures for MultiNet, Samba, and even Watcher on occasion, under SYSTEM. If auditors asked, I always told them it was necessary for the proper operation of the system. Besides, I had managers who were not part of IT who seemed to always be allowed to retain SETPRV by going to the CIO. You'd have thought that wouldn't fly between SOX and HIPAA audits, but it's still like that, and I'm no longer an employee. ------------------------------ Date: Wed, 13 Jun 2007 22:47:10 -0700 From: DeanW Subject: Re: BYPASS privilege !! Message-ID: <3f119ada0706132247n7b69643bm5bd7c2cf82627e2e@mail.gmail.com> On 6/11/07, Richard B. Gilbert wrote: > JF Mezei wrote: > > In the end, isn't it still true that for a functional system, you still > > need to trust at least one system manager who could still wreak havok on > > your system if he truly wanted to ? > > > > Or can a system truly be locked down to a point where the system manager > > cannot do his job without supervision from the security folks ? > > Yes, it can! It may take me days to remember exactly what it's called > but there is a secondary password that can be required to log in to an > account; IOW two passwords, only one of which is known to the system > manager. I've never known a site that actually used this feature but > it's there! $ HELP SET PASS /SYSTEM or HELP SET PASS /SECONDARY: [snip happened] The /SECONDARY and /SYSTEM qualifiers are incompatible. So you can set secondary passwords... but possibly not for SYSTEM. ------------------------------ Date: Wed, 13 Jun 2007 19:23:18 GMT From: Hal Kuff Subject: ES45 Mod 2 Service Bulletin Message-ID: There was a critical ES45 bulletin, riser card or backplane replacement in 2002 ... anyone remember or have that document? ------------------------------ Date: Wed, 13 Jun 2007 14:28:45 -0400 From: JF Mezei Subject: Re: help running OpenVMS on Itanium 2 2620 WinXP variant Message-ID: <78a6d$46703760$cef8887a$30475@TEKSAVVY.COM> David Turner, Island Computers wrote: > Can someone point us in the right direction to getting VMS up and running on > this RX2600? Put the unit on a table. Then place a DS10L on it and load VMS in the DS10L. This way, VMS will be running *on* the IA64 box. :-) ------------------------------ Date: Wed, 13 Jun 2007 15:32:25 -0400 From: "David Turner, Island Computers" Subject: Re: help running OpenVMS on Itanium 2 2620 WinXP variant Message-ID: <1370hhukttstu64@news.supernews.com> Tee Hee Day Job? Stick with it... Merci et Salutations,JF "JF Mezei" wrote in message news:78a6d$46703760$cef8887a$30475@TEKSAVVY.COM... > David Turner, Island Computers wrote: >> Can someone point us in the right direction to getting VMS up and running >> on this RX2600? > > Put the unit on a table. Then place a DS10L on it and load VMS in the > DS10L. This way, VMS will be running *on* the IA64 box. > > :-) ------------------------------ Date: Wed, 13 Jun 2007 14:39:36 -0400 From: JF Mezei Subject: Re: host based routing software? Message-ID: <17551$467039eb$cef8887a$4204@TEKSAVVY.COM> Anton Shterenlikht wrote: > Hello > > I'm trying to configure a cluster on ds10l under vms8.3. > When I run NET$CONFIGURE.COM and try to make my node a ROUTER I get a > warning: This is a DECnet thing. With just the "end node", DECNET can only use one interface. With ethernet as interface, you can decnet to any node on that ethernet. But if you had multiple ethernet interfaces to different ethernet segments, or some synchronous lines to far away sites, you would then need the "routing" capabilities enabled so that not only would this node be able to talk to other nodes on either interfaces, but would also be able to take traffic from a node on the ethernet and forward it to a node on the synchronous segment. This has nothing to do with TCPIP routing. And yes, originally, DEC had decided that you needed the DECnet routing to get a cluster alias. But you can have a good cluster without a cluster alias. Is that still the case or has the policy changed to allow a cluster alias now with the standard decnet licence ? ------------------------------ Date: Wed, 13 Jun 2007 19:49:09 +0000 (UTC) From: moroney@world.std.spaamtrap.com (Michael Moroney) Subject: Re: More TCPIP nonsense Message-ID: Ron Johnson writes: >Disregarding the fact that this system doesn't have a QA cluster >sitting right next to it, since when is disabling a G*d D*mned >network service supposed to *crash* (I said *CRASH*, hard) a machine? That shouldn't happen of course, but you should know that in many cases, VMS will *deliberately* crash the system when it detects an inconsistancy that may corrupt data. If you look at the source of a VMS driver or something, they're often loaded with BUG_CHECK statements. There's usually an associated comment as what was detected, which is a great help for whoever analyzes the problem. Deliberate crashes actually make VMS more reliable. First, a bug is less likely to get into a released version, second, if it does, people like yourself *complain*, and it gets fixed. >Christ on a stick! Windows is more frickin' reliable than that! >Not to mention Linux (and even FreeBSD). How often does an inconsistancy go undetected in Windows or something, say something gets passed a FOO structure when it should get a BAR structure, and it silently scribbles BAR elements all over a FOO structure, and you get undetected data corruption or a mystery crash some time later. VMS usually writes the type of data structure into system data structures themselves, so a driver can check that an IRP passed to it really is an IRP. Which do you prefer, a crash or silent data corruption? Having said that, yes, the quality of TCPIP on VMS is much less than VMS itself. I posted a gripe here a few days ago. ------------------------------ Date: Thu, 14 Jun 2007 10:44:13 +1000 From: Jim Duff Subject: Re: More TCPIP nonsense Message-ID: <46708f60@dnews.tpgi.com.au> Ron Johnson wrote: > On 06/12/07 20:52, Jim Duff wrote: >> Ron Johnson wrote: >>> ES40 >>> Alpha VMS 8.2 >>> TCPIP v5.5-1 >>> >>> When our SysAdmin tried to disable the RSH service about a half hour >>> ago, the box *instantly* crashed. (Hasn't brought the box up, because >>> we need RSH disabled.) >>> >>> VMS might not get daily patches, but all our Alphas sure do seem to >>> crash with an inordinate frequency. >>> >>> You know, maybe VMS *should* get daily patches. It might not crash as >>> often. >>> >>> $ SET FACE/MOUTH=FROWN=LARGE >>> >> >> Alpha OpenVMS 8.2 with all patches except UPDATE-V0700 and DRIVER-V0200 >> TCPIP 5.5-1 >> >> RSH Configuration >> >> Service is defined in the SYSUAF. >> Service is defined in the TCPIP$SERVICE database. >> Service is enabled on specific node. >> Service is started. >> >> RSH configuration options: >> >> 1 - Enable service on all nodes >> 2 - Disable service on this node >> >> 3 - Stop service on this node >> 4 - Disable & Stop service on this node >> >> [E] - Exit RSH configuration >> >> Enter configuration option: 4 >> %TCPIP-I-INFO, service disabled >> %TCPIP-I-INFO, logical names deleted >> %TCPIP-I-INFO, image SYS$SYSTEM:TCPIP$RSH.EXE deinstalled >> %TCPIP-I-INFO, image SYS$SYSTEM:TCPIP$RCP.EXE deinstalled >> %TCPIP-S-SHUTDONE, TCPIP$RSH shutdown completed >> >> >> Works for me. > > @SYS$STARTUP:RSH_SHUTDOWN.COM I assume you mean @SYS$STARTUP:TCPIP$RSH_SHUTDOWN? Same test system as my prior reply: $ @sys$manager:tcpip$rsh_shutdown %TCPIP-I-INFO, service disabled %TCPIP-S-SHUTDONE, TCPIP$RSH shutdown completed $ Again, it works no problems. > >> What's the crash footprint? > > He was up really late last night, and hasn't had a chance to analyze the > dump yet. > Looking forward to seeing at least a CLUE CRASH... Jim -- www.eight-cubed.com ------------------------------ Date: Wed, 13 Jun 2007 20:53:17 -0500 From: Ron Johnson Subject: Re: More TCPIP nonsense Message-ID: On 06/13/07 19:44, Jim Duff wrote: > Ron Johnson wrote: >> On 06/12/07 20:52, Jim Duff wrote: >>> Ron Johnson wrote: >>>> ES40 >>>> Alpha VMS 8.2 >>>> TCPIP v5.5-1 >>>> >>>> When our SysAdmin tried to disable the RSH service about a half hour >>>> ago, the box *instantly* crashed. (Hasn't brought the box up, because >>>> we need RSH disabled.) >>>> >>>> VMS might not get daily patches, but all our Alphas sure do seem to >>>> crash with an inordinate frequency. >>>> >>>> You know, maybe VMS *should* get daily patches. It might not crash as >>>> often. >>>> >>>> $ SET FACE/MOUTH=FROWN=LARGE >>>> >>> Alpha OpenVMS 8.2 with all patches except UPDATE-V0700 and DRIVER-V0200 >>> TCPIP 5.5-1 >>> >>> RSH Configuration >>> >>> Service is defined in the SYSUAF. >>> Service is defined in the TCPIP$SERVICE database. >>> Service is enabled on specific node. >>> Service is started. >>> >>> RSH configuration options: >>> >>> 1 - Enable service on all nodes >>> 2 - Disable service on this node >>> >>> 3 - Stop service on this node >>> 4 - Disable & Stop service on this node >>> >>> [E] - Exit RSH configuration >>> >>> Enter configuration option: 4 >>> %TCPIP-I-INFO, service disabled >>> %TCPIP-I-INFO, logical names deleted >>> %TCPIP-I-INFO, image SYS$SYSTEM:TCPIP$RSH.EXE deinstalled >>> %TCPIP-I-INFO, image SYS$SYSTEM:TCPIP$RCP.EXE deinstalled >>> %TCPIP-S-SHUTDONE, TCPIP$RSH shutdown completed >>> >>> >>> Works for me. >> @SYS$STARTUP:RSH_SHUTDOWN.COM > > I assume you mean @SYS$STARTUP:TCPIP$RSH_SHUTDOWN? Yes, sorry. The machine I'm typing this from isn't my "work" machine. > Same test system as my prior reply: > > $ @sys$manager:tcpip$rsh_shutdown > %TCPIP-I-INFO, service disabled > %TCPIP-S-SHUTDONE, TCPIP$RSH shutdown completed > $ > > Again, it works no problems. Well, that's pretty much what what our SysAdmin expected also! :( >>> What's the crash footprint? >> He was up really late last night, and hasn't had a chance to analyze the >> dump yet. >> > > Looking forward to seeing at least a CLUE CRASH... I'll try tomorrow. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Wed, 13 Jun 2007 23:57:44 +0000 (UTC) From: david20@alpha2.mdx.ac.uk Subject: Re: OT: Question to Bob Message-ID: In article , John Santos writes: >david20@alpha2.mdx.ac.uk wrote: >> In article <1181477976.454093.231900@h2g2000hsg.googlegroups.com>, ultradwc@gmail.com writes: >> >>>On Jun 10, 6:48 am, davi...@alpha2.mdx.ac.uk wrote: >>> >>>>The end result in both cases is the same - suffering for Mankind. However >>>>whereas in Greek Mythology Zeus' motivation is explicitly to punish Mankind >>>>it is unclear why God sets up Adam and Eve in Genesis. >>> >>>It is very clear ... God setup created Adam in his image, and >>>like the angels in heaven were tempted and had to prove >>>themselves, Adam and Eve had to do the same >> >> >> A test is probably a reasonable supposition but as far as I can see from >> Genesis a supposition is all it is. >> Now if it is a test what is God testing ? Is it that Adam and Eve would obey >> him and not eat from a particular tree if ordered not to ? >> Is it that they cannot be tempted to eat from said tree ? >> If the latter then the serpent is carrying out God's wishes in providing >> temptation and hence it seems strange for God to punish the serpent. >> If the former then the serpent in providing temptation is interfering and >> invalidating the test. >> >> In any case why use that particular tree ? Ordering them not to eat from a >> tree which God created which would ,say, turn their skin green would be as >> good a test ? Why plant the tree of knowledge of good and evil in the garden >> and use that for the test - it seems foolhardy. >> >> Unless of course the point of the test was for Adam and Eve to disobey God and >> gain that Knowledge - a rite of passage to maturity. But then if that was the >> case then God's subsequent punishments seem excessive. >> >> > >I think the point is they acquired knowledge of good and evil and hence >responsibility. Before that they were innocent animals. The test wasn't >that they ate the fruit, but that when they were asked about it, they >hid and lied, thus showing that they knew they had done wrong. In other >words, they started out as innocents, and changed over time to become >self-aware and capable of making moral choices. This passage proves >the Bible supports evolution, and that humans descended from animals. > If they were innocent animals which didn't understand that disobeying God was wrong before eating the fruit then God shouldn't punish them for eating the fruit since that test would be meaningless since as you say at the time they couldn't make a moral choice. However if they were that innocent before eating the fruit then I wouldn't want them tending my Garden - in their innocence they would probably destroy the garden without realising that it was wrong. As to punishing them for lying afterwards. Did Adam and Eve lie to God ? When asked whether he has eaten the fruit Adam replied that Eve had given him the fruit to eat. When God asked Eve she admitted it and said she had been beguiled by the Serpent. According to the earlier text in Genesis this is exactly what had happened. >>>... God even >>>told them in His warning that if you eat from that tree you will >>>die ... it couldn't be much clear or simpler than that, >> >> >> Actually the warning is >> >> Genesis 2:17 >> >> " But of the tree of the knowledge of good and evil, thou shalt not eat of it: >> for in the day that thou eatest thereof thou shalt surely die. >> " >> >> Which is a bit strange since Adam didn't die on that day or for quite a few >> days after >> > >I don't know why I'm responding to this thread, :-( but... > >Clearly, the word "day" in the Bible doesn't mean 864000000000 >100ns VMS clock ticks. He didn't literally die that day, but he >became aware of his own mortality. > To me it sounds more like a not particularly bright white-lie warning to a child Don't eat that fruit it's poisonous. A variant of the "Don't make faces - if the wind changes you'll be stuck like that" lie. David Webb Security team leader CCSS Middlesex University > >> Genesis 5:5 >> >> " >> And all the days that Adam lived were nine hundred and thirty years: and he >> died. >> " >> >> Of course if he and Eve had died immediately after eating the forbidden fruit >> then there would, according to the Bible, be no Human race since at that time >> they had no children. >> >> Alternatively if Adam and Eve had resisted temptation would they still be >> there in the Garden immortal and innocent on their own tending the Garden ? >> Would both Heaven and Hell be empty of souls ? >> >> >> David Webb >> Security team leader >> CCSS >> Middlesex University >> >> >> >> >>>but they >>>instead chose to believe the lies of the prince of lies ... the >>>temptation was the same on that the devil uses on everyone, >>>pride of life ... that you will be like God, which is want he >>>wanted and still wants ... everyone has to choose their master, >>>and knowing what I know, I would choose a loving God every >>>time over hell and the lake of fire ... God has a set of rules that >>>must be followed or evil results ... and look all around you today >>>at the results of breaking Gods rules ... no way do I call this >>>heaven! If you love God, your creator, you will do what He asks, >>>but if you insist on being God, then you will be put outside His >>>universe in the lake of fire ... God does not want a bunch of mind >>>numbed robots serving Him, which is why even though He knows >>>all He allows us to make our own choice on this matter ... where >>>you end up will be by your own choice ... God has proved His love >>>for you by sending His only Son to die for your sins ... and when >>>His Son soon returns, He promises a world of no tears, no sickness >>>and no sorrow ... we have all of these now because of Adam and >>>Eves and our own continued revolt againset God by wanting to >>>be one, and not letting Him be ... your current predicament is the >>>result of sin ... the only question is, who will be your God ... >>> >>>why would you want to not serve your Creator and go againset >>>Him? You can read about the life of His Son from many >>>witnesses who tell of Jesus who did nothing but love and heal >>>people, but they instead nailed Him to a cross! He saind those >>>who have seen Him have seen the Father ... so God is love ... >>> >>>the prince of lies on the other hand is trying to pull you apart >> >>>from your loving Creator ... he is not called the destroyer for >> >>>nothing ... he is out to kill and destroy you and all of man >>>because he does not want you to spend eternity with God >>>in heaven ... this is who Adam and Eve listened to, and God >>>let them be their own gods, and you now are seeing the >>>results of sin ... sin destroys ... >>> >>>I think the first choice is obvious, but many will choose the >>>latter unfortunately but will have nobody to blame but >>>themselves ... God is allowing YOU to choose ... choose >>>life so you do not end of in the group of those who >>>are wailing and knashing teeth, because then it will be too >>>late! >>> >>> >>> >>> > > >-- >John Santos >Evans Griffiths & Hart, Inc. >781-861-0670 ext 539 ------------------------------ Date: Wed, 13 Jun 2007 18:13:39 GMT From: Tad Winters Subject: Re: Question for the Group Message-ID: Michael Kraemer wrote in news:f4oasv$9q0$01$2@news.t-online.com: > Well, I'm not in HPs shoes and I have no business > in defending their actions, I just find their strategy comprehensible. > Why should they put extra effort on such a tiny fraction of their > business ? Even if VMS revenue was several times larger at the time of > the Compaq takeover, it still was dwarfed by HPs ink ocean. Then the answer must be to drop _all_ other products and just sell ink, right? ------------------------------ Date: Wed, 13 Jun 2007 11:27:06 -0700 From: AEF Subject: Re: Question for the Group Message-ID: <1181759226.493315.138820@d30g2000prg.googlegroups.com> On Jun 13, 4:46 am, Michael Kraemer wrote: > AEF schrieb: > > > > > Can you please supply a link? I missed it. > > It's the well-known webcast transcription: > > http://mail.openvms.org:8100/Lists/news/Message/18.html Thanks! But it wouldn't let me in: Error: Must authenticate before using this service. :-( Is there some other way I can read this? [...] AEF ------------------------------ Date: Wed, 13 Jun 2007 15:00:30 -0400 From: JF Mezei Subject: Re: Question for the Group Message-ID: <9418c$46703ed1$cef8887a$32591@TEKSAVVY.COM> Ron Johnson wrote: > Tech comebacks are *extraordinarily* rare. It needs a visionary > leader like Steve Jobs or Lou Gerstner. If Hurd were to listen to us and fire/isolate those people below him, he too could appear to be a visionary leader and make things happen. Gerstner wasn't the vision. He was the one with ears and with the experience of knowing who to listen to. The impression I have is that Hurd is gullible and is being taken for a ride by people below him who have an agenda. > And even though Apple has come back from the brink, and is > profitable, the Mac still has only ~5% market share back in the days where MACs still had about 12% share, Apple was the largest maker of personal computers. (the wintel market may have had close to 90%, but because it was so fragmented, there were no single vendor with more than 10% market share). And even if Apple only has 5%, it is still profitable, and more importantly, Apple has managed to put OS-X on the radar and it is being followed by the press with good press covereage. (Says JF who typed this as he was opening his just received box for OS-X :-) > is less than in the late 80s). It's big cash cow is the iPod, which > is why "Computer" isn't part of Apple's name anymore. Apple is broadening itself into walkmans and now phones too. Note that the iphone runs OS-X. Carly also wanted HP to become a consumer goods company. She just didn't have the imagination, innovation and guts to go it it in a real way like Apple, so she decided to take the easy road and affix "TV Set" stickers on computer monitors. ------------------------------ Date: Wed, 13 Jun 2007 23:50:26 GMT From: Tad Winters Subject: Re: Question for the Group Message-ID: JF Mezei wrote in news:9418c$46703ed1$cef8887a$32591@TEKSAVVY.COM: > back in the days where MACs still had about 12% share, Apple was the > largest maker of personal computers. (the wintel market may have had > close to 90%, but because it was so fragmented, there were no single > vendor with more than 10% market share). > > And even if Apple only has 5%, it is still profitable, and more > importantly, Apple has managed to put OS-X on the radar and it is > being followed by the press with good press covereage. In the early 90's, I kept wishing that DEC would partner with Apple and make it the chosen desktop face. In fact, a shared venture to build a VMS workstation with some Apple applications would have been a real bringing together of the simpleness executives like and the power desired by the scientist crowd. ------------------------------ Date: Wed, 13 Jun 2007 20:43:18 -0500 From: Ron Johnson Subject: Re: Question for the Group Message-ID: On 06/13/07 18:50, Tad Winters wrote: > JF Mezei wrote in > news:9418c$46703ed1$cef8887a$32591@TEKSAVVY.COM: > >> back in the days where MACs still had about 12% share, Apple was the >> largest maker of personal computers. (the wintel market may have had >> close to 90%, but because it was so fragmented, there were no single >> vendor with more than 10% market share). >> >> And even if Apple only has 5%, it is still profitable, and more >> importantly, Apple has managed to put OS-X on the radar and it is >> being followed by the press with good press covereage. > > In the early 90's, I kept wishing that DEC would partner with Apple and > make it the chosen desktop face. In fact, a shared venture to build a VMS > workstation with some Apple applications would have been a real bringing > together of the simpleness executives like and the power desired by the > scientist crowd. Great minds must think alike! When I was working for my fist "VMS company", I got a Mac and thought that the two "we're #2, we try harder" companies should (although that wasn't the the exact thought I had back then) "synergize" for the same reason you specified. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Wed, 13 Jun 2007 18:52:18 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: SMTP.CONFIG: Reject-Mail-From: for part of an address? Message-ID: In article , david20@alpha2.mdx.ac.uk writes: > Are you sure you don't have any users of those domains who might send via an > ISP but set the From address to the address in your domain so that replies are > sent to their account on your domain ? If they also send a copy of the message > they are sending to their account in your domain it will appear to come from > outside with an address in your domain. (And of course this will also happen if > they send to someone else in your domain). This is just my hobbyist cluster, so in that case, yes, I am sure. > Also there are some mailing lists which instead of sending mail from the list > with the from address set as the listname set the from address to that of the > person who sent the mail message. If one of your users is a member of such a > list and sends a mail message to the list then the copy of the mail message > sent back to them will also appear to come from outside but be from their > address in your domain. Thanks; I'll have to think about that one. I think most of the lists in use don't do it that way, but I'll have to check. ------------------------------ Date: Wed, 13 Jun 2007 18:53:51 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: SMTP.CONFIG: Reject-Mail-From: for part of an address? Message-ID: In article <5d904tF342tfpU1@mid.individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes: > Users should not be playing with the From: address. That is what the > Reply-To: address is for. Our MTA normalizes all From: addresses so > this would not work anyway. In many cases, yes. In some cases, when sending email to a list etc, it expects a certain From: address. Since it is reasonable to have more than one domain on a cluster, it is OK to use TCPIP$SMTP_FROM. If necessary, one can disable this for users. ------------------------------ Date: Wed, 13 Jun 2007 16:52:38 -0400 From: "Main, Kerry" Subject: RE: Story Time Message-ID: > -----Original Message----- > From: Bob Koehler [mailto:koehler@eisner.nospam.encompasserve.org] > Sent: June 12, 2007 9:22 AM > To: Info-VAX@Mvb.Saic.Com > Subject: RE: Story Time >=20 > In article > t>, "Main, Kerry" writes: >=20 > > > > So, if you have your Help desk and junior level 1 staff supporting > many > > different platforms, would you not want them to have a point and > click > > environment vs giving them DCL or shell prompt access with elevated > > priv's to do the things they need to do on all the platforms they > > support? >=20 > No. I would want them to learn what they need to know and use the > OS' features to make sure they can do it without elevated > privileges. Having a support staff that can't be trusted with DCL > is like having an electrician who can't be trusted to run wire. I hear what you are saying, but in large environments, the level 1 staff do basic admin stuff on Solaris, AIX, Windows, OpenVMS etc ... may even do odd mainframe thing or two. Point is that while I agree it is a good thing for level 1's to learn the OS, sometimes its just not practical when their primary role is to add / modify the odd user account, kick start stalled queues, log calls and take information down and then try and figure out which Level 2 support resource the call should go to. Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Wed, 13 Jun 2007 19:19:59 GMT From: Chris Sharman Subject: Re: VMS analogue of FBSD and linux hier(7) man pages Message-ID: david20@alpha2.mdx.ac.uk wrote: > The basic directory structure of the VMS system disk is well defined. > The only complication is that the directory structure is duplicated so as to > provide system-specific roots and a cluster-common root. Just one nit-pick: vms$common (or syscommon) is not necessarily a cluster common root, but is a common root to all systems sharing that boot disk (which may or may not be the whole cluster). In my two node cluster (LAVC), I have two boot disks, and therefore one vms$common directory for each machine. It would be nice if vms supported a true cluster common directory, and in fact I've got my system set up that way, so that early in the boot, the cluster common disk is mounted, and sys$sysroot redefined to add a third equivalence. Without it I'd have to maintain two complete sets of systartup & associated files. The other distinguishing feature of the sys$sysroot setup, by the way, is that the 'common' files (programs and other distributed files etc) tend to go in the syscommon root, logs and node-specific files go in the specific root, and com files and other non-hp/compaq/dec stuff goes in my cluster common. Do other people run something similar, or do they all use a single boot disk (in a LAVC?), or maintain several separate boot disks - it's always seemed a bit clunky to me. On VMS 7.3-1, btw, although I'm not aware of any significant changes in this area between recent versions. Chris ------------------------------ Date: 13 Jun 2007 21:27:03 -0400 From: Rich Alderson Subject: Re: VMS analogue of FBSD and linux hier(7) man pages Message-ID: bill@cs.uofs.edu (Bill Gunshannon) writes: > In article , > John Santos writes: >> Bill Gunshannon wrote: >>> In article <20070612113434.GA70321@mech-aslap33.men.bris.ac.uk>, >>> Anton Shterenlikht writes: >>>> On FBSD and linux (at least) the hier(7) man pages give a brief overview >>>> of the filesystem, including all major system directories and their >>>> intended use. I refer to these quite often. Is there anything similar on >>>> VMS? >>> I am sure someone will correct me if I am wrong, :-) but I don't think the >>> VMS filesystem would be considered "hierarchical" which would preclude such >>> a listing. You are correct, even though someone incorrectly said otherwise. I'll explain below. >> Okay, will do :-) AFAIK, "hierarchical" in the context of file systems >> basically means you can nest directories. By this definition, VMS (ODS-2 >> and ODS-5) is most definitely hierarchical. Yes, in so far as that goes, but it does not address the main point. The Unix-related family of operating systems use a single hierarchical filesystem, as did (soon again to be does) Multics. There is a single system root directory, under which all other directories are found; other filesystems may exist on subsidiary disks or partitions of disks, but they are attached to directories located within the root hierarchy. VMS started out with a non-hierarchical filesystem (now called ODS-1) which was identical to that of RSX-11{A,B,C,D,M,S} and similar to those of Tops-10 and TSS/8 (Tops-10 inspired), and IIRC those of the 18-bit family. (Tops-10 added "SubFile Directories" eventually, so some hierarchicality, but this was not very cleanly done. IMAO.) At some point in its history, IIRC v4, VMS adopted a hierarchical model for its filesystems, on a per-filesystem basis, similar though not identical to the model of TENEX and Tops-20: There is a root directory for each filesystem, but mounting a filesystem does not require that it be associated in any way with a directory on a central filesystem. > Well, because I would really like to see someone with more experience > address this let me clarify what I said above. > I know you can nest directories in VMS, but is there any portion > of this nesting that is common to all VMS systems or is it strictly > user preference? While it would be possible to put Unix files anywhere, > there is a hierarchy that is considered standard and upon which a > number of assumptions have been made. I don't know the answer to this; I can only point out that in the similar Tops-20 filesystem there is an assumption built into the monitor that UNLESS EXPLICITLY CHANGED there is a directory pointed to by the logical name SYSTEM: and a directory pointed to by the logical name SYS:. There are no further hierarchical requirements. > Even if many of us think VMS is slowly dying, there is still much > some of us would like to learn about it. :-) Indeed! -- Rich Alderson | /"\ ASCII ribbon | news@alderson.users.panix.com | \ / campaign against | "You get what anybody gets. You get a lifetime." | x HTML mail and | --Death, of the Endless | / \ postings | ------------------------------ Date: Wed, 13 Jun 2007 22:26:32 -0400 From: "Richard B. Gilbert" Subject: Re: VMS analogue of FBSD and linux hier(7) man pages Message-ID: <4670A758.2020501@comcast.net> Rich Alderson wrote: > bill@cs.uofs.edu (Bill Gunshannon) writes: > > >>In article , >> John Santos writes: > > >>> Bill Gunshannon wrote: >> > >>>>In article <20070612113434.GA70321@mech-aslap33.men.bris.ac.uk>, >>>> Anton Shterenlikht writes: >>> > >>>>>On FBSD and linux (at least) the hier(7) man pages give a brief overview >>>>>of the filesystem, including all major system directories and their >>>>>intended use. I refer to these quite often. Is there anything similar on >>>>>VMS? >>>> > >>>>I am sure someone will correct me if I am wrong, :-) but I don't think the >>>>VMS filesystem would be considered "hierarchical" which would preclude such >>>>a listing. >>> > > You are correct, even though someone incorrectly said otherwise. I'll explain > below. > > >>>Okay, will do :-) AFAIK, "hierarchical" in the context of file systems >>>basically means you can nest directories. By this definition, VMS (ODS-2 >>>and ODS-5) is most definitely hierarchical. >> > > Yes, in so far as that goes, but it does not address the main point. > > The Unix-related family of operating systems use a single hierarchical > filesystem, as did (soon again to be does) Multics. There is a single system > root directory, under which all other directories are found; other filesystems > may exist on subsidiary disks or partitions of disks, but they are attached to > directories located within the root hierarchy. > > VMS started out with a non-hierarchical filesystem (now called ODS-1) which was > identical to that of RSX-11{A,B,C,D,M,S} and similar to those of Tops-10 and > TSS/8 (Tops-10 inspired), and IIRC those of the 18-bit family. (Tops-10 added > "SubFile Directories" eventually, so some hierarchicality, but this was not > very cleanly done. IMAO.) > > At some point in its history, IIRC v4, VMS adopted a hierarchical model for its > filesystems, on a per-filesystem basis, similar though not identical to the > model of TENEX and Tops-20: There is a root directory for each filesystem, but > mounting a filesystem does not require that it be associated in any way with a > directory on a central filesystem. > > >>Well, because I would really like to see someone with more experience >>address this let me clarify what I said above. > > >>I know you can nest directories in VMS, but is there any portion >>of this nesting that is common to all VMS systems or is it strictly >>user preference? While it would be possible to put Unix files anywhere, >>there is a hierarchy that is considered standard and upon which a >>number of assumptions have been made. > > > I don't know the answer to this; I can only point out that in the similar > Tops-20 filesystem there is an assumption built into the monitor that UNLESS > EXPLICITLY CHANGED there is a directory pointed to by the logical name > SYSTEM: and a directory pointed to by the logical name SYS:. There > are no further hierarchical requirements. I would answer by saying that the structure of the system disk is common to all VMS Systems. It has been this way since at least VMV V3.6 (ca. 1984). There are "system roots": SYS0 by default for a standalone system. SYSE is conventionally standalone backup. SYSF is used for installations and upgrades. SYS1-SYSC are optional on a VMS Cluster system disk; one root for each system in the cluster. The "system root" directories hold files specific to a particular cluster member. All the standard system directories are twinned in SYS$SPECIFIC and SYS$COMMON trees. the SYS$SPECIFIC tree has files that are specific to a particular system while the SYS$COMMON tree has files common to all. I don't believe I've ever seen more than three systems booting from the same system disk although, in principle, you could have as many as thirteen. A cluster could have one system disk for each node in the cluster or small cluster could share a common system disk (disk loading would make this impractical in a large cluster) imagine fourteen nodes beating up the same system disk, it would run like a dog! ------------------------------ Date: Thu, 14 Jun 2007 04:25:53 +0200 From: "P. Sture" Subject: Re: VMS analogue of FBSD and linux hier(7) man pages Message-ID: In article , david20@alpha2.mdx.ac.uk wrote: A good summary David. Just one nitpick, for accuracy: > Logical names such as SYSEXE are then used to point at both the > > SYSEXE directory in the system-specific root for a particular node and the > SYSEXE directory in the cluster-common root Should read as "Logical names such as SYS$SYSTEM are the used to point at both the SYSEXE directory in the system-specific root for a particular node and the SYSEXE directory in the cluster-common root" -- Paul Sture ------------------------------ Date: Wed, 13 Jun 2007 22:01:03 -0500 From: Ron Johnson Subject: Re: VMS analogue of FBSD and linux hier(7) man pages Message-ID: On 06/13/07 21:26, Richard B. Gilbert wrote: [snip] > same system disk although, in principle, you could have as many as > thirteen. A cluster could have one system disk for each node in the > cluster or small cluster could share a common system disk (disk loading > would make this impractical in a large cluster) imagine fourteen nodes > beating up the same system disk, it would run like a dog! Only if the page/swap files, or some other important system files (audit logs, etc) were on it, no? -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Wed, 13 Jun 2007 20:02:09 -0700 From: Ken Fairfield Subject: Re: VMS analogue of FBSD and linux hier(7) man pages Message-ID: <5dbphdF347sr7U1@mid.individual.net> Richard B. Gilbert wrote: [...] > I would answer by saying that the structure of the system disk is common > to all VMS Systems. It has been this way since at least VMV V3.6 (ca. > 1984). There are "system roots": SYS0 by default for a standalone > system. SYSE is conventionally standalone backup. SYSF is used for > installations and upgrades. SYS1-SYSC are optional on a VMS Cluster > system disk; one root for each system in the cluster. The "system root" > directories hold files specific to a particular cluster member. All the > standard system directories are twinned in SYS$SPECIFIC and SYS$COMMON > trees. the SYS$SPECIFIC tree has files that are specific to a > particular system while the SYS$COMMON tree has files common to all. I > don't believe I've ever seen more than three systems booting from the > same system disk although, in principle, you could have as many as > thirteen. Haven't been around much, eh? :-) :-) > A cluster could have one system disk for each node in the > cluster or small cluster could share a common system disk (disk loading > would make this impractical in a large cluster) imagine fourteen nodes > beating up the same system disk, it would run like a dog! At my previous, previous employment, we had 2 Alpha 4100's on one system disk, and 3 VAX 6000-class machines on another (of course) system disk, all on the CI. But we also had 30 VAXstations (3100's and 4000 VLC's) _also_ booting from the VAX system disk. In other words, there were 33 or so system roots on the VAX system disk. I dont believe there is any hard limit on the number of systems, even "big" systems, booting from the same disk. The real limits are disk space and performance. First, you don't want that single volume handling all the paging (and swapping), but that is routinely handled by placing only a small (or no) pagefile on the system disk and installing additional pagefiles on additional separate disks. (Oh, and the VAXstations in the above cluster used local disks for pagefiles, of course.) Similarly, there just isn't room of dump files for very many systems on a single disk. But again, that has been addressed by DOSD. The remaining problem is I/O performance of the many systems to key files on a single volume (typically in SYS$SYSTEM and SYS$LIBRARY). At some point, and depending on the usage models, etc., you may very well prefer to have multiple system disks. As with everything else, it's a set of trade offs. But I don't believe there is any architectural limit to the number of nodes using a single system disk (other than supported cluster sizes and the maximum system specific root being SYSFF, i.e., 255...). -Ken -- Ken & Ann Fairfield What: Ken dot And dot Ann Where: Gmail dot Com ------------------------------ Date: Wed, 13 Jun 2007 23:58:23 -0400 From: "Richard B. Gilbert" Subject: Re: VMS analogue of FBSD and linux hier(7) man pages Message-ID: <4670BCDF.3020600@comcast.net> Ron Johnson wrote: > On 06/13/07 21:26, Richard B. Gilbert wrote: > [snip] > >> same system disk although, in principle, you could have as many as >> thirteen. A cluster could have one system disk for each node in the >> cluster or small cluster could share a common system disk (disk >> loading would make this impractical in a large cluster) imagine >> fourteen nodes beating up the same system disk, it would run like a dog! > > > Only if the page/swap files, or some other important system files (audit > logs, etc) were on it, no? > How long would it take to boot thirteen nodes from the same system disk? You may assume that each node has its own page/swap disk. ------------------------------ Date: Thu, 14 Jun 2007 00:29:28 -0400 From: "Richard B. Gilbert" Subject: Re: VMS analogue of FBSD and linux hier(7) man pages Message-ID: <4670C428.6000802@comcast.net> Ken Fairfield wrote: > Richard B. Gilbert wrote: > [...] > >> I would answer by saying that the structure of the system disk is >> common to all VMS Systems. It has been this way since at least VMV >> V3.6 (ca. 1984). There are "system roots": SYS0 by default for a >> standalone system. SYSE is conventionally standalone backup. SYSF is >> used for installations and upgrades. SYS1-SYSC are optional on a VMS >> Cluster system disk; one root for each system in the cluster. The >> "system root" directories hold files specific to a particular cluster >> member. All the standard system directories are twinned in >> SYS$SPECIFIC and SYS$COMMON trees. the SYS$SPECIFIC tree has files >> that are specific to a particular system while the SYS$COMMON tree has >> files common to all. I don't believe I've ever seen more than three >> systems booting from the same system disk although, in principle, you >> could have as many as thirteen. > > > Haven't been around much, eh? :-) :-) > > > A cluster could have one system disk for each node in the > >> cluster or small cluster could share a common system disk (disk >> loading would make this impractical in a large cluster) imagine >> fourteen nodes beating up the same system disk, it would run like a dog! > > > At my previous, previous employment, we had 2 Alpha 4100's on one > system disk, and 3 VAX 6000-class machines on another (of course) > system disk, all on the CI. But we also had 30 VAXstations (3100's > and 4000 VLC's) _also_ booting from the VAX system disk. In other > words, there were 33 or so system roots on the VAX system disk. How did it perform? How long did it take to boot? Few of my previous employers could afford that much hardware or that many software licenses! My largest employer was the F.W. Dodge division of McGraw-Hill in Hightstown, NJ. We had twenty-five systems in the data center and approximately 100 field offices, each with its own VAX Cluster. The field offices all had a MicroVAX 3100 and one or more VAXstation 3100s. No cluster in the data center had more than three nodes or two system disks. They were the exception. My last employer had seven Alphas: 2 ES40s (clustered) 3 4100s (2 clustered), an Alphaserver 2100 and an Alphaserver 2000. So the largest cluster I've "seen" had ten or so nodes and would have been one of the larger McGraw-Hill/F.W. Dodge field offices. I never laid eyes on it; we managed these clusters remotely using a long forgotten product called RSM (Remote System Manager). While, in principle, it may be possible to run several dozen machines off the same system disk, it does not seem very practical. ------------------------------ Date: Thu, 14 Jun 2007 06:25:06 +0200 From: "P. Sture" Subject: Re: VMS analogue of FBSD and linux hier(7) man pages Message-ID: In article <4670A758.2020501@comcast.net>, "Richard B. Gilbert" wrote: > Rich Alderson wrote: > > bill@cs.uofs.edu (Bill Gunshannon) writes: > > > > > >>In article , > >> John Santos writes: > > > > > >>> Bill Gunshannon wrote: > >> > > > >>>>In article <20070612113434.GA70321@mech-aslap33.men.bris.ac.uk>, > >>>> Anton Shterenlikht writes: > >>> > > > >>>>>On FBSD and linux (at least) the hier(7) man pages give a brief overview > >>>>>of the filesystem, including all major system directories and their > >>>>>intended use. I refer to these quite often. Is there anything similar on > >>>>>VMS? > >>>> > > > >>>>I am sure someone will correct me if I am wrong, :-) but I don't think > >>>>the > >>>>VMS filesystem would be considered "hierarchical" which would preclude > >>>>such > >>>>a listing. > >>> > > > > You are correct, even though someone incorrectly said otherwise. I'll > > explain > > below. > > > > > >>>Okay, will do :-) AFAIK, "hierarchical" in the context of file systems > >>>basically means you can nest directories. By this definition, VMS (ODS-2 > >>>and ODS-5) is most definitely hierarchical. > >> > > > > Yes, in so far as that goes, but it does not address the main point. > > > > The Unix-related family of operating systems use a single hierarchical > > filesystem, as did (soon again to be does) Multics. There is a single > > system > > root directory, under which all other directories are found; other > > filesystems > > may exist on subsidiary disks or partitions of disks, but they are attached > > to > > directories located within the root hierarchy. > > > > VMS started out with a non-hierarchical filesystem (now called ODS-1) which > > was > > identical to that of RSX-11{A,B,C,D,M,S} and similar to those of Tops-10 > > and > > TSS/8 (Tops-10 inspired), and IIRC those of the 18-bit family. (Tops-10 > > added > > "SubFile Directories" eventually, so some hierarchicality, but this was not > > very cleanly done. IMAO.) > > > > At some point in its history, IIRC v4, VMS adopted a hierarchical model for > > its > > filesystems, on a per-filesystem basis, similar though not identical to the > > model of TENEX and Tops-20: There is a root directory for each filesystem, > > but > > mounting a filesystem does not require that it be associated in any way > > with a > > directory on a central filesystem. > > > > > >>Well, because I would really like to see someone with more experience > >>address this let me clarify what I said above. > > > > > >>I know you can nest directories in VMS, but is there any portion > >>of this nesting that is common to all VMS systems or is it strictly > >>user preference? While it would be possible to put Unix files anywhere, > >>there is a hierarchy that is considered standard and upon which a > >>number of assumptions have been made. > > > > > > I don't know the answer to this; I can only point out that in the similar > > Tops-20 filesystem there is an assumption built into the monitor that > > UNLESS > > EXPLICITLY CHANGED there is a directory pointed to by the logical > > name > > SYSTEM: and a directory pointed to by the logical name SYS:. > > There > > are no further hierarchical requirements. > > I would answer by saying that the structure of the system disk is common > to all VMS Systems. It has been this way since at least VMV V3.6 (ca. > 1984). There are "system roots": SYS0 by default for a standalone > system. SYSE is conventionally standalone backup. SYSF is used for > installations and upgrades. SYS1-SYSC are optional on a VMS Cluster > system disk; one root for each system in the cluster. The "system root" > directories hold files specific to a particular cluster member. All the > standard system directories are twinned in SYS$SPECIFIC and SYS$COMMON > trees. the SYS$SPECIFIC tree has files that are specific to a > particular system while the SYS$COMMON tree has files common to all. I > don't believe I've ever seen more than three systems booting from the > same system disk although, in principle, you could have as many as > thirteen. A cluster could have one system disk for each node in the > cluster or small cluster could share a common system disk (disk loading > would make this impractical in a large cluster) imagine fourteen nodes > beating up the same system disk, it would run like a dog! The beginnings of this structure came with V3.0. : VAX/VMS Version V3.0 26-APR-1982 16:21 Directory DBA2:[000000] 000000.DIR;1 BACKUP.SYS;1 BADBLK.SYS;1 BADLOG.SYS;1 BITMAP.SYS;1 CONTIN.SYS;1 CORIMG.SYS;1 INDEXF.SYS;1 SYS0.DIR;1 SYSEXE.DIR;1 SYSEXEMIN.DIR;1 SYSMAINT.DIR;1 VOLSET.SYS;1 Directory DBA2:<000000.SYSEXE> SYSBOOT.EXE;1 Total of 1 file. Directory DBA2:[SYS0] 001001.DIR;1 001002.DIR;1 SYSCBI.DIR;1 SYSERR.DIR;1 SYSEXE.DIR;1 SYSHLP.DIR;1 SYSLIB.DIR;1 SYSMAINT.DIR;1 SYSMGR.DIR;1 SYSMSG.DIR;1 SYSTEST.DIR;1 SYSUPD.DIR;1 where [001001] is equivalenced to [SYS0.SYSEXE] and [001002] is equivalenced to [SYS0.SYSMSG] $ show log sys$sysroot SYS$SYSROOT = "__DBA2:[SYS0.]" (system) Plug alert! The above taken from a V3.0 system running on SIMH http://simh.trailing-edge.com/ -- Paul Sture ------------------------------ Date: Wed, 13 Jun 2007 14:31:42 -0400 From: JF Mezei Subject: Re: Why partitioned disks on VMS would be useful Message-ID: <73d71$46703811$cef8887a$30475@TEKSAVVY.COM> Dave Gullen wrote: > Tried the LD utility? I also got such suggestions by email. Say I have a hard disk DQA0: with VMS on it. I create an LD container file in it to host a page file. When I shadow DQA0: with some other system, won't all writes to the LD container file end up being propagated to the other shadowset members ? Or does LDriver do its writing at such a low level that the shadowing software would be unaware of the activity inside the LD container file ? ------------------------------ Date: Wed, 13 Jun 2007 20:55:38 +0200 From: Jur van der Burg <"lddriver at digiater dot nl"> Subject: Re: Why partitioned disks on VMS would be useful Message-ID: <46703db6$0$321$e4fe514c@news.xs4all.nl> > When I shadow DQA0: with some other system, won't all writes to the LD > container file end up being propagated to the other shadowset members ? Yes. If the containerfile is on a shadowset then the contents of the container file are just treated like a normal file. > Or does LDriver do its writing at such a low level that the shadowing > software would be unaware of the activity inside the LD container file ? If you create a containerfile on a shadowset, see above. All data to or from LD devices will always go to the driver below LDdriver, that is the driver that handles the device where the containerfiles are located. Jur. JF Mezei wrote: > Dave Gullen wrote: >> Tried the LD utility? > > I also got such suggestions by email. > > Say I have a hard disk DQA0: with VMS on it. I create an LD container > file in it to host a page file. > > When I shadow DQA0: with some other system, won't all writes to the LD > container file end up being propagated to the other shadowset members ? > > Or does LDriver do its writing at such a low level that the shadowing > software would be unaware of the activity inside the LD container file ? ------------------------------ Date: Wed, 13 Jun 2007 20:52:14 +0200 From: Michael Unger Subject: Re: Why partitioned disks on VMS would be useful Message-ID: <5dat1hF33qve8U1@mid.individual.net> On 2007-06-13 17:51, "Stephen Hoffman" wrote: > [...] > > Laptops, the iPAQ Desktop, the thin clients, and the MicroVAX and ^^^^^^^ > VAXstation 2000 series had a single fixed-disk bay, but most anything > else I can think of within the low- to mid-range has multiple bays. [...] Not fully correct ... ;-) IBM had built (around 2001/2002) two series of notebooks ("A30" and "A30p") with the usual built-in hard disk drive and *two* "removable bays" in addition to that -- one bay usually equipped with an optical drive (CD or DVD), the other one usable for a second hard disk drive. (That's quite convenient for separating programs and data -- you can simply pull out the hard disk drive bay if you have to send the notebook to a service organization avoiding privacy issues completely.) Michael -- Real names enhance the probability of getting real answers. My e-mail account at DECUS Munich is no longer valid. ------------------------------ Date: Wed, 13 Jun 2007 22:11:59 +0000 (UTC) From: helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) Subject: Re: Why partitioned disks on VMS would be useful Message-ID: In article <729f0$466f8bd0$cef8887a$7819@TEKSAVVY.COM>, JF Mezei writes: > P. Sture wrote: > > CLUSTER_CONFIG.COM already puts the pagefile on the local disk for you, > > OK, in a standard satellite, you have the workstation with its local > disk used only for the pagefile and all "system" io done via > MSCP/ethernet to the boot node's system drive. > > My point was that if you could partition that workstation's only drive, > you could then have one logical disk being the system disk, and one > logical disk for the page file. The "system disk" could then be shadowed > with other workstations or servers. Yes, but to do this you need controllers which are more expensive and difficult to obtain than an additional physical disk! ------------------------------ End of INFO-VAX 2007.321 ************************