1 INFO-VAX	Thu, 17 Aug 2006	Volume 2006 : Issue 457       Contents: Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  Re: Alpha remembrance day  CDD/Repository Documentation  Re: CDD/Repository Documentation Re: Ken Olsen VAX  Re: Ken Olsen VAX  Re: Ken Olsen VAX  Re: Ken Olsen VAX   Re: Products in Operating System  Re: Products in Operating System  Re: Products in Operating System Samba / CIFS and ACLs  Re: Samba / CIFS and ACLs P Re: Seeking Data Archiving (BACKUP) Suggestions (was: Re: VAX/VMS site)  site)siP Re: Seeking Data Archiving (BACKUP) Suggestions (was: Re: VAX/VMS site) site)sitP RE: Seeking Data Archiving (BACKUP) Suggestions (was: Re: VAX/VMS site) site)sitP RE: Seeking Data Archiving (BACKUP) Suggestions (was: Re: VAX/VMSsite)  site)sitP Re: Seeking Data Archiving (BACKUP) Suggestions (was: Re: VAX/VMSsite)  site)sitP Re: Seeking Data Archiving (BACKUP) Suggestions (was: Re: VAX/VMSsite) site)site Shadow set problem Re: Shadow set problem Re: Shadow set problem Re: Shadow set problem Re: Shadow set problem Re: Shadow set problem RE: Speaking of Clusters: % Re: The race for 8086 servers is on ! % Re: The race for 8086 servers is on ! 1 Re: Unexpected output from IO AUTOCONFIGURE /FULL  Re: VAX/VMS site Re: VAX/VMS site& Re: VMS backup: competition from Apple& Re: VMS backup: competition from Apple  F ----------------------------------------------------------------------  % Date: Thu, 17 Aug 2006 09:02:22 +0200 ( From: Michael Kraemer <M.Kraemer@gsi.de>" Subject: Re: Alpha remembrance day/ Message-ID: <ec1493$anf$00$1@news.t-online.com>    Bob Koehler schrieb:\ > In article <e9ofvr$onl$02$1@news.t-online.com>, Michael Kraemer <M.Kraemer@gsi.de> writes: > < >>One might be tempted to speculate what would have happenedH >>if DEC never started alpha development. If they'd just bought half of H >>Mips and continued with Ultrix/MIPS, making it a more viable platform. > I >    Selecting a different hardware platforms to manufacture would never   >    have saved DEC.    B Ultrix/Mips wouldn't have been a different, new hardware platform,: but one they already had. And one which at least partially# satisfied the demands of that time. 9 Developing alpha plus porting VMS to alpha plus inventing 6 a new Unix for alpha (plus later porting WNT to alpha)5 was an uphill battle that finally killed the company.   7 >    They didn't learn what Billy knew:  the money was   >    in the software.   @ As far as Billy is concerned: the money is in market domination.  D >    DEC would have stayed alive only if they had kept VMS customersG >    happy by putting VMS on cheaper platforms instead of letting cheap F >    UNIX RISC and Windows Intel system steal all their VMS customers.  G If DEC managed to steer the defectors to their *UNIX* and WNT platforms   the company might have survived.  F >    DEC didn't have to manufacture those platforms to make money.  KO >    just thought he did.  >   5 IBM and Sun survive with own platforms plus software.    ------------------------------    Date: 17 Aug 2006 02:43:04 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayC Message-ID: <1155807784.528880.162010@i42g2000cwa.googlegroups.com>    Richard B. Gilbert wrote:  > Sharon wrote:  > ` > > In article <44E0AEF4.ADF7A446@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > >  > > G > >>Read up "Elephants CAN Dance" by Lou Gerstner. IBM was in far worse I > >>shape than Digital, yet, Gerstner was able to turn the company around G > >>big time exactly by stopping the slash and burn that had begun just  > >>before him.  > >>I > >>Both IBM and Digital had become uncompetitive because of their prices I > >>and attitudes towards customers. Firing a gazillion employees doesn't L > >>magically reduce prices on your price list. But it does prevent you from6 > >>making sales when you no longer had a sales force. > >  > > I > > 	Have anay of you read "DEC is Dead, Long Live DEC"?  Sorry, I forget L > > the author's name, but it's available on amazon.  I don't like the titleQ > > because it reeks of OS religious wars, but it's really a story of how DEC was # > > started, grew, and fizzled out. I > > 	I found it interesting that when the company reached a certain size, N > > people started spending more and more time in CYA activities and corporateO > > politics and less time being technically productive.  It mentioned that Ken Q > > tried several times to stop this, but he had no clue how to do it (and didn't Q > > realize that his own personality caused some of it) so he was very frustrated  > > by the time he bailed out.E > > 	It also talked about how Ken and his management team were having S > > trouble reading the market in the 1980's.  They still let various people try to S > > develop what they thought would be successful products, but then canned many of M > > them too early and let a few bad ones go to market.  I'm not sure why the R > > culture of "try it and see what happens" worked in the early days but actuallyS > > damaged the company later on.  Perhaps because by then they had a reputation to = > > uphold and things like the DEC Rainbow tarnished that...?  > F > The Rainbow was a fairly decent PC.  The problems were price, price,D > price, and the lack of an Open bus structure.  IIRC you could haveG > either a hard disk controller or a network interface but not both AND F > both were DEC proprietary.  DEC offered, for $2200, a hard disk thatG > could be bought elsewhere for about $300.   DEC offered a set of 256K D > RAM chips for $700; I bought mine on the open market for $33.  TheI > memory expansion daughter board was another $700.  (I bought a used one  > for far less than that!)  D I remember playing with a Rainbow when they were first launched. TheG first impression was that it was very nicely engineered, the second was D the sharp intake of breath when the sales person told me how much it cost.   C Compared with IBM and Compaq PC's the Rainbow was superiour from an E engineering standpoint, the problem was that good design did not sell  PC's.   + Price and RAM/CPU/DISK/SCREEN features did.   7 Because of this the DEC Rainbow was engineered to fail.    Regards  Andrew Harrison    ------------------------------    Date: 17 Aug 2006 02:55:54 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayB Message-ID: <1155808554.424905.247650@74g2000cwt.googlegroups.com>   JF Mezei wrote:  > Andrew wrote: I > > The only fantasy here is the Bob Palmer killed Alpha one, the reality K > > is much more complicated as it generally is and DEC's management before 9 > > Palmer had more to do with killing Alpha than Palmer.  > A > I disagree. Prior to Palmer, DEC management failed to grasp may F > oppportunities and turned Digital into a legacy uncompetitive vendor1 > that was trying to milk its existing customers.  > I > Palmer was given an essentially clean sheet and he could have fixed the H > problems that had gotten DEC into trouble. He could have used Alpha toH > essentially relaunch Digital. He had all the tools at his disposal, he@ > had the power to really change Digital to make it competitive.   Clean sheet !!  D Lets see, Palmer inherited a loss making company, a failing VAX 9000E project, Alpha the soup to nuts "Industry Standard" 64 bit processor, F the Hudson and UK FABS, a UNIX strategy that was in tatters, and Phase	 V DECNET.   C In addition to failing projects DEC had managed to miss the two big G changes in the Computing market, the rise of the PC and the rise of the  UNIX Server/Workstation.  G Describing this mess as a clean sheet is a bit like describing George W ! Bush as a bleeding heart liberal.   F Yes he could have done everything you suggest but the lack of anythingA remotely close to a clean sheet made his chances of sucess highly F unlikely. DEC had become a big, unwieldy, out of touch juggernaut that3 was cancelling more projects than it had completed.    Regards  Andrew Harrison    ------------------------------    Date: 17 Aug 2006 03:03:02 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayB Message-ID: <1155808982.189976.181030@75g2000cwc.googlegroups.com>   Bill Todd wrote: > Andrew wrote:  >  > ...  > L > >>> So where exactly would the VMS?VAX customer base have gone in your odd > >>> little world. I > >> Those who did *not* wish to migrate to Alpha stayed right where they L > >> were - and there were a lot of them.  For that matter, there are a fair! > >> number still on VAX *today*.  > >> > >> Moron.  > > F > > Um so stating the absolutely obvious apparently lets you muster upG > > enough courage to be rude again. Of course those who didn't need to J > > migrate didn't migrate wow what an insight. Just as people still usingB > > 486 boxes or old SuperSPARC machines havn't needed to migrate. > H > The point, moron, was that your suggestion above that VAX users had noJ > option save to migrate to Alpha was as much complete bullshit as most ofE > your other drivel.  They had an eminently viable alternative in VAX I > itself - an alternative which some would happily stick with for another 	 > decade.  > H > If Alpha had been as fatally compromised at its launch as you claim itG > was, *most* users would have stayed with VAX (either long-term, or at H > least temporarily while actively investigating a vendor switch) ratherF > than risked switching to a new platform of dubious life-expectancy -F > which was the point above (though you've snipped it) to which you so > incompetently responded. >  > ...  > I > >>> In 1993 SAP generated annual revenues of $718 million, by 2002 less K > >>> than a decade later SAP generated annual revenues of $9.5 billion. In L > >>> 1993 some of that 718 million dollar market was addressable by VMS, in  > >>> 2002 none was addressable. > >>> D > >>> Siebel generated annual revenues of $8 million in 1995, by theL > >>> beginning of 2002 less than a decade later Siebel had revenues of justC > >>> over $2 billion. A market that Alpha was not able to address. K > >> And yet somehow in Y2K VMS systems were still generating $4 billion in J > >> annual revenue and $800 million in annual profit, while Tru64 systemsI > >> were generating $3 billion in annual revenue to add to that (I don't 3 > >> have profit figures for Tru64, unfortunately).  > >>2 > > I have no idea where you got your numbers from > K > Of course you don't, since you don't know a damn thing about any of this.  >  > ...  > E > > Either Palmer killed Alpha and by default Tru64 and OpenVMS or he  > > didn't.  > E > That was *never* anything at all resembling the issue, you complete E > fucking idiot.  The point was that your suggestion that *pre-Alpha* J > events caused Alpha's 'decline' was pure bullshit:  the mid-'90s declineB > after Alpha's earlier acceptance was caused by Palmer's mid-'90sD > mismanagement of the related products (duh), and the late-'90s/Y2KF > resurgence - particularly in Tru64 - was due to Palmer's replacementI > first by Pfeiffer (who gave the entire platform a brief but significant J > shot in the arm) and then by Capellas (who at least was not as obviously" > incompetent as Palmer early-on). >  > ...  >  > > G > > Incedentally there are no Server market sahre numbers which support K > > your revenue figures which raises the question of where they came from.  > G >  From Compaq, of course:  from a meeting that Dave Froble, Rob Young, J > and I (as representatives of a larger group of people interested in VMS)D > had with Rich Marcello (then VP in charge of VMS) and his staff inG > mid-Y2K (that's where the specific VMS figures came from), and from a G > March, 2001 Compaq slide presentation (that's where the identical VMS G > revenue number and the corresponding Tru64 revenue number came from).  >  > ...  > J > > The whole discussion has now become extremely boring and so I will notG > > be responding to any more of your posts on this subject unless they I > > contain well thought out and relevant points which don't descend into 
 > > abuse. >  > Good riddance, asshole.   C Let me spell it out for you since you seem to have missed the point E again. I have lost interest in your responses to this thread and your + latest reply only serves to illustrate why.   C That doesn't mean that when you post similarly well thought out and D relevant points in other threads that I will refrain from making you splutter with rage.    Regards  Andrew Harrison    ------------------------------   Date: 17 Aug 2006 12:05:10 GMT( From: bill@cs.uofs.edu (Bill Gunshannon)" Subject: Re: Alpha remembrance day+ Message-ID: <4kj4bmFc8cn9U1@individual.net>   C In article <1155807784.528880.162010@i42g2000cwa.googlegroups.com>, 0 	"Andrew" <andrew_harrison@symantec.com> writes: > E > Compared with IBM and Compaq PC's the Rainbow was superiour from an G > engineering standpoint, the problem was that good design did not sell  > PC's.  > - > Price and RAM/CPU/DISK/SCREEN features did.   E Sorry Andrew, here I have to disagree.  There were machines with much G better DISK and SCREEN features.  The Nec APC for one.  1.25 Meg floppy F and 1024x1024 256 color graphics.  And an available hard disk.  All atF a very reasonable price.  Didn't run the 8088, ran the real 8086 whichI at the time was used proimarily for high-end CAD stations like those from F Tektronix.  Had software, too.  AutoCAD cruised along on this machine,H It failed int he marketplace.  Why?  It was not truly PC compatable (howG could it be with all these features the PC lacked?) and that was always D the kiss of death.  The incompatable floppy woud have been more thanE enough to kill the Rainbow, even if the price didn't.  And anyway, it G obviously is not all about price as business were always willing to pay G a premium for the IBM name.  The local Blue Cross office was famous for H this.  The insisted on all their PS2 memory coming in IBM packaging evenI though at the time it was nothing but re-badged Kingston memory and could H be bought directly from Kingston for less than half what IBM was asking.   bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------    Date: 17 Aug 2006 05:58:57 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayC Message-ID: <1155819537.050290.169320@b28g2000cwb.googlegroups.com>    Bill Gunshannon wrote:E > In article <1155807784.528880.162010@i42g2000cwa.googlegroups.com>, 2 > 	"Andrew" <andrew_harrison@symantec.com> writes: > > G > > Compared with IBM and Compaq PC's the Rainbow was superiour from an I > > engineering standpoint, the problem was that good design did not sell 	 > > PC's.  > > / > > Price and RAM/CPU/DISK/SCREEN features did.  > G > Sorry Andrew, here I have to disagree.  There were machines with much I > better DISK and SCREEN features.  The Nec APC for one.  1.25 Meg floppy H > and 1024x1024 256 color graphics.  And an available hard disk.  All atH > a very reasonable price.  Didn't run the 8088, ran the real 8086 whichK > at the time was used proimarily for high-end CAD stations like those from H > Tektronix.  Had software, too.  AutoCAD cruised along on this machine,J > It failed int he marketplace.  Why?  It was not truly PC compatable (howI > could it be with all these features the PC lacked?) and that was always F > the kiss of death.  The incompatable floppy woud have been more thanG > enough to kill the Rainbow, even if the price didn't.  And anyway, it I > obviously is not all about price as business were always willing to pay I > a premium for the IBM name.  The local Blue Cross office was famous for J > this.  The insisted on all their PS2 memory coming in IBM packaging evenK > though at the time it was nothing but re-badged Kingston memory and could J > be bought directly from Kingston for less than half what IBM was asking. >   E There was very definitely a 2 tier market. You had some customers who @ would only buy IBM PC's and then you had customers who would buy1 anything provided it was cheap. Compaq generally.   C The risk adverse tended to buy IBM, reinforced by IBM's strategy of E suing all and sundry fro things like apparently using IBM IP in their  BIOS's.   @ I am thinking here of the PC compatible market, as you point outG vendors such as NEC and DEC produced systems that were not exact clones C of an IBM PC, some like the NEC were better but failed because they 6 couldn't pass the all important PC compatibility test.     Regards  Andrew Harrison    ------------------------------  # Date: Thu, 17 Aug 2006 15:10:23 GMT + From: "Villy Madsen" <Villy.Madsen@shaw.ca> " Subject: Re: Alpha remembrance day- Message-ID: <zF%Eg.422614$IK3.51518@pd7tw1no>   A I remember being at the initial Rainbow rollout here in Edmonton.   M I also remember the reception that I got when I said that their non-standard    (hard sectored) buy preformatted floppy would kill them...   M I also think that the on-going maintenance costs (hw & sw) for the VAX lines   was an issue... L It boogled my mind to think how much we spent to keep the OS support on our M 4300 current.  We had dropped hw support on just about everything except the  H CPU.  Used spares for the drives were paid for by a couple of months of  dropped maintenance...   Villy     9 "Andrew" <andrew_harrison@symantec.com> wrote in message  = news:1155819537.050290.169320@b28g2000cwb.googlegroups.com...  >  > Bill Gunshannon wrote:F >> In article <1155807784.528880.162010@i42g2000cwa.googlegroups.com>,2 >> "Andrew" <andrew_harrison@symantec.com> writes: >> >H >> > Compared with IBM and Compaq PC's the Rainbow was superiour from anJ >> > engineering standpoint, the problem was that good design did not sell
 >> > PC's. >> >0 >> > Price and RAM/CPU/DISK/SCREEN features did. >>H >> Sorry Andrew, here I have to disagree.  There were machines with muchJ >> better DISK and SCREEN features.  The Nec APC for one.  1.25 Meg floppyI >> and 1024x1024 256 color graphics.  And an available hard disk.  All at I >> a very reasonable price.  Didn't run the 8088, ran the real 8086 which L >> at the time was used proimarily for high-end CAD stations like those fromI >> Tektronix.  Had software, too.  AutoCAD cruised along on this machine, K >> It failed int he marketplace.  Why?  It was not truly PC compatable (how J >> could it be with all these features the PC lacked?) and that was alwaysG >> the kiss of death.  The incompatable floppy woud have been more than H >> enough to kill the Rainbow, even if the price didn't.  And anyway, itJ >> obviously is not all about price as business were always willing to payJ >> a premium for the IBM name.  The local Blue Cross office was famous forK >> this.  The insisted on all their PS2 memory coming in IBM packaging even L >> though at the time it was nothing but re-badged Kingston memory and couldK >> be bought directly from Kingston for less than half what IBM was asking.  >> > G > There was very definitely a 2 tier market. You had some customers who B > would only buy IBM PC's and then you had customers who would buy3 > anything provided it was cheap. Compaq generally.  > E > The risk adverse tended to buy IBM, reinforced by IBM's strategy of G > suing all and sundry fro things like apparently using IBM IP in their 	 > BIOS's.  > B > I am thinking here of the PC compatible market, as you point outI > vendors such as NEC and DEC produced systems that were not exact clones E > of an IBM PC, some like the NEC were better but failed because they 8 > couldn't pass the all important PC compatibility test. >  > 	 > Regards  > Andrew Harrison  >    ------------------------------    Date: 17 Aug 2006 09:42:16 -0700- From: "Andrew" <andrew_harrison@symantec.com> " Subject: Re: Alpha remembrance dayC Message-ID: <1155832936.721317.224120@b28g2000cwb.googlegroups.com>    Villy Madsen wrote: C > I remember being at the initial Rainbow rollout here in Edmonton.  > N > I also remember the reception that I got when I said that their non-standard" > (hard sectored) buy preformatted > floppy would kill them...  >   G I guess that having a 400K disk drive vs the 360K that other PC vendors D used might have looked like a selling point to someone in DEC. Sadly their optimism was misplaced.   D The irony was that the Rainbow was quite clever, Z80 and 8088 CPU soF that you could run CPM/80 and MSDOS wasn't a bad idea. The trouble wasE that IBM had already set the standard for PC's and the Rainbow didn't  comply.   E Another example of DEC not understanding their place in the scheme of  things.    Regards  Andrew Harrison    ------------------------------    Date: 17 Aug 2006 10:02:14 -0700- From: "Doug Phillips" <dphill46@netscape.net> " Subject: Re: Alpha remembrance dayB Message-ID: <1155834134.725255.28370@b28g2000cwb.googlegroups.com>   Richard B. Gilbert wrote:  > Sharon wrote:  > ` > > In article <44E0AEF4.ADF7A446@teksavvy.com>, JF Mezei <jfmezei.spamnot@teksavvy.com> writes: > >  > > G > >>Read up "Elephants CAN Dance" by Lou Gerstner. IBM was in far worse I > >>shape than Digital, yet, Gerstner was able to turn the company around G > >>big time exactly by stopping the slash and burn that had begun just  > >>before him.  > >>I > >>Both IBM and Digital had become uncompetitive because of their prices I > >>and attitudes towards customers. Firing a gazillion employees doesn't L > >>magically reduce prices on your price list. But it does prevent you from6 > >>making sales when you no longer had a sales force. > >  > > I > > 	Have anay of you read "DEC is Dead, Long Live DEC"?  Sorry, I forget L > > the author's name, but it's available on amazon.  I don't like the titleQ > > because it reeks of OS religious wars, but it's really a story of how DEC was # > > started, grew, and fizzled out. I > > 	I found it interesting that when the company reached a certain size, N > > people started spending more and more time in CYA activities and corporateO > > politics and less time being technically productive.  It mentioned that Ken Q > > tried several times to stop this, but he had no clue how to do it (and didn't Q > > realize that his own personality caused some of it) so he was very frustrated  > > by the time he bailed out.E > > 	It also talked about how Ken and his management team were having S > > trouble reading the market in the 1980's.  They still let various people try to S > > develop what they thought would be successful products, but then canned many of M > > them too early and let a few bad ones go to market.  I'm not sure why the R > > culture of "try it and see what happens" worked in the early days but actuallyS > > damaged the company later on.  Perhaps because by then they had a reputation to = > > uphold and things like the DEC Rainbow tarnished that...?  > F > The Rainbow was a fairly decent PC.  The problems were price, price,D > price, and the lack of an Open bus structure.  IIRC you could haveG > either a hard disk controller or a network interface but not both AND F > both were DEC proprietary.  DEC offered, for $2200, a hard disk thatG > could be bought elsewhere for about $300.   DEC offered a set of 256K D > RAM chips for $700; I bought mine on the open market for $33.  TheI > memory expansion daughter board was another $700.  (I bought a used one  > for far less than that!) > J > Then there was the floppy issue; DEC insisted that it was impossible forJ > the Rainbow to format its own floppy disks.  The real issue was that DECA > wanted to sell formatted 5-1/4" floppies for ~$5 each!  All the H > competing machines could format blank floppies that sold for something > like a dollar each!!!! > J > DEC eventually yielded on the floppy issue; the wonder is that anyone atH > DEC could believe that DEC could get away with it!  There was, by thatH > time, a program available for PC's that would format Rainbow Floppies;H > naturally, the Rainbow required a unique format and could not exchange > floppy disks with PCs. > I > DEC should have known better than to close the architecture; one of the H > things that made the PDP11 great was the UNIBUS or Q-BUS architecture.H > Anybody could make and sell UNIBUS and/or Q-BUS interfaces and severalG > companies did.  That was a big part of the success of those machines. J > They also had the example of the Apple II and the IBM PC/XT with its ISAH > bus.  In short, they built hardware that could not compete on featuresG > and certainly not on price.  Not to mention that IBM had a head start ! > that amounted to several years.   C I know I can't tell you anything about the Rainbow, David, but this  sure brings back some memories.   D At the time of the Rainbow-100's conception, not its birth, no clearG leader in the desktop chip & OS wars had been declared. So, DEC made it E a triple boot machine with a Zilog Z80 for C/PM and an Intel-8088 for E MS-DOS & CP/M-86. When IBM's overwhelming success made Intel & MS-DOS E the de facto desktop standard, DEC was already committed to producing  the Frankensteinish Rainbow.  C The Rainbow was grossly over-engineered for a desktop whose time to D obsolescence was short. DEC apparently didn't understand or buy intoG Moore's Law, so it was built in the "last forever" manner of larger DEC A systems; therefore it was expensive. While it was built for "easy E upgrade" using a special back-plane, the assumption was that upgrades G would be available and the supporting electronics would suffice for any @ future need. Naturally, time proved that the cost of upgrading a? Rainbow exceeded the cost of an entire new Compaq or other such 	 computer.   F You needed a special Rainbow version of all software because the mediaA and operating systems were not compatible with any other desktop. E Naturally, there was not always a special Rainbow version of software D one might like to have. (Does this sound familiar to all those loyal) DEC customers who bought into Alpha NT ?)   C We had a few Rainbows and our customers, being loyal to DEC, bought F Rainbows, but not from us because we couldn't sell them. DECdirect wasD easy to buy from! Plus, they were sold at the local ComputerLand andE even at the local Sears store. They were advertised in the newspaper, F radio and TV. PBS' Nightly Business Report showcased Rainbow's & VT's.E Really! I know some younger people won't believe that, but it's true!   F The PC world moved on, but those Rainbows lasted forever. Because theyG were so expensive, people couldn't justify throwing them out so most of ! them became very fancy VT-220's.    
 Ah, memories.    ------------------------------  # Date: Thu, 17 Aug 2006 09:52:25 GMT . From: Jack Patteeuw <jack.patteeuw@nospam.net>% Subject: CDD/Repository Documentation ; Message-ID: <t%WEg.10167$kO3.89@newssvr12.news.prodigy.com>   F Not exactly a VMS Question, but I'm looking for documentation on this G product.  The only thing I can find on the Oracle Rdb web site are the   Release Notes.   ------------------------------  # Date: Thu, 17 Aug 2006 13:20:56 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com>) Subject: Re: CDD/Repository Documentation . Message-ID: <Y2_Eg.66$vZ4.58@news.cpqcorp.net>   Jack Patteeuw wrote:H > Not exactly a VMS Question, but I'm looking for documentation on this I > product.  The only thing I can find on the Oracle Rdb web site are the   > Release Notes.  2    Google and AllTheWeb both pretty quickly found:  :    http://www.oracle.com/technology/documentation/rdb.html  L    Most site-local search engines are not particularly good at indexing and H retrieving the information -- which is unfortunate -- or the tools have 2 different priorities than you might want, or both.  Q    I've noticed various of the Google results or the Google cache seems a little  Q stale of late.  There are references I know exist, but that Google can't find or  Q otherwise won't report.  Hence I generally try several of the search engines, or  O a mash-up/lash-up like DogPile.  (And if you haven't seen it, the Google Dance  % Tool is interesting.)  But I digress.    ------------------------------    Date: 17 Aug 2006 04:32:36 -0700% From: "Russ Leathe" <russ@gordon.edu>  Subject: Re: Ken Olsen VAXC Message-ID: <1155814356.556042.123750@m73g2000cwd.googlegroups.com>   @ His office is in Maynard.   The current setup is local only...noE internet access.  I have a Win2K server on the same localnet.  I plan  on using this for FTP.  G It's a microvax, clustered of course, shadow drives and a tape library. =  Approx 2gb of disk.  actual size of the data files I haven't  determined yet.   . I would appreciate any help you could provide!  D Not sure if you guys knew about "Ken Olsen Day" we had a the CollegeG two months ago....we have a DVD if anyone is interested.  Also, we hope 9 Ken can make it back for the ribbon cutting in 18 months.    thx    Russ       Hoff Hoffman wrote:  > Russ Leathe wrote: > 7 > > Anyway, Ken donated his micro VAX to the college... C > > I plan on going to his office next week to perform the backups.  > G >    Where is KO's office these days?  Boxborough?  Or over in Lincoln? H > I'd expect that there are folks here in OpenVMS Engineering that would= > be honored to offer at least informal assistance with this.    ------------------------------  % Date: Thu, 17 Aug 2006 07:25:16 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca>  Subject: Re: Ken Olsen VAX< Message-ID: <44e450e1$0$24186$9a6e19ea@news.newshosting.com>  : "Hoff Hoffman" <hoff-remove-this@hp.com> wrote in message ( news:LnIEg.23$Et4.14@news.cpqcorp.net... > Russ Leathe wrote: > 6 >> Anyway, Ken donated his micro VAX to the college...B >> I plan on going to his office next week to perform the backups. > F >   Where is KO's office these days?  Boxborough?  Or over in Lincoln?H > I'd expect that there are folks here in OpenVMS Engineering that would= > be honored to offer at least informal assistance with this.  >   J Hoff: Run this up to HP management. This is a photo-op that should not be F lost. With all due respect to Russ, please send over some people from L OpenVMS Engineering to make sure the backup doesn't get pooched. I can only K imagine the small talk between Ken and the OpenVMS Engineering technician.   For example, Ken's thoughts on:  1) the alliance with Intel! 2) recent growth of OpenVMS sales > 3) growing popularity of OpenVMS in Europe (the home of LINUX) etc.  
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.9 http://www3.sympatico.ca/n.rieck/links/cool_openvms.html       begin 666 ken-olsen.jpg = M_]C_X `02D9)1@`!`0$`2 !(``#_VP!#``8$!08%! 8&!08'!P8("A *"@D) = M"A0.#PP0%Q08&!<4%A8:'24?&ALC'!86("P@(R8G*2HI&1\M,"TH,"4H*2C_ = MVP!#`0<'!PH("A,*"A,H&A8:*"@H*"@H*"@H*"@H*"@H*"@H*"@H*"@H*"@H = M*"@H*"@H*"@H*"@H*"@H*"@H*"@H*"C_P `1" "=`'@#`2(``A$!`Q$!_\0` = M'0````<!`0$``````````````@,$!08'" `!"?_$`#P0``(!`P($!0(#!@(+ = M``````$"`P`$$04A!A(Q00<3(E%A<8$4,I$5(T*AL<$()#,T4F*"DJ+1X>+Q = M_\0`% $!`````````````````````/_$`!01`0````````````````````#_ = MV@`,`P$``A$#$0`_`+_<2 =,YZT4'YW ;"FC2&C)"Y=3VSTH@@!CS1D$T G* = MJW7!HIF!&1N*)EMP\I8YV[@TTZ[KD&CJ5+"29AS+&OM[GV% HU"X_#H^$4G& = M?4<`?4U7VM\436O,EI/&X#9Y54X'QUI/J]_>ZFYDF<@'H@)Y1^E1?4K4LA9U = M8>Y&<?7-`?>>(>IHW+_ER<X`*D;_`%S2!?$K6;>X+XAEBSNO4'X]Q49U.W90 = M3DLG3>F&YBS)SJ<``DD'K]?F@L.?Q>N!()7LH&C&WE\Q&?O5C\$<7:5Q5:J= = M/N$6\4<TMHS>M/UQS#Y%9<GC)WZBDEO<7-C=1W%E/)!,ARLD;<K+]"*#95R+ = MB:;R5;D9MLKV%+%TV,*O,6Y^[$]:I/PJ\5I[F_MM(XFD1I9"(X;]AN6[+)]? = M]K]:O@PRYYO,(;N * B6U=8_W/J/MVKSRYB@1>81XW-'PW 5L/Z2#C?O2DMS = M@AEV- W_`(=EE0\_*N=@*ZEWE("Q9.<C8?%=0.*&1<\^XS09&# X)HZ>9(F( = MYAD]:232HQY0C,&[J*!KXBURVT#35FN6S+(2D,>=W?&?T'>JHTY;W5M5EN+Q = MP[AN=\[8SVKW5[R7B?Q#O&@<_@]-!MD8[J,?FQ\EMOM4KTS3DL[<GEQ)*>=R = M?<]J!(UJJC*[/_(TV:C;&2%EP-QWZ5)Y( ",#;V]J17D&0,;K05CJEF\8'[L = MX4U#-31DD<!>5#OCL/I5Q:G9ED;F`Q4$U3348N&4_%!7LQV.VU(I$!QUIVU* = M!H)<;$4UN,XZT"=XPOJ!P#T(K5?@YQ2_$O"$'G2^9J-CBWN2>K #T-]QW]P: = MRRP/*4.X/8]J?> >+K[@[6?QEF>:"3"7$)&1(F<GZ'K@T&OYHHV@(/-S9S2> = M&2485F&/X2:-TV[M]2L;:]M)!):W,8DC;W!&:"!B5E8^D'8B@61S#*YV8[&N = MHJ"0.P(QMVQ74#P(^I&,_-)+U!';33*&5T1G]/N!FA^;(AY6Z]C2/6)V33+M = MMP!$Q)ST.*"OO#O2?(TB::>(@SMSY]\DFI)(F9MEQ'_>O>%FY]*95RX5AZ\8 = M#''8>U+8X0`<*-CF@2,F1TP*2W* *?33\MMS)G>D\UH@C97&>U!$;J$2ITSG = MO\U$=?L_W)*+EL'IUS5C7%FJQD ;>]1K5;<,C9&5/]:"E>(X/0"1ZL=?>HJR = M889.]6CQ1IB^67&<CL:KF\B 8D #'STH$,HP,]Z#/'EPZ>D'OGO7LI&*Z(B1 = M`1@$;&@T'_AVU]KW0+W1+E\RV+>;"#MB-NH'T;^M6K+ 2/2W*0:R;P-Q1-PC = M>2ZG;P)/+R&+RW8A=^YQU'Q6GN"]?AXJX8M-5MX_+\T%)(\[QNIPP^G]B*!R = MBDQ.1R[#\Q]ZZA36Y=5/49R1WKJ!>8Q>R%D5_*7J3MFDNM0K;Z3=G!"<ASCN = M/8U(%STP`*1:O;BZT^YA) $D;+G'3:@C>@%8[ (I"KG94& *6QG=@>F:#IBK = M)86YA0*@0"A8Y9">QVH%T) &/TQ1%V!C.<5ZKG&Q%)+QGQLQZ>U BN6Y003U = M[5&M5C8JZ=STQ3MJ+2\A`V]B>](8LW$#$MEHS@]C00K4K7F7E89)!!/7%55K = MUN(;J6,+C?.!W'O5XZC#Y43<P 0C(.-LU6VKVL<T\A8<B$XR1UH*TN<ASL1[ = M4C)*-L>M2+6((8I'1&0D=C[4P7"@$%?TH%2/FSE]]JM[_#GQ*UMK,_#\KGR+ = MP-/%D["10,@?4 U2\/,T,JKU`R!4H\)KHP>(7#S\V,7:K]CM_>@V.5S@'I74 = M49E#84\WM74#W(0BDY-)9)&*$!"<@[TM(RQ Z4!AVH(QIY-O%)&YP8^GS[4( = MR\\8<J5QVHO5862_F" <I 89Z$GM^HI/:3-+%*DF0RMMD=,]J!RA0,23T]J# = M<*G+T&U)K^X:.U/DX\T+U.PJH.,/$+5M,YTL9DN5C;$K)"2J;XW;I06=?K&\ = M3JN*C]E.+:[9'_T<V0=NA[5"])XMUZ18EOH(R)#A&5@-\]P:L&]T,WVDY=W@ = MF"<Q"GU9Z]:"(<;<3V6F`B\9>;'H7KS?054.K<0SZQ*TBP216\?J)C4L0/>D = MG&L,MOQ 4NII)PN^7))Q[4Z<':UI]E9W%C?P^9;3NLG.XR,CID=J".7MS;,H = M>,W$G/OSR+@_I[4W[R*2N_SBI+KYAO9O*TSRUA9MR=C_`/*:+BU:VY5;DQ\4 = M":U]++[YQ4D\+=.?4./]&@ASM=>8Q'\*IEB?Y5'#CG 'OBK)\!],NKCQ"2\C = MC86MK'*TK@;;K@#/N2:#1^GQ)&[8R<[9-=2E%Y1MTKJ"1,0,FB78YVH;D9I/ = M*3D8."*!GXGBE-OYML,R`=/?&]-*,?-C=5PL\8E'Z#(J5RH)$PP!S4;U-)(I = M(]AB,D# WP1T^E EUZSGOM.F@M9?*DD7E#+OCYJ+ZCP?I$?#Z6,\3.(6,BLQ = MW+'J2?MTJ<Q3<T0`Z#^M!G@$@QMRT%-V.B:CJ6MV]G8\T=DD@9I2F !G.1GJ = M>M6Y<#T-'S$GEQGO08D6!W=5*[;L3_2DT=R)E#0KS<W3YH,Z>+ML8N(`Q0J" = MG7WJ%6K,KE O.O7'M5K>-%OS>3,5PRG%5 6:-/,C)#B@?+7E+YQRG^E U-D! = M54&!WWZUUG/Y\"<ZA9<;TCO<@;^]`FS^^!'8YK5?@_'I$7!-DVC-&9KA1+=@ = M2<[^=C?F]L>WM64,XWHF.^NK"]\ZQN9K:9<$/$Y4C[B@W:O;^==65^&O&_B? = M2D6*_P#P^J0J,9N!RR?\XZ_<&NH-BR$'ZTG;<Y(Z49+OTZT2Q;.!O0<S=S3= = MJ"<^6Y&8=\#)!J+<8^)_#?"S^1>W,EQ>#/[BV3F/W)V%9^X]\7];XH,EM9,V = MEZ6Y(\F!O7(/]]^OV&U!I?*HY,;J\;;@J=J51SCRR.E5'X"\0_M'ALZ5<M_F = MK%CY.?XHCOM]#D?I5GF1?>@8>,M9%AI-PT0]0!'6B=#35;71])9X(YG9`9F: = M3E901GIC>A:E8)?W:B<!HPW,%/3;N:>Q<HZ84CE0;DC"B@K/Q)T.\UDP6R". = M(S/@2.=A\8'>J=N^&;K3KB>&\;,T1SR@;$>XK07%-[8B>"X-P3^'/,>5"1FJ = MGXZXB75KEGT^S*JB\K2GJWS\4$0L[U-/O4::$2PC9D.V1[?6C>))K&:1)=/R = M8F!R.A0^Q%1^XDDEE()Y1GMUIQTXP<ESYP)=HR!]:!M?(YL]CFF^9N:1C2N5 = MC@YW/+O26X3D<#V44 %-=7@KJ#57&/CYH]D7@X<MI=0N.@FD!2(?..I_E50\ = M4>+'%6OJ\<M^UI W6&U'EKCY/4_K5>KDG(H0.S9W]J#I99)6+2.6/<DY)KV% = M/,D`ZCOM13-@?-.6GQ,D0EZ%MQ0/G#6JW7#^L6NHZ<_J@;=&SRNG=3]1FM.Z = M3JUMK6E0:A8/FWG7F [K[@_(.U91>0,^'3UG?.<9%33P^XOEX5NTBNV:32;E = M@)4SO&Q..<?3O\4%V:M:7D[R"UN#")@(PX7)C'<CZT-M"6)(DCN)I(E #+*Y = M.3W)IX8"2W5X2KJPR&4Y!'8BAA<QKS>H]#00'BK1K*.W9Y)F3*XP23_*H-Q# = M;R7-E^%L;3E,:X)QR\^W6KQN=-@F7FF4-CH,5%>(+-%AE$**AP,8%!FW4+": = MSF9;A.1^N/:D8D:-@R]#UJ0\52/^T9UD.2K$9J+2L3Z1M0<1SO@'KUI+<-S3 = M.?G%.%O;LL7,0<L,TV9RQSUR:#T5U>CK74"UEPH'0443Z2<T*0@`*1U[F@-G = M( ^@H#+2`3RYD!\M?S<O<T[)ELF/'+C `HF-!'&J#9NK`]Z-10Q!)9&!P!0& = MJ!SXD5N8=3WH-^"824)*=<49(^?1L<G',>]%70'E-Z@=@,>U!HGP/UU.*^#T = MTM.>'5M'B6-G/Y)HR2$/U `!J3L]U:3F.[CY=_;%4Y_A@U0V?'%W9%E$5Y;% = M2#[J<@_SK3E[:Q74865 ?8]Q00J2_0(2QY0/=JBG$NJ6UO&TDSKR'/4U+N(] = M,:QM972,2*5/J"Y ^U4/J^E:OJ>I2Q26ES+&IV182J@_)Z4$-XHG%YJTYMR& = M1FR"!3AH7!%].OFW,)7F_*C[$#N3_0?>KJX$\,K.S2UU'5HQ)/RB2.' *1GL = MQ]SL34LUK3XUMO(@01!\^:X&^,8Y1_3]:#/%[H*6>EWMXRY2-"J''7'?[DC[ = M"JO (ZUH[Q5BC@X>:TMU"QHN&Q\9_P#8_>L\7"@3-CIGK0%#K748!MM74!C[ = MG;./FO(V96#(?4M!!VWHR%<E=^M Y176Q60JK'<'&1_XKRYD+NHCPJJ-\=S2 = M6?H3[;8H:L2$?/JH%%N_H (W%*&8E0%Z8PQ^M)HAB0A<#U>WQ1[DE%'08)Q0 = M./AEJ!TGQ!T>?FY )PA;VSM6X'<8YL@+C.2=A7S\>1K;4(I8SZT<,/J#6LO$ = M;6+R+PWT.&&4HVJR):SR+^81X)8`_.,9^M! O&7C.^XOSHO"F?V*C!;FYZ?B = M'S^4>Z+U..M5YK%_<WMND-QJ-U^QM-C$"O*Y8M_P]V;?`[#Z5?F@<.:<NE6U = MP8<MYRH%[<O,HQCZ5G#Q(46>H6^G0;6T*M*%]W9VR3]@H^@H''A?Q/UKAJ=8 = MM)99-(C/^J77J#=-\]5)QVVJ\-'XYAXATJ.Y2VDAN"O,;=SDH>G,#_$!AC[[ = MBLNZ;$MQ>VT+[([*&QWS5ZZ;$EME80% &!\;L/[4!/%%[^+TN^=?4P1B5/4; = M?VQ_TU15RI#<V=CTJ]^.]/C/"DVI1LT=P3Y4G+TD!0-O\_\`>J+NP.;-`0OY  *@*Z@J?574'__V0``  `  end    ------------------------------    Date: 17 Aug 2006 08:29:34 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)  Subject: Re: Ken Olsen VAX3 Message-ID: <NEwefzEfO1yT@eisner.encompasserve.org>   j In article <1155747343.524030.241220@74g2000cwt.googlegroups.com>, "Russ Leathe" <russ@gordon.edu> writes:	 > Hi all,  > G > As you may know, Gordon College is building the new Ken Olsen Science 	 > Center.  >  > Please see.....  > . > webcam.gordon.edu to watch the construction. > I > Anyway, Ken donated his micro VAX to the college.  I would like to back F > this up to tape or ftp all his documents to another server (prior toF > moving).   It's been a while since I've run backups on a VAX and I'mH > unfamiliar with UCX.  Especially running the FTP process. It's OpenVMS; > 5.x so I'm not sure if FTP was supported on this version.  > ' > anyone out there willing to help out?  >   G    FTP in UCX on 5.x should work well enough, if you don't mind loosing F    VMS file attributes.  If you want to preserve those you're probably7    best off sticking a copy of ZIP on the system first.    ------------------------------  # Date: Thu, 17 Aug 2006 13:34:51 GMT , From: Hoff Hoffman <hoff-remove-this@hp.com> Subject: Re: Ken Olsen VAX. Message-ID: <%f_Eg.67$EU4.24@news.cpqcorp.net>   Russ Leathe wrote:B > His office is in Maynard.   The current setup is local only...noG > internet access.  I have a Win2K server on the same localnet.  I plan  > on using this for FTP.  M    I can usually be standing near the Guillotine Gate in less than two hours  Q from receiving a call, and yes, I know my way around the Mill.  (Well, I used to  O be able to find my way around.  I'd expect more than a few walls and halls and  6 partitions have changed over the years.)  Building 12?  I > It's a microvax, clustered of course, shadow drives and a tape library. ? >  Approx 2gb of disk.  actual size of the data files I haven't  > determined yet.   <    There are hardware configuration details (still) missing.  N    Copying the files onto or via a Microsoft Windows or Unix or Linux box can J mess up the OpenVMS file attributes, particularly if you're not using the P correct tools and the right command options.  Just last week, I was cleaning up O a similarly-triggered corruption in a source archive someone had (mis)created.  N   It's generally better and safer and easier to use OpenVMS tools to preserve  OpenVMS files.  P    If you wish assistance, send me mail and we can discuss this off-line -- and O as I stated, I can be in Maynard in a couple of hours.  I can also bring along  P additional I/O hardware and media, if and as needed for the safe-keeping of the 7 data for the transfer of the system to its destination.    ------------------------------    Date: 17 Aug 2006 08:18:54 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ) Subject: Re: Products in Operating System 3 Message-ID: <H6RDyaN8Zd+l@eisner.encompasserve.org>   V In article <4kgjcgFc3bkhU1@individual.net>, bill@cs.uofs.edu (Bill Gunshannon) writes:5 > In article <DfhRAXBgl7Kh@eisner.encompasserve.org>, @ > 	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: >>  O >>    That didn't happen until VMS 3.0, and at our site we got our copy of the  # >>    key on 8 1/2 inch floppies.    > I > Wow!!!  How did you get that 8 1/2 inch floppy into the drive?  Biggest ' > floppy drive I ever saw was 8".   :-)       Oops, misplaced my ruler.  $    Must have been using compression.   ------------------------------    Date: 17 Aug 2006 08:20:06 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) ) Subject: Re: Products in Operating System 3 Message-ID: <RnAR2LoBnIMR@eisner.encompasserve.org>   p In article <ftOdnTe4zterhX7ZnZ2dnUVZ_qCdnZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes: >>  O >>    That didn't happen until VMS 3.0, and at our site we got our copy of the  E >>    key on 8 1/2 inch floppies.  (I don't recall TK50 support until  >>    later systems.)  > + > I believe we were talking about VMS V4.7!   A     Ah, lost track of that in the thread.  A DECnet key on TK was >     certainly a 4.7 possibility.  In fact, I probably had one.   ------------------------------  % Date: Thu, 17 Aug 2006 16:10:34 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch> ) Subject: Re: Products in Operating System J Message-ID: <paul.sture.nospam-704958.16103417082006@mac.sture.homeip.net>  3 In article <RnAR2LoBnIMR@eisner.encompasserve.org>, =  koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:   I > In article <ftOdnTe4zterhX7ZnZ2dnUVZ_qCdnZ2d@comcast.com>, "Richard B.  + > Gilbert" <rgilbert88@comcast.net> writes:  > >>  M > >>    That didn't happen until VMS 3.0, and at our site we got our copy of   > >>    the G > >>    key on 8 1/2 inch floppies.  (I don't recall TK50 support until  > >>    later systems.)  > > - > > I believe we were talking about VMS V4.7!  > C >     Ah, lost track of that in the thread.  A DECnet key on TK was @ >     certainly a 4.7 possibility.  In fact, I probably had one.  ( ISTR having one on a small 9 track tape.   --  
 Paul Sture   ------------------------------  # Date: Thu, 17 Aug 2006 10:15:03 GMT . From: Jack Patteeuw <jack.patteeuw@nospam.net> Subject: Samba / CIFS and ACLs= Message-ID: <HkXEg.10168$kO3.6665@newssvr12.news.prodigy.com>   9 We are currently running Alpha VMS 7.3-2 and Samba 2.8(?)   H The evaluation version of CIFS has the restriction that "ACL's will not 
 be honoured".   G This seems odd, because the current version of Samba that we are using  I seems to handle them fine (at least the ACL's that are propagated by the  ? default ACE's that we placed on the directories using EDIT/ACL)   G Anyone (who really knows !) care to add some light to that restriction.    ------------------------------  # Date: Thu, 17 Aug 2006 13:49:09 GMT 7 From: John Malmberg <malmberg@dskwld.zko.hp.compaq.dec> " Subject: Re: Samba / CIFS and ACLs. Message-ID: <pt_Eg.68$m_4.43@news.cpqcorp.net>   Jack Patteeuw wrote:; > We are currently running Alpha VMS 7.3-2 and Samba 2.8(?)  > J > The evaluation version of CIFS has the restriction that "ACL's will not  > be honoured".  > I > This seems odd, because the current version of Samba that we are using  K > seems to handle them fine (at least the ACL's that are propagated by the  A > default ACE's that we placed on the directories using EDIT/ACL)  > I > Anyone (who really knows !) care to add some light to that restriction.   E Currently from a CIFS client, you can not display or change the ACLs  - that are on a file served by CIFS on OpenVMS.   G There are two types of ACEs that can be in ACLs.  Advanced Server ACEs   and OpenVMS ACLs.   D Advanced Server ACEs are interpreted in the same way that Microsoft D group access is handled by Advanced Server.  OpenVMS CIFS currently  ignores those ACLS.     F OpenVMS ACEs are interpreted differently.  While Advanced Server will H honor the ACEs because RMS does, those ACEs are not visible to Advanced . Sever Clients, and can not be changed by them.    I SAMBA expects a draft POSIX ACL implementation, or some specific private  C UNIX ACL implementation.  Those implementations may interpret ACLs  3 differently than either Advanced Server or OpenVMS.     I By stating interpreted differently, it means that the precedence of ACEs  H of Microsoft Group format, or draft POSIX format may be quite different 3 than the way that OpenVMS interprets it's own ACEs.   F One example where Microsoft based access controls can not be properly D simulated by SAMBA on either UNIX or OpenVMS, is the DOS attributes.  I On Microsoft platform, the "readonly" attribute is honored by all users,  D local and remote, and there is no "Bypass" type privilege that will I override it.  A privileged user can remove the attribute, but until they  , do, they can not modify or delete that file.    G This issue is being worked on by the HP OpenVMS CIFS Engineering team.  K The primary effort is to provide the current Advanced Server functionality.   H The SAMBA.ORG programmers are also working on trying to improve the ACL H support in it, but with many incompatible ACL implementations, that can  be a challenge.     G I will pass your comments along to the product manager, Larry Woodcome, H (Lawrence.Woodcome@hp.compaq.dec).  This looks like an issue that needs  better documentation.   5 Questions about OpenVMS CIFS can also be sent to the   OpenVMSCIFS@hp.compaq.dec.  E Please remove the obvious extra characters from the e-mail addresses.    -John ! malmberg@dskwld.zko.hp.compaq.dec  Personal Opinion Only    ------------------------------  % Date: Thu, 17 Aug 2006 03:21:48 -0400 ' From: Dave Froble <davef@tsoft-inc.com> Y Subject: Re: Seeking Data Archiving (BACKUP) Suggestions (was: Re: VAX/VMS site)  site)si 9 Message-ID: <XqKdnWkWNcDCinnZnZ2dnUVZ_tudnZ2d@libcom.com>    JF Mezei wrote: - > Barry.Treahy@EmersonNetworkPower.com wrote: J >> You might find the costs to migrate everything from the 4000/100 modelsI >> to replacement CHARON 4000/108 emulated systems cost effect especially  > G > If he starts to evaluate migration costs, he might find it cheaper to  > migrate to Linux or Windows.  H It's unfortunate that the word 'migrate' was used.  Upgrading to CHARON H means still running VMS.  Plenty of VMS applications don't run on Linux  and windoz.   I > Suggesting a migration where his systems are working fine is not a good G > solution. He can upgrade those VAX systems to the last fully featured C > version of VAX-VMS if he wants. hardware is not the problem here.   E Well, using DAT tape hardware is a problem.  DLT would be a solution.   I > He has systems at 5.5 and needs to find a solution to ease the backups.  > F > CMU-IP is availbale at that version and does have some FTP utilitiesF > (does it have NFS ?). And I think that Mad Goat's FTP server is alsoH > available (or was available) for CMUIP. It is more "featured" than the > CMU FTP server.      --  4 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: Thu, 17 Aug 2006 03:22:57 -0400 ' From: Dave Froble <davef@tsoft-inc.com> Y Subject: Re: Seeking Data Archiving (BACKUP) Suggestions (was: Re: VAX/VMS site) site)sit 9 Message-ID: <XqKdnWgWNcA-innZnZ2dnUVZ_tudnZ2d@libcom.com>    Stanley F. Quayle wrote:F > On 16 Aug 2006 at 14:42, Barry.Treahy@EmersonNetworkPower.com wrote:J >> You might find the costs to migrate everything from the 4000/100 models> >> to replacement CHARON 4000/108 emulated systems cost effect > C > Another CHARON-VAX possibility [Shameless Plug Alert (tm)] is to  H > consolidate those 4000's into one 6610 (or 6620, 6630, etc.) emulated F > system.  The 66x0 series can do 95+ VUP's per emulated processor on $ > modern multi-core Opteron systems.  ? Going to a single system gives up some advantages of a cluster.    --  4 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: Thu, 17 Aug 2006 11:17:30 -0400 , From: <Barry.Treahy@EmersonNetworkPower.com>Y Subject: RE: Seeking Data Archiving (BACKUP) Suggestions (was: Re: VAX/VMS site) site)sit M Message-ID: <63A4454BFCE1C048B2683DBB63A3633363C59C@ETP-CIN-US-EX01.etp1.com>   6 From: Hoff Hoffman [mailto:hoff-remove-this@hp.com]=20( Sent: Wednesday, August 16, 2006 2:06 PM To: Info-VAX@Mvb.Saic.Com B Subject: Re: Seeking Data Archiving (BACKUP) Suggestions (was: Re:9 VAX/VMS site) site)site) site) site)site)site) site)site)    JF Mezei wrote: - > Barry.Treahy@EmersonNetworkPower.com wrote: C >> You might find the costs to migrate everything from the 4000/100  models> >> to replacement CHARON 4000/108 emulated systems cost effect
 especially >=20G > If he starts to evaluate migration costs, he might find it cheaper to  > migrate to Linux or Windows.  G    Yes, an investigation might well find it is cheaper to migrate to=20 H Linux, Windows, OS X Tiger, or some other platform.  Or it might not,=20H and might well find that migrating to a similar platform (and/or a newer  D version) is the cheapest approach available.  Facts not in evidence. ----------------------------  G Migrate was a poor use of words because VMS and the apps running on VMS H over VAX do not require migration to run on CHARON-VAX unlike efforts to6 'migrate' the apps to Alpha or Itanic running VMS. =20  G The other point that has been ignored was cost containment. If you move E to newer class machines (ie Alpha/Itanic), it'll most likely cost you E much more in software licensing/re-licensing than if you just stay on G the exact same sized machine (4000/100 class machine) that the software  was originally licensed for...  C HP charges $1k to move VMS and $1k to move the layered products and G depending on how your 3rd party layered products license is written, it B may cost you nothing since it's the same workgroup class system...   Barry Treahy   ------------------------------  % Date: Thu, 17 Aug 2006 11:29:51 -0400 , From: <Barry.Treahy@EmersonNetworkPower.com>Y Subject: RE: Seeking Data Archiving (BACKUP) Suggestions (was: Re: VAX/VMSsite)  site)sit M Message-ID: <63A4454BFCE1C048B2683DBB63A3633363C59E@ETP-CIN-US-EX01.etp1.com>    -----Original Message-----7 From: JF Mezei [mailto:jfmezei.spamnot@teksavvy.com]=20 ( Sent: Thursday, August 17, 2006 12:54 AM To: Info-VAX@Mvb.Saic.Com B Subject: Re: Seeking Data Archiving (BACKUP) Suggestions (was: Re:- VAX/VMSsite) site)site) site)site) site)site)   D Surely it is cheaper to find a backup solution for this chap than toG suggest he change all his hardware and upgrade his software at what may E be great costs to him. How much would HP charge for software upgrades + from VMS 5.5 to 7.3 for multiple machines ?    ------------------------  D His apps, or layered products, may not support newer versions of VMSF without also being upgraded which could be a cost and/or technological constraint.   C As for alternate tape drives, there are 16-bit SCSI daughter-boards H (KZCCA's) that existed for the 4000 series of VAX systems.  I still haveH one installed my in decommissioned 4000/100 which did run 5.5-2 (not h4)G when first installed.  It isn't perfect since the console can't see the G drive which is a problem for standalone backup tape boots, but once VMS E is up and the driver is loaded, VMS can manipulate it just fine and I H connected multiple SCSI style tape drives (ie. DAT, DLT and VXA) to this adapter without issues.   @ My only reason for 'chiming in' is that I had to run on a frayedG shoe-string budget for years, so I can appreciate where this individual F might be coming from and I replaced my 4000/100 with CHARON-VAX simply: because the HW maintenance was poor and became too costly,C self-maintenance then became a problem because of difficulties with H sourcing spares, and overall system dependability was starting to sufferA -- not to mention our system was simply our of performance gas...   
 Best regards,    Barry Treahy   ------------------------------  % Date: Thu, 17 Aug 2006 03:53:34 -0400 - From: JF Mezei <jfmezei.spamnot@teksavvy.com> Y Subject: Re: Seeking Data Archiving (BACKUP) Suggestions (was: Re: VAX/VMSsite)  site)sit , Message-ID: <44E42067.50FDCACE@teksavvy.com>   Dave Froble wrote:I > It's unfortunate that the word 'migrate' was used.  Upgrading to CHARON I > means still running VMS.  Plenty of VMS applications don't run on Linux 
 > and windoz.   D From a management point of view, it is still a project that requiresE RFP, budgeting ,approval etc etc. To PHBs, it looks like a migration.   G If those VAXes are still there and at 5.5, it is likely that management E do not wish to spend any money to upgrade those machines and that the D next spending for those application will involve porting to a modern8 platform that is alive and well. (aka Linux or Windows).  G Pushing for such an "upgrade" to Charon VAX may result in the loss of a 3 VMS shop faster than would have otherwise happened.   D Surely it is cheaper to find a backup solution for this chap than toG suggest he change all his hardware and upgrade his software at what may E be great costs to him. How much would HP charge for software upgrades + from VMS 5.5 to 7.3 for multiple machines ?    ------------------------------    Date: 17 Aug 2006 05:31:06 -0700 From: etmsreec@yahoo.co.ukY Subject: Re: Seeking Data Archiving (BACKUP) Suggestions (was: Re: VAX/VMSsite) site)site B Message-ID: <1155817866.410466.112140@74g2000cwt.googlegroups.com>  G It all depends on what the site is set up with in terms of maintenance, F spares, ongoing costs etc etc etc.  Upgrading to the latest version ofD OpenVMS VAX may have no cost if the company already has right to useC new versions in place on their contracts.  alternatively, it may be A that Hoff's suggestion of porting to Integrity is cheaper both in & revenue costs and capital expenditure.  > Putting a DLT on is likely to be problematical since there are' suprisingly few DLTs around these days.    Steve    JF Mezei wrote:  > Dave Froble wrote:K > > It's unfortunate that the word 'migrate' was used.  Upgrading to CHARON K > > means still running VMS.  Plenty of VMS applications don't run on Linux  > > and windoz.  > F > From a management point of view, it is still a project that requiresG > RFP, budgeting ,approval etc etc. To PHBs, it looks like a migration.  > I > If those VAXes are still there and at 5.5, it is likely that management G > do not wish to spend any money to upgrade those machines and that the F > next spending for those application will involve porting to a modern: > platform that is alive and well. (aka Linux or Windows). > I > Pushing for such an "upgrade" to Charon VAX may result in the loss of a 5 > VMS shop faster than would have otherwise happened.  > F > Surely it is cheaper to find a backup solution for this chap than toI > suggest he change all his hardware and upgrade his software at what may G > be great costs to him. How much would HP charge for software upgrades - > from VMS 5.5 to 7.3 for multiple machines ?    ------------------------------  % Date: Thu, 17 Aug 2006 07:51:35 -0700 * From: "Tom Linden" <tom@kednos-remove.com> Subject: Shadow set problem ) Message-ID: <op.tefnj9cvtte90l@hyrrokkin>   3 Have following  cluster of Alphas, except as noted.     i ┌───────────────────────┬─────────┐ ) │        SYSTEMS        │ MEMBERS │ i ├────────┬──────────────┼─────────┤ + │  NODE  │   SOFTWARE   │  STATUS │ i ├────────┼──────────────┼─────────┤ ; │ HAFNER │ VMS V7.3-2   │ MEMBER  │---------------- < │ HERMES │ VMS V7.3     │ MEMBER  │  VAX           |T │ ODIN   │ VMS F8.3     │ MEMBER  │-------------------- Shared SCSI Shadow  	 on BA3256 < │ NORNS  │ VMS V7.3-1   │ MEMBER  │                |; │ FREJA  │ VMS V8.2     │ MEMBER  │---------------- i └────────┴──────────────┴─────────┘     J I have three two member shadow sets and I noted that one of the sets is no longer mounted  A $42$DKA800:   (HAFNER)  ShadowSetMember      1  (member of DSA1:) A $42$DKA900:   (HAFNER)  ShadowSetMember      0  (member of DSA1:) A $42$DKA1000:  (HAFNER)  ShadowSetMember      1  (member of DSA2:) A $42$DKA1100:  (HAFNER)  ShadowSetMember      0  (member of DSA2:) . $42$DKA1200:  (HAFNER)  Online               1A $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:)    So I have two questions   E 1.  To add the member back in, is it the same command that I use at    startup, viz.,
 $     MOUNT   J DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=($42$DKA1200:,$42$DKA1300:)   COMMON3 2.  How do I determine why it is no longer mounted?    Tom    ------------------------------    Date: 17 Aug 2006 09:09:53 -0700 From: bill@wcschmidt.com Subject: Re: Shadow set problem B Message-ID: <1155830993.244531.25020@b28g2000cwb.googlegroups.com>  L Rmlyc3QgcGxhY2UgdG8gbG9vayBpcyBpbiB0aGUgb3BlcmF0b3IubG9nLCAgMm5kIHBsYWNlIGlzL IERJQQoKU2V2ZXJhbCB0aGluZ3MgY2FuIGNhdXNlIG1lbWJlciB0byBkcm9wLgoKQmlsbAoKVG9tL IExpbmRlbiB3cm90ZToKPiBIYXZlIGZvbGxvd2luZyAgY2x1c3RlciBvZiBBbHBoYXMsIGV4Y2VwL dCBhcyBub3RlZC4KPgo+Cj4gpqOmoaahpqGmoaahpqGmoaahpqGmoaahpqGmoaahpqGmoaahpqGmL oaahpqGmoaahpqimoaahpqGmoaahpqGmoaahpqGmpAo+IKaiICAgICAgICBTWVNURU1TICAgICAgL ICCmoiBNRU1CRVJTIKaiCj4gpqemoaahpqGmoaahpqGmoaahpqimoaahpqGmoaahpqGmoaahpqGmL oaahpqGmoaahpqumoaahpqGmoaahpqGmoaahpqGmqQo+IKaiICBOT0RFICCmoiAgIFNPRlRXQVJFL ICAgpqIgIFNUQVRVUyCmogo+IKanpqGmoaahpqGmoaahpqGmoaarpqGmoaahpqGmoaahpqGmoaahL pqGmoaahpqGmoaarpqGmoaahpqGmoaahpqGmoaahpqkKPiCmoiBIQUZORVIgpqIgVk1TIFY3LjMtL MiAgIKaiIE1FTUJFUiAgpqItLS0tLS0tLS0tLS0tLS0tCj4gpqIgSEVSTUVTIKaiIFZNUyBWNy4zL ICAgICCmoiBNRU1CRVIgIKaiICBWQVggICAgICAgICAgIHwKPiCmoiBPRElOICAgpqIgVk1TIEY4L LjMgICAgIKaiIE1FTUJFUiAgpqItLS0tLS0tLS0tLS0tLS0tLS0tLSBTaGFyZWQgU0NTSSBTaGFkL b3cKPiBvbiBCQTMyNTYKPiCmoiBOT1JOUyAgpqIgVk1TIFY3LjMtMSAgIKaiIE1FTUJFUiAgpqIgL ICAgICAgICAgICAgICAgfAo+IKaiIEZSRUpBICCmoiBWTVMgVjguMiAgICAgpqIgTUVNQkVSICCmL oi0tLS0tLS0tLS0tLS0tLS0KPiCmpqahpqGmoaahpqGmoaahpqGmqqahpqGmoaahpqGmoaahpqGmL oaahpqGmoaahpqGmqqahpqGmoaahpqGmoaahpqGmoaalCj4KPgo+IEkgaGF2ZSB0aHJlZSB0d28gL bWVtYmVyIHNoYWRvdyBzZXRzIGFuZCBJIG5vdGVkIHRoYXQgb25lIG9mIHRoZSBzZXRzIGlzIG5vL Cj4gbG9uZ2VyIG1vdW50ZWQKPgo+ICQ0MiRES0E4MDA6ICAgKEhBRk5FUikgIFNoYWRvd1NldE1lL bWJlciAgICAgIDEgIChtZW1iZXIgb2YgRFNBMTopCj4gJDQyJERLQTkwMDogICAoSEFGTkVSKSAgL U2hhZG93U2V0TWVtYmVyICAgICAgMCAgKG1lbWJlciBvZiBEU0ExOikKPiAkNDIkREtBMTAwMDogL IChIQUZORVIpICBTaGFkb3dTZXRNZW1iZXIgICAgICAxICAobWVtYmVyIG9mIERTQTI6KQo+ICQ0L MiRES0ExMTAwOiAgKEhBRk5FUikgIFNoYWRvd1NldE1lbWJlciAgICAgIDAgIChtZW1iZXIgb2YgL RFNBMjopCj4gJDQyJERLQTEyMDA6ICAoSEFGTkVSKSAgT25saW5lICAgICAgICAgICAgICAgMQo+L ICQ0MiRES0ExMzAwOiAgKEhBRk5FUikgIFNoYWRvd1NldE1lbWJlciAgICAgIDAgIChtZW1iZXIgL b2YgRFNBMDopCj4KPiBTbyBJIGhhdmUgdHdvIHF1ZXN0aW9ucwo+Cj4gMS4gIFRvIGFkZCB0aGUgL bWVtYmVyIGJhY2sgaW4sIGlzIGl0IHRoZSBzYW1lIGNvbW1hbmQgdGhhdCBJIHVzZSBhdAo+IHN0L YXJ0dXAsIHZpei4sCj4gJCAgICAgTU9VTlQKPiBEU0EwOi9DTFVTVEVSL05PQVNTSVNUL0lOQ0xVL REUvTk9DT1BZL1NIQURPVz0oJDQyJERLQTEyMDA6LCQ0MiRES0ExMzAwOikKPiBDT01NT04KPiAyL LiAgSG93IGRvIEkgZGV0ZXJtaW5lIHdoeSBpdCBpcyBubyBsb25nZXIgbW91bnRlZD8KPiAKPiBU b20K   ------------------------------  % Date: Thu, 17 Aug 2006 18:06:37 +0200 / From: Paul Sture <paul.sture.nospam@hispeed.ch>  Subject: Re: Shadow set problem J Message-ID: <paul.sture.nospam-7BA18C.18063717082006@mac.sture.homeip.net>  ) In article <op.tefnj9cvtte90l@hyrrokkin>, ,  "Tom Linden" <tom@kednos-remove.com> wrote:  5 > Have following  cluster of Alphas, except as noted.  >  > k > ┌───────────────────────┬─────────┐ + > │        SYSTEMS        │ MEMBERS │ k > ├────────┬──────────────┼─────────┤ - > │  NODE  │   SOFTWARE   │  STATUS │ k > ├────────┼──────────────┼─────────┤ = > │ HAFNER │ VMS V7.3-2   │ MEMBER  │---------------- > > │ HERMES │ VMS V7.3     │ MEMBER  │  VAX           |N > │ ODIN   │ VMS F8.3     │ MEMBER  │-------------------- Shared SCSI 
 > Shadow   > on BA3256 > > │ NORNS  │ VMS V7.3-1   │ MEMBER  │                |= > │ FREJA  │ VMS V8.2     │ MEMBER  │---------------- k > └────────┴──────────────┴─────────┘  >  > L > I have three two member shadow sets and I noted that one of the sets is no > longer mounted > C > $42$DKA800:   (HAFNER)  ShadowSetMember      1  (member of DSA1:) C > $42$DKA900:   (HAFNER)  ShadowSetMember      0  (member of DSA1:) C > $42$DKA1000:  (HAFNER)  ShadowSetMember      1  (member of DSA2:) C > $42$DKA1100:  (HAFNER)  ShadowSetMember      0  (member of DSA2:) 0 > $42$DKA1200:  (HAFNER)  Online               1C > $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:)  >  > So I have two questions  > G > 1.  To add the member back in, is it the same command that I use at    > startup, viz., > $     MOUNT   L > DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=($42$DKA1200:,$42$DKA1300:)   > COMMON   Yes.  5 > 2.  How do I determine why it is no longer mounted?  >   N At first pass, look through your OPERATOR.LOG for shadow member state changes.E Depending on what that reveals, you might need to dig into the error   logs.    --  
 Paul Sture   ------------------------------    Date: 17 Aug 2006 11:24:21 -0500 From: briggs@encompasserve.org Subject: Re: Shadow set problem 3 Message-ID: <SkERd2EAu7o9@eisner.encompasserve.org>   V In article <op.tefnj9cvtte90l@hyrrokkin>, "Tom Linden" <tom@kednos-remove.com> writes:0 > $42$DKA1200:  (HAFNER)  Online               1C > $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:)  >  > So I have two questions  > G > 1.  To add the member back in, is it the same command that I use at    > startup, viz., > $     MOUNT   L > DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=($42$DKA1200:,$42$DKA1300:)   > COMMON  & You do not want the /NOCOPY qualifier.  D When you mount the new member, you want it to be brought up to date.C If you use /NOCOPY and an a copy operation is required to bring the D new member up to date, VMS will simply refuse to add the new member.  L You may want the /CONFIRM qualifier instead.  If a copy operation is needed,D /CONFIRM will give you a chance to verify that it involves the disksB you expect in the direction you expect and answer yes or no before the copy is actually initiated.    You may not want /INCLUDE   C The effect of /INCLUDE is to automatically include the members that ? were previously in the shadow set.  But you're already manually C specifying them.  So /INCLUDE is redundant (but probably won't hurt 
 anything).  F Other than that, yes.  The command you give is fine.  And even without= my suggested changes, executing it won't do anything harmful.   5 > 2.  How do I determine why it is no longer mounted?   I Look at the operator log: sys$manager:operator.log and possibly the error  log.   ------------------------------  % Date: Thu, 17 Aug 2006 10:11:20 -0700 * From: "Tom Linden" <tom@kednos-remove.com> Subject: Re: Shadow set problem ) Message-ID: <op.teft06hntte90l@hyrrokkin>   E On Thu, 17 Aug 2006 09:24:21 -0700, <briggs@encompasserve.org> wrote:   ; > In article <op.tefnj9cvtte90l@hyrrokkin>, "Tom Linden"  =   ! > <tom@kednos-remove.com> writes: 1 >> $42$DKA1200:  (HAFNER)  Online               1 D >> $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:) >> >> So I have two questions >>F >> 1.  To add the member back in, is it the same command that I use at >> startup, viz.,  >> $     MOUNTI >> DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=3D($42$DKA1200:,$42$DKA1=  300:) 	 >> COMMON  > ( > You do not want the /NOCOPY qualifier. > F > When you mount the new member, you want it to be brought up to date.E > If you use /NOCOPY and an a copy operation is required to bring the F > new member up to date, VMS will simply refuse to add the new member. > I > You may want the /CONFIRM qualifier instead.  If a copy operation is  =   	 > needed, F > /CONFIRM will give you a chance to verify that it involves the disksD > you expect in the direction you expect and answer yes or no before! > the copy is actually initiated.  >  > You may not want /INCLUDE  > E > The effect of /INCLUDE is to automatically include the members that A > were previously in the shadow set.  But you're already manually E > specifying them.  So /INCLUDE is redundant (but probably won't hurt  > anything). > I > Other than that, yes.  The command you give is fine.  And even without=   ? > my suggested changes, executing it won't do anything harmful.  > 6 >> 2.  How do I determine why it is no longer mounted? > I > Look at the operator log: sys$manager:operator.log and possibly the er=  ror  > log.   HAFNER> MOUNT  =  I DSA0:/CLUSTER/NOASSIST/INCLUDE/SHADOW=3D($42$DKA1200:,$42$DKA1300:) COMM=  ON* %MOUNT-I-MOUNTED, COMMON mounted on _DSA0:I %MOUNT-I-SHDWMEMFAIL, _$42$DKA1200: (HAFNER) failed as a member of the  =   
 shadow set# -SYSTEM-F-MEDOFL, medium is offline E %MOUNT-I-ISAMBR, _$42$DKA1300: (HAFNER) is a member of the shadow set   ( Didn't see anything in the operator.log.   Maybe I'll try a spare drive -- =  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Thu, 17 Aug 2006 10:18:42 -0700 * From: "Tom Linden" <tom@kednos-remove.com> Subject: Re: Shadow set problem ) Message-ID: <op.tefudgmvtte90l@hyrrokkin>   I On Thu, 17 Aug 2006 10:11:20 -0700, Tom Linden <tom@kednos-remove.com>  =    wrote:  G > On Thu, 17 Aug 2006 09:24:21 -0700, <briggs@encompasserve.org> wrote:  > < >> In article <op.tefnj9cvtte90l@hyrrokkin>, "Tom Linden"  =  " >> <tom@kednos-remove.com> writes:2 >>> $42$DKA1200:  (HAFNER)  Online               1E >>> $42$DKA1300:  (HAFNER)  ShadowSetMember      0  (member of DSA0:)  >>>  >>> So I have two questions  >>> G >>> 1.  To add the member back in, is it the same command that I use at  >>> startup, viz., >>> $     MOUNT I >>> DSA0:/CLUSTER/NOASSIST/INCLUDE/NOCOPY/SHADOW=3D($42$DKA1200:,$42$DKA=  1300:)
 >>> COMMON >>) >> You do not want the /NOCOPY qualifier.  >>G >> When you mount the new member, you want it to be brought up to date. F >> If you use /NOCOPY and an a copy operation is required to bring theG >> new member up to date, VMS will simply refuse to add the new member.  >>I >> You may want the /CONFIRM qualifier instead.  If a copy operation is =   =  
 >> needed,G >> /CONFIRM will give you a chance to verify that it involves the disks E >> you expect in the direction you expect and answer yes or no before " >> the copy is actually initiated. >> >> You may not want /INCLUDE >>F >> The effect of /INCLUDE is to automatically include the members thatB >> were previously in the shadow set.  But you're already manuallyF >> specifying them.  So /INCLUDE is redundant (but probably won't hurt
 >> anything).  >>I >> Other than that, yes.  The command you give is fine.  And even withou=  t @ >> my suggested changes, executing it won't do anything harmful. >>7 >>> 2.  How do I determine why it is no longer mounted?  >>I >> Look at the operator log: sys$manager:operator.log and possibly the  =    >> error >> log.  >  > HAFNER> MOUNT  =  I > DSA0:/CLUSTER/NOASSIST/INCLUDE/SHADOW=3D($42$DKA1200:,$42$DKA1300:) CO=  MMON, > %MOUNT-I-MOUNTED, COMMON mounted on _DSA0:I > %MOUNT-I-SHDWMEMFAIL, _$42$DKA1200: (HAFNER) failed as a member of the=    =    > shadow set% > -SYSTEM-F-MEDOFL, medium is offline G > %MOUNT-I-ISAMBR, _$42$DKA1300: (HAFNER) is a member of the shadow set  > * > Didn't see anything in the operator.log. >  > Maybe I'll try a spare drive   Bingo!   HAFNER> MOUNT  =  I DSA0:/CLUSTER/NOASSIST/INCLUDE/SHADOW=3D($42$DKA1200:,$42$DKA1300:) COMM=  ON* %MOUNT-I-MOUNTED, COMMON mounted on _DSA0:I %MOUNT-I-SHDWMEMCOPY, _$42$DKA1200: (HAFNER) added to the shadow set wit=  h  =   a copy operationE %MOUNT-I-ISAMBR, _$42$DKA1300: (HAFNER) is a member of the shadow set      -- =  E Using Opera's revolutionary e-mail client: http://www.opera.com/mail/    ------------------------------  % Date: Thu, 17 Aug 2006 11:00:33 -0400 ' From: "Main, Kerry" <Kerry.Main@hp.com> " Subject: RE: Speaking of Clusters:T Message-ID: <FA60F2C4B72A584DBFC6091F6A2B8684018BDF89@tayexc19.americas.cpqcorp.net>   > -----Original Message-----7 > From: Andrew [mailto:andrew_harrison@symantec.com]=20   > Sent: August 10, 2006 12:02 PM > To: Info-VAX@Mvb.Saic.Com $ > Subject: Re: Speaking of Clusters: >=20 >=20 > Bill Todd wrote: > > Keith Parris wrote: % > > > david20@alpha2.mdx.ac.uk wrote: A > > >> Never having used AIX I didn't recognise HACMP and made=20  > the erronious ; > > >> assumption from context that it was another Linux=20  > failover solution.? > > >> I'm quite happy to accept your word that it is a good=20  > cluster solution.  > > > ? > > > HACMP is a run-of-the-mill UNIX High-Availability (HA)=20  > cluster solution, ? > > > roughly comparable to what TruCluster could do back in=20  > the ASE days > > > (pre-V5.0).  > > B > > Not when you include available extensions like GPFS and the=20 > HACMP DLM,
 > > it isn't.  > > A > >   Focus is all on failover. You see the typical references to C > > > heartbeat, failover scripts, and active and "takeover" nodes.  > > > = > > > It's interesting that IBM must define the term "high=20  > availability" toD > > > include some implied downtime, as their solution can't provideF > > > continuous application availability like an OpenVMS cluster can.> > > > (From "High Availability Cluster Multi-Processing for=20 > AIX: Concepts and  > > > Facilities Guide"=206 > http://publib.boulder.ibm.com/epubs/pdf/c2348646.pdf9 > > > "The difference between fault tolerance and high=20  > availability, then, is: > > > this: a fault tolerant environment has no service=20 > interruption, while a ; > > > highly available environment has a minimal service=20  > interruption. ManyF > > > sites are willing to absorb a small amount of downtime with high= > > > availability rather than pay the much higher cost of=20  > providing fault B > > > tolerance. ... High availability systems are an excellent=20 > solution for= > > > applications that can withstand a short interruption=20  > should a failure= > > > occur, but which must be restored quickly." By IBM's=20  > definition, OpenVMS 8 > > > Clusters achieve Fault Tolerance, not just High=20 > Availability (and inF > > > practice they actually do so at no additional cost beyond what's& > > > required for High Availability.) > > ? > > I suspect you just don't understand what IBM is saying: =20  > their reference A > > to 'short interruption' appears to be to fail-over latency=20  > (measured inG > > seconds, just as VMS cluster state transitions are), rather than to B > > 'down time' per se (i.e., actual periods when a client sees=20
 > the service H > > as unavailable - not there at all - rather than merely brief service# > > delays as a transition occurs).  > > > > > IBM's definition of 'fault tolerance' is also something=20 > which you don't 9 > > appear to understand:  it refers to *zero*-latency=20  > interruptions when aA > > fault occurs - because a second system executing the *same=20  > workload* in; > > parallel just picks up the workload instantly as the=20  > failing system is > > > fenced out.  This is not, of course, what a VMS cluster=20 > provides - you@ > > need to look to systems like Tandem's or Parallel Sysplex=20
 > to find it, G > > though IIRC Sun has products in that area and some even exist for - < > > gasp! - Windows (Stratus, still, and perhaps Marathon?). > > H > I would agree, neither HACMP or OpenVMS clusters meet IBM's definitionH > of fault tolerance because both of them have failover or cluster stateE > transition times that are measured in seconds rather than subsecond E > switching to a second system/component running the same code at the H > same point in the code as the failed component/system which you see inA > an FT system. In addition because the FT systems are running in > > hardware or software lock-step the switching time is very=20 > well defined, G > this is not the case with failover or CST. Sure CST is within a range H > of values but this is not good enough for some classes of application. >=20F > In telco environments Tandem and Stratus were commonplace componentsG > providing an interface between the network switches using SS7 and the H > rest of the computing infrastructure. Without a FT device connected toB > the switch SS7 traffic which might include important CDR billing= > information could be dropped resulting loss or revenue etc.  >=20H > Conventional cluster based high availability solutions such as OpenVMS? > Clustering or HACMP could not meet this requirment because=20  > the failoverE > time/CST time was too long and would result in dropped SS7 traffic.  >=20D > In practice the demand for FT systems has declined in part becauseG > middleware has become more sophisticated, replicating enough state to D > ensure that if a failure happens it happens with minimal impact to
 > clients. >=20H > Bill mentioned Sun but most of the J2EE environments including the SunH > one which uses the Clustra product have the ability to replicate stateG > information across the nodes in the application server infrastructure F > so that when a app server fails the clients are not impacted. CoupleH > this with Oracle RAC configured for HA at the back end and you have an> > software and hardware infrastructure that has some of the=20 > attributes of  > a FT system. >=20 >=20	 > Regards  > Andrew Harrison  >=20  G OpenVMS Clusters provide very high availability - including multi-site, - load balanced solutions, not FT solutions.=20   E For software based fault tolerant solutions with OpenVMS (a committed B transaction is never lost - even with site or major router network; failures), you would use RTR + OpenVMS multi-site clusters.   
 Reference:* http://www.hp.com/products1/rtr/index.html   Regards   
 Kerry Main Senior Consultant  HP Services Canada Voice: 613-592-4660  Fax: 613-591-4477  kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20  8 OpenVMS - the secure, multi-site OS that just works.>=20   ------------------------------  % Date: Thu, 17 Aug 2006 02:56:36 -0400 ' From: Dave Froble <davef@tsoft-inc.com> . Subject: Re: The race for 8086 servers is on !9 Message-ID: <CcKdnchTDd_rjHnZnZ2dnUVZ_oydnZ2d@libcom.com>    JF Mezei wrote:  > Dave Froble wrote:G >> He's just stubbornly waiting for a chocolate bribe.  Problem is that A >> he's already indicated he won't stay bought and will insist on  >> continuing bribes.  >>G >> I've been considering a special batch of chocolate for him, with rat  >> poison a major ingredient > J > Good luck sending that through customs...  And I never said that I wouldE > be the one eating all the chocolate :-) :-) So you might in fact be C > killing off innocent people and I would survive. (think Inspector  > Cluseau... :-)  E That's fine.  The return address will be yours also.  Then Inspector  9 Cluseau's friends will come for you.  Still gets results.   I Haven't you seen enough complaints from many people?  Hey, you even save   a keystroke by using x64.    --  4 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: 17 Aug 2006 08:25:35 -0700' From: "bclaremont" <msi1@earthlink.net> . Subject: Re: The race for 8086 servers is on !C Message-ID: <1155828334.916990.139050@h48g2000cwc.googlegroups.com>   G Porting VMS to other processors would be a wise move, helping reinforce E the survivability of the O/S.  Tieing an O/S to a single architecture  in this day and age is foolish.   E Unfortunately, at its business core HP still views an O/S as a way to E move iron, rather that as a standalone product that can generate it's E own revenue stream (Linux is an up and coming example of the latter). G Until this attitude changes, the long term survivability of VMS remains  at risk.   ------------------------------    Date: 16 Aug 2006 23:16:10 -0700/ From: "Volker Halle" <volker_halle@hotmail.com> : Subject: Re: Unexpected output from IO AUTOCONFIGURE /FULLC Message-ID: <1155795370.729297.116680@m79g2000cwm.googlegroups.com>    Dave,   D the %IOGEN-I-ACTIVATE informational messages are expected when using the /FULL qualifier.   Volker.    ------------------------------    Date: 17 Aug 2006 08:27:51 -0500; From: koehler@eisner.nospam.encompasserve.org (Bob Koehler)  Subject: Re: VAX/VMS site 3 Message-ID: <mGClO4aMe335@eisner.encompasserve.org>   ^ In article <44E3665A.56435B6D@vaxination.ca>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes: > contracer11@gmail.com wrote:- >> - 6 VAX 4000-100 running OpenVMS V5.5-2H4. I >>  I dont need tell you diary suffering to mounting 8 dat tapes in each  > J >> (We have a HP storage with terabytes there, storying Solaris and Oracle
 >> files). > J > Ubfortunatly, at 5.5, VMS didn't have much connectivity with the outside > world (aka TCPIP).  G    Multinet on VMS 5.5 provides great TCPIP connectivity to the outside 	    world.    ------------------------------    Date: 17 Aug 2006 08:53:50 -0700' From: "bclaremont" <msi1@earthlink.net>  Subject: Re: VAX/VMS site B Message-ID: <1155830030.002147.251150@i3g2000cwc.googlegroups.com>  G If you are stuck on VMS V5.5-2H4, then a port to CHARON-VAX is a viable D alternative.  You could then take advantage of the underlying modernA hardware to improve your backup process.  In your situation using G CHARON-VAX, I would switch the backups to purpose built container files A and the transmit the backup container files across the network to 4 another location and/or archive them to tape/CD/DVD.  ? It is possible a similar solution could be built using the SimH 	 emulator.    -    Bruce Claremont    Improves with age: Wine Wisdom OpenVMS    ------------------------------  % Date: Thu, 17 Aug 2006 03:00:21 -0400 ' From: Dave Froble <davef@tsoft-inc.com> / Subject: Re: VMS backup: competition from Apple 9 Message-ID: <CcKdnctTDd_Lj3nZnZ2dnUVZ_oydnZ2d@libcom.com>    Russell Wallace wrote:! > david20@alpha2.mdx.ac.uk wrote: D >> But 32 cores ?  I'd imagine that that would be well over the SMP  >> performanceF >> peak for desktop use. The performance improvement of adding in the F >> extra cores against the scheduling overhead would gain you nothing. > K > For a word processor, you're probably right. On the other hand games are  H > a significant driver, and the number of things that could usefully be ? > done in parallel in a complex game is easily in the millions.  >   H AMD now is using over 1200 pins for their planned 4 core chips.  Wonder 1 how many pins they'll require for a 32 core chip?    --  4 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: 17 Aug 2006 03:20:13 -0700- From: "Andrew" <andrew_harrison@symantec.com> / Subject: Re: VMS backup: competition from Apple B Message-ID: <1155810012.974633.266040@75g2000cwc.googlegroups.com>   david20@alpha2.mdx.ac.uk wrote: a > In article <1155128452.672820.158060@m73g2000cwd.googlegroups.com>, bob@instantwhip.com writes:  > > " > >david20@alpha2.mdx.ac.uk wrote: > >>. > >> What will a desktop PC do with 32 cores ?5 > >> What 32 things will it be running concurrently ?  > > F > >thats the solution for the x86 boat anchor ... run cpus because the > >cpu itself stinks ... > > ? > >thats what sun and other vendors had to do to compete with a  > >single alpha chip ... > >   @ Sun's multi-core strategy and for that matter AMD and Intels hadF absolutely nothing to do with competing with Alpha. Alpha was allreadyF dead when Sun bought the company who did the origional Niagara design.  F Sun did multi-core because it saved power, reduced heat and because itE was much simpler to do than continuing to attempt to crank out faster D and faster single threaded or slightly threaded modules. You can betB your bottom dollar that if Alpha was still being designed that theD Alpha roadmap would have included multi-core multi-threaded modules.   > F > Come off it Bob. Alphas EV8 was heading down the same path of addingA > performance by increasing the number of concurrent threads that B > could be run - it's just it was using hyperthreading rather than > multiple cores.  > H > >when your chip stinks and you are out of ideas, run 80000 of them ... > > ? > >ibms power 6 blows this crap away, and alpha could have been < > >there also except a bunch of suits who know nothing aboutB > >computer engineering has dumbed down the IT world ... pathetic! > > 2 > Power has been dual core since at least Power 4.  B I don't normally make predictions but my bet is that Power 6 and IB assume there will be a Power 6+ will be the last really large letsD clock this thing as fast as possible and execute a thread as fast asD possible design for servers. Yes Power 6 is multi-core and yes it isC multi-threaded but it is still using most of the transistor largess D available to it because of Moores Law to clock quicker and therefore execute threads quicker.  E Sun, AMD and Intel have all taken a different route and the sucess of ? Sun's Niagara processor shows that the market is ready for very B agressively threaded and cored modules where the performance of an# individual thread is realively low.   D The only market where this may not be the case is the desktop marketE but then Power 6 and its follow ons are not designed for that anyway.    regards  Andrew Harrison    ------------------------------   End of INFO-VAX 2006.457 ************************