1 INFO-VAX	Wed, 21 Jun 2000	Volume 2000 : Issue 344       Contents:. Affordable Debate Summary (was: VAX on Intel?)9 Re: Alpha DEC 2000-300 (Jensen?) - Serial port as console 9 RE: Alpha DEC 2000-300 (Jensen?) - Serial port as console 9 Re: Alpha DEC 2000-300 (Jensen?) - Serial port as console 0 Archiving many widely scattered files, best way?4 Re: Archiving many widely scattered files, best way?  Re: Besides Pathworks for Mac...% Re: Compaq C v6.2 Single User License " Compaq paying for software ports ?% Re: Fast ethernet on micro-vax series % Re: Fast ethernet on micro-vax series  re: Fun VMS Facts? Re: Fun VMS Facts? Looking for VAX ARM right now.$ Re: Mitnick (was Re: Fun VMS Facts?)$ Re: Mitnick (was Re: Fun VMS Facts?)$ Re: Mitnick (was Re: Fun VMS Facts?)$ Re: Mitnick (was Re: Fun VMS Facts?)! Re: Mitnick -- was Fun VMS Facts? ' Monitoring Tool for CIS app on Open VMS . RE: OpenVMS clusters vs other systems clusters. Re: OpenVMS clusters vs other systems clusters. Re: OpenVMS clusters vs other systems clustersA RE: OpenVMS commentaries (was Re: Gartner commentary on Wildfire) A Re: OpenVMS commentaries (was Re: Gartner commentary on Wildfire)  Re: OpenVMS Customer Database  Re: OpenVMS Customer Database  Re: OpenVMS Customer Database % OpenVMS UCX/FTP and Internet Explorer  print files 5 Re: Proxy problem: Why does node:: work but 0:: fail?  QUEUE ENTRY NUMBERS... RE: QUEUE ENTRY NUMBERS...+ request for new linker error: "multinclude"  SLS and TL891 Robot A Re: Storage Works / Snapshots / Maybe it's (NOT) time to skip VMS A Re: Storage Works / Snapshots / Maybe it's (NOT) time to skip VMS ? Re: Storage Works / Snapshots / Maybe it's time to skip OpenVMS ? Re: Storage Works / Snapshots / Maybe it's time to skip OpenVMS ? Re: Storage Works / Snapshots / Maybe it's time to skip OpenVMS # RE: Techwise report on availability  Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX on Intel? P ~-~ Save up to 70% on Your Life Insurance -FREE Quote                       +a#n  F ----------------------------------------------------------------------  % Date: Tue, 20 Jun 2000 21:23:36 -0500 7 From: "David J. Dachtera" <djesys.nospam@earthlink.net> 7 Subject: Affordable Debate Summary (was: VAX on Intel?) - Message-ID: <39502728.88FF33E2@earthlink.net>   < Here's my assessment of the situation. Your mileage may vary considerably from this...   . To summarize, there are essentially two camps:   In Compaq's corner:  o Bill Todd  o Larry Kilgallen  o others  F These are the folks trying to drum Compaq's position into the folks inF the other corner: that Compaq is intentionally abandoning all but it's- biggest and most lucrative OpenVMS customers.    In the Customers' corner:  o David J. Dachtera  o Chris Sheers o others  F These are the folks trying to drum the customers' position into CompaqF before the remaining "low end" and "middle end(?)" customers defect toC the competition and OpenVMS ends up with a weak market which cannot  sustain itself.    Summary  -------   . Essentially, the two camps are at an impasse.   E The Pro-Compaq camp has adopted the "company" line and feels that the E other side is wrong for wanting to stay in the OepnVMS business. In a G nutshell, their message is tantamount to "Compaq has turned its back on F you. Get over it. Move on." They also tend to equate "affordable" with> "IA32", even though the two are separate, but related, issues.  @ The Pro-Customer camp maintains the position that the customer'sC decision to commit to OpenVMS should not be second guessed and that C Compaq should exploit this market instead of abandoning it. Neither E should we, as business people, be penalized for our choice to support H these customers since our costs to retrain on other systems take a large  toll on our profits and margins.  A Again, this is my assessment. Your mileage may vary considerably.    --   David J. Dachtera  dba DJE Systems " http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/    ------------------------------  % Date: Tue, 20 Jun 2000 23:47:14 +0100 5 From: "Adrian Lumsden" <A.Lumsden@spamtrap.xdt.co.uk> B Subject: Re: Alpha DEC 2000-300 (Jensen?) - Serial port as console/ Message-ID: <8iosjp$ktc$2@newsg3.svr.pol.co.uk>   , I think the floppy is OK. I have just done a- BACKUP /PHYSICAL/VERIFY from the ECU diskette 5 to a saveset in a file and then done the reverse back 4 to another floppy. It didn't report any verification. errors. I also did an ANALYZE /MEDIA/EXER=FULL9 on the second floppy and that didn't report any problems.   3 The good (strange) news is that the copy of the ECU 2 floppy does seem to run. The bad news is to figure0 out what I have to do with it. I'm familiar with- EISA configurations on PCs (quite a few years , ago now) but I'm a bit worried about messing3 with the configuration of this system since I don't 2 have any documentation about environment variables etc.   Any hints or tips?     regards,   Adrian   --( Adrian Lumsden, XDT Computer Systems, UK" A dot Lumsden at xdt dot co dot uk      0 Chris Scheers <asi@airmail.net> wrote in messageH news:CE5B02EF3F5B5EA7.B8D8169CB4984F60.08C428401472CAAA@lp.airnews.net.. .  > Adrian Lumsden wrote:  > > 7 > > I have found SET CONSOLE SERIAL and have managed to & > > install OpenVMS onto this machine. > > 9 > > I still have problems with the graphics cards and the 7 > > EISA Configuration Utility. Does anybody know where 6 > > I can get a new copy of the ECU from? Does anybody0 > > have any information about the graphics card= > > (a Compaq QVision 1024/e) and are there any alternatives?  > H > AFAIK, the QVision 1024E is THE graphics card for VMS on the DEC 2000.H > (Well, a QVision 1280E will work, but only at 1024x768, so there is no > advantage over the 1024E.) > F > RE the ECU problem:  Do you know whether or not your floppy drive is > good?  > H > ---------------------------------------------------------------------- - & > Chris Scheers, Applied Synergy, Inc. > 9 > 817-237-3360 (Voice)    817-237-3074 (Fax)    Internet:  asi@airmail.net    ------------------------------  % Date: Tue, 20 Jun 2000 20:49:20 -0400 + From: "Main, Kerry" <Kerry.Main@compaq.com> B Subject: RE: Alpha DEC 2000-300 (Jensen?) - Serial port as consoleJ Message-ID: <910612C07BCAD1119AF40000F86AF0D805284435@kaoexc4.kao.dec.com>   Adrian,    >>> Any hints or tips?<<<   G This should answer your questions: firmware pointer and release notes - . http://ftp.digital.com/pub/DEC/Alpha/firmware/B http://ftp.digital.com/pub/DEC/Alpha/firmware/readmes/dec2000.html   Regards,    
 Kerry Main Senior Consultant,
 Compaq Canada  Professional Services  Voice : 613-592-4660 FAX   : 819-772-7036 Email : kerry.main@compaq.com        -----Original Message-----: From: Adrian Lumsden [mailto:A.Lumsden@spamtrap.xdt.co.uk]$ Sent: Tuesday, June 20, 2000 6:47 PM To: Info-VAX@Mvb.Saic.Com B Subject: Re: Alpha DEC 2000-300 (Jensen?) - Serial port as console    , I think the floppy is OK. I have just done a- BACKUP /PHYSICAL/VERIFY from the ECU diskette 5 to a saveset in a file and then done the reverse back 4 to another floppy. It didn't report any verification. errors. I also did an ANALYZE /MEDIA/EXER=FULL9 on the second floppy and that didn't report any problems.   3 The good (strange) news is that the copy of the ECU 2 floppy does seem to run. The bad news is to figure0 out what I have to do with it. I'm familiar with- EISA configurations on PCs (quite a few years , ago now) but I'm a bit worried about messing3 with the configuration of this system since I don't 2 have any documentation about environment variables etc.   Any hints or tips?     regards,   Adrian   --( Adrian Lumsden, XDT Computer Systems, UK" A dot Lumsden at xdt dot co dot uk      0 Chris Scheers <asi@airmail.net> wrote in messageH news:CE5B02EF3F5B5EA7.B8D8169CB4984F60.08C428401472CAAA@lp.airnews.net.. .  > Adrian Lumsden wrote:  > > 7 > > I have found SET CONSOLE SERIAL and have managed to & > > install OpenVMS onto this machine. > > 9 > > I still have problems with the graphics cards and the 7 > > EISA Configuration Utility. Does anybody know where 6 > > I can get a new copy of the ECU from? Does anybody0 > > have any information about the graphics card= > > (a Compaq QVision 1024/e) and are there any alternatives?  > H > AFAIK, the QVision 1024E is THE graphics card for VMS on the DEC 2000.H > (Well, a QVision 1280E will work, but only at 1024x768, so there is no > advantage over the 1024E.) > F > RE the ECU problem:  Do you know whether or not your floppy drive is > good?  > H > ---------------------------------------------------------------------- - & > Chris Scheers, Applied Synergy, Inc. > 9 > 817-237-3360 (Voice)    817-237-3074 (Fax)    Internet:  asi@airmail.net    ------------------------------   Date: 20 Jun 2000 12:05:05 GMTF From: lederman@star.enet.dec.DISABLE-JUNK-EMAIL.com (Bart Z. Lederman)B Subject: Re: Alpha DEC 2000-300 (Jensen?) - Serial port as console, Message-ID: <8inmlh$i7a$1@sniff.shr.dec.com>  f >In article <8ilhcj$kpq$1@news5.svr.pol.co.uk>, "Adrian Lumsden" <A.Lumsden@spamtrap.xdt.co.uk> wrote: > 6 >I still have problems with the graphics cards and the4 >EISA Configuration Utility. Does anybody know where3 >I can get a new copy of the ECU from? Does anybody   :      I believe the ECU utility was licensed from a vendor.2  I'm don't think it's available over the Internet.  @      The FAQ gives the site where you can download firmware, and:  good instructions on how to do the upgrade on a number ofA  platforms, but it doesn't specifically address the ECU.  It does   have the images for the    @      The following site is where firmware updates are available:  . http://ftp.digital.com/pub/DEC/Alpha/firmware/  ?      This page has a lot of information about firmware updates.   ?      To update a "Jensen",  look for the entry in the left-hand @  column under Alpha PC's for DECpc AXP 150 or DEC 2000AXP, which>  will point you to the page where instructions are given for a9  variety of update methods.  This might help you recover.   9      There is also a more general entry point for finding 3  software that Compaq makes available over the net:   8 http://gatekeeper.dec.com/hypertext/gatekeeper.home.html  =      A search of Jensen from here points to a number of files >  (mostly for Linux) which includes the swxcrmgr floppy images.;  I'm not sure if that will help, but you might want to look   at it.   ;      If none of that works, you may have to order one.  The ?  newest copy I've seen is V1.10 and has part number AK-Q2CRK-CA =  on it (this is the Unix / VMS version that gives you the SRM %  console, which is what I recommend).        --  (  B. Z. Lederman   Personal Opinions Only  8  Posting to a News group does NOT give anyone permission8  to send me advertising by E-mail or put me on a mailing  list of any kind.  5  Please remove the "DISABLE-JUNK-EMAIL" if you have a 5  legitimate reason to E-mail a response to this post.    ------------------------------    Date: 20 Jun 2000 16:07:43 -0500+ From: rjordan@Mars.mcs.net (Richard Jordan) 9 Subject: Archiving many widely scattered files, best way? ' Message-ID: <8iomev$s98$1@Mars.mcs.net>   E We have a need to archive several hundred files every few days, with  A sizes ranging from a few blocks to over 500,000 blocks, scattered E over a number of different disks.  Which files are archived will vary D but basically its treated like an incremental backup (files modifiedA since a particular event occured) except for two things: the re-  < quirement to have all the files in a single archive (not oneA save set per involved disk) and the fact that not all files on a  > disk are checked, only those on a specific list (this list canC include wildcards, but only the latest version of a file in a given F directory will be archived).  Since the archive will need to be moved @ across a slow net link, it will be compressed (ZIP), but whetherA ZIP is used as the archiver or just to compress the archive after  the fact is not decided.  B Well, BACKUP preserves the pathnames, but not the device names forB the individual files.  It is also limited by the allowable size of@ the input specifier as to how many files we could put in a givenB save set (wildcards are not usable here).  Using ZIP directly does< allow adding files to the archive one at a time but does notA preserve the pathname or device and gets quite unhappy if there's # more than one file of a given name.   A Maybe I'm missing a simple solution but all I can see are complex B ones.  Creating the list of files to actually archive is easy (andE coded).  Run BACKUP per-drive with /CONFIRM, define input and output  B to mailboxes, and have a process compare the queried filename withA the archive list and answer (Y)es only for those?  That gives one = saveset per disk, but those could then be zipped into a final 
 archive.    , There's got to be a better way to do this...   Rich Jordan  rjordan@mcs.net       ------------------------------   Date: 20 JUN 2000 21:49:57 GMT6 From: greenwoodde@feda34.fed.ornl.gov (Dave Greenwood)= Subject: Re: Archiving many widely scattered files, best way? 2 Message-ID: <20JUN00.21495787@feda34.fed.ornl.gov>  , rjordan@Mars.mcs.net (Richard Jordan) wrote:  B I did something similar several years ago.  Once I had the list ofD files to archive I wrote a .COM to read the list and generate backupC commands by appending filenames until the next one would exceed the E DCL limit.  Then I'd execute the backup command and create a new one. D I also created unique saveset names for each backup command.  If youE have long filespecs this approach may not buy you much (or anything). C My problem was simplified because my "list of files" was actually a E list of *directories*.  Backup itself could select the specific files  in the directory.   G > We have a need to archive several hundred files every few days, with  C > sizes ranging from a few blocks to over 500,000 blocks, scattered G > over a number of different disks.  Which files are archived will vary F > but basically its treated like an incremental backup (files modifiedC > since a particular event occured) except for two things: the re-  > > quirement to have all the files in a single archive (not oneC > save set per involved disk) and the fact that not all files on a  @ > disk are checked, only those on a specific list (this list canE > include wildcards, but only the latest version of a file in a given H > directory will be archived).  Since the archive will need to be moved B > across a slow net link, it will be compressed (ZIP), but whetherC > ZIP is used as the archiver or just to compress the archive after  > the fact is not decided. >   D > Well, BACKUP preserves the pathnames, but not the device names forD > the individual files.  It is also limited by the allowable size ofB > the input specifier as to how many files we could put in a givenD > save set (wildcards are not usable here).  Using ZIP directly does> > allow adding files to the archive one at a time but does notC > preserve the pathname or device and gets quite unhappy if there's % > more than one file of a given name.  >   C > Maybe I'm missing a simple solution but all I can see are complex D > ones.  Creating the list of files to actually archive is easy (andG > coded).  Run BACKUP per-drive with /CONFIRM, define input and output  D > to mailboxes, and have a process compare the queried filename withC > the archive list and answer (Y)es only for those?  That gives one ? > saveset per disk, but those could then be zipped into a final  > archive.   >   . > There's got to be a better way to do this... >   
 > Rich Jordan  > rjordan@mcs.net    --------------9 Dave Greenwood                Email: Greenwoodde@ORNL.GOV H Oak Ridge National Lab        %STD-W-DISCLAIMER, I only speak for myself   ------------------------------  # Date: Wed, 21 Jun 2000 01:29:53 GMT 2 From: "Zane H. Healy" <healyzh@shell1.aracnet.com>) Subject: Re: Besides Pathworks for Mac... 5 Message-ID: <lUU35.197$6C1.48936@typhoon.aracnet.com>   , Richard D. Piccard <piccard@ohio.edu> wrote:  B > There is a Mac Product called "Dave" that allegedly provides SMBJ > filesharing access to NT (and presumably PathWorks) servers.  I think itH > may also know how to provide access to W98/NT-shared printers.  I have > never used it. )   > 						RDPa  I "Dave" does not appear to be compatible with Samba on OpenVMS, at least IaH was unable to get it to work.  I forget what the problem was, but it wasJ something to do with the way "Dave" expects to be able to create files.  I+ do not know if it will work with PathWorks.t   			Zanen   ------------------------------  % Date: Tue, 20 Jun 2000 21:36:43 -0400 * From: Chuck McCrobie <mccrobi@apl.jhu.edu>. Subject: Re: Compaq C v6.2 Single User License+ Message-ID: <39501C2B.403EF6FE@apl.jhu.edu>n   Todd Nelson wrote: > N > I am in need of a single user license (part number QL-015AA-2B) for Compaq C > version 6.2 OpenVms Alpha. > E > I was quoted a price of around $1000.00 from compaq services... wasnM > wondering if anyone had this license floating around that wanted to sell ite > cheap. >  > Thanks >  > Todd.M  F Isn't the personal use license registered to you, not the machine.  AsG such, I _think_ you can use it on any machine, but only one at a time. bC Check out the license policies...  $1000?  We I checked into such a ) license a few years back, it was $1200...    ------------------------------  % Date: Wed, 21 Jun 2000 01:37:17 -0400r- From: JF Mezei <jfmezei.spamnot@videotron.ca>e+ Subject: Compaq paying for software ports ?), Message-ID: <39505486.98E80519@videotron.ca>  E Tandem used to take equity stakes in companies that provided software H considered to be strategic for the platform. I beleive that stopped whenL Compaq took over Tandem (I know of two companies that were sold coincidental with Compaq buying Tandem).p  H Digital also used to have special deal with companies to write strategicM software (I beleive that the IBM-SNA interconnect products were actually donet5 by an independant company, and "sponsored" by Compaq.f  L Couldn't Compaq actively get involved in the porting/writing of software forN VMS ? Or would that be politically impossible ? The ASAP (or whatever the nameK is) helps developpers, but it doesn't garantee that certain products judgedf strategic get ported.   L Just wondering what sort of real efforts a company such as Compaq can/should be taking ?o  N I've heard rumours of Compaq getting Oracle to make some sort of commitment toH VMS, but in all of the public announcements I have seen, Compaq+Oracle = True64 only.   ------------------------------   Date: 20 Jun 2000 18:16:44 GMT2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman). Subject: Re: Fast ethernet on micro-vax series5 Message-ID: <8iocec$4e$1@mailint03.im.hou.compaq.com>o  T In article <0056890011596397000002L972*@MHS>, reindert.voorhorst@philips.com writes:I :Is there anyone who knows of or has experience with a fast ethernet ada= 1 :pter on the micro-vax 3100-80 to 3100-96 series?o  G   The MicroVAX 3100 series was not particularly intended to be extendedeH   (eg: to have random I/O options added) -- it is (largely) a "busless" 
   system box.o  F :The only type we know is probably offered by nemonixinc, though at a ; :somewhat less affordable price. Are there other solutions?u  F   Use a 10-100 bridge/switch?  (This is not what you want to hear, of 
   course.)  N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Wed, 21 Jun 2000 02:57:28 GMT $ From: Ed Wilts <ewilts@mediaone.net>. Subject: Re: Fast ethernet on micro-vax series, Message-ID: <39502F18.C5D65DB7@mediaone.net>   Hoff Hoffman wrote:t > V > In article <0056890011596397000002L972*@MHS>, reindert.voorhorst@philips.com writes:K > :Is there anyone who knows of or has experience with a fast ethernet ada=v3 > :pter on the micro-vax 3100-80 to 3100-96 series?J > I >   The MicroVAX 3100 series was not particularly intended to be extended I >   (eg: to have random I/O options added) -- it is (largely) a "busless"  >   system box.- > G > :The only type we know is probably offered by nemonixinc, though at ae= > :somewhat less affordable price. Are there other solutions?-  F I had the same problem with a VAXstation 4000-90.  I ended up buying aG new Alpha DS10 for less than what Nemonix wanted for a 100Mbps EthernetH> adapter.  Needless to say, the DS10 is a wee bit faster too...     -- e Ed Wilts Mounds View, MN, USA mailto:ewilts@mediaone.net   ------------------------------  # Date: Tue, 20 Jun 2000 18:22:04 GMTn# From: alphaman@hsv.sungardtrust.comr Subject: re: Fun VMS Facts?)) Message-ID: <8iocnp$kq8$1@nnrp1.deja.com>d  7 In article <009EBA48.C3BCB401.24@maxwell.ph.kcl.ac.uk>, 2   Nigel Arnot <sysmgr@maxwell.ph.kcl.ac.uk> wrote:F > Not really a VMS fact. but I've heard that microVAX-II chips had the RussiantF > for "Digital VAX - for those who know to steal the very best" etched inF > the silicon! (This was of course when exporting them to the USSR wasC > strictly illegal, and the communist bloc's best(?) computers werex > cloned VAX 11/780s)   7 Actually, it was a CVAX (uV 3000 & 6200's) and it said:04  "VAX - when you care enough to steal the very best"   See for yourself:n  8  http://microscopy.fsu.edu/creatures/pages/russians.html  / You can find more fun stuff at the Silicon Zoo:   %  http://microscopy.fsu.edu/creatures/   $ Like the following pic of a 21064...  8  http://microscopy.fsu.edu/creatures/pages/lastcall.html     Aaron     & Sent via Deja.com http://www.deja.com/ Before you buy.a   ------------------------------  % Date: Wed, 21 Jun 2000 00:08:57 -0500e) From: "John E. Malmberg" <wb8tyw@qsl.net>i Subject: Re: Fun VMS Facts?n7 Message-ID: <111301bfdb3e$cfa9a4c0$020a0a0a@xile.realm>n  0 Aaron <alphaman@hsv.sungardtrust.company> wrote: > 1 > You can find more fun stuff at the Silicon Zoo:r > ' >  http://microscopy.fsu.edu/creatures/  >-   And one more VMS picture:-  4 http://microscopy.fsu.edu/creatures/pages/dream.html   ------------------------------  # Date: Tue, 20 Jun 2000 22:10:11 GMT)0 From: Timothy Stark <sword7@grace.speakeasy.org>' Subject: Looking for VAX ARM right now.09 Message-ID: <7ZR35.195923$701.2559687@news4.giganews.com>m   Hello Folks:  C Thank you for information about instruction sets.  I found complete0E instructions set from Macro-11 manual (at www.openvms.compaq.com).  I I recently am starting to develop my VAX emulator under my PDP-10 emulator. E I read some pages and noticed that I was asked to look at VAX ARM forwF more information like page tables, models, etc...  That's why I do not: know how to implement console routines without ARM manual.  
 Thank you!   -- Tim Stark   --  C Timothy Stark	<><	Inet: sword7@speakeasy.org, sword7@firesword7.net J --------------------------------------------------------------------------F "For God so loved the world, that he gave his only begotten Son, that H whosoever believeth in him should not perish, but have everlasting life.. Amen." -- John 3:16 (King James Version Bible)   ------------------------------  % Date: Tue, 20 Jun 2000 14:17:19 -0400e- From: "Peter Weaver" <peter.weaver@stelco.ca>o- Subject: Re: Mitnick (was Re: Fun VMS Facts?) / Message-ID: <skvda75be7f153@corp.supernews.com>c   John Nebel wrote in message ...n >r >..sF >I'll call a local congresscritter and request a transcript copy if no! >one else has easy access to one.u > ; >The source document in this case would make the story moreu convincing.s >u    F The source would be a good thing to have. If anyone out there does getA a copy from their "local congresscritter" then let me know, it iso$ kinda hard for us Canadians to do :)    % Terry C. Shannon wrote in message ...- > ...nA > Kevie-boy must have broken into a VMS system. After all, he did 	 manage tohC > abscond with the VMS source code after penetrating DEC's EASYNET.. > ...C  F I agree, he must have gotten into a VMS system or two somewhere, but I> don't care if he did. IMHO Mitnick was not a hacker and only aE want-to-be cracker, he was (and may be still) a great social engineer D and no operating system is going to stop a good social engineer. TheF important thing is that the PHB and public in general view him as "theB world's most notorious hacker." And if "the world's most notoriousE hacker" told the US Congress that he VMS was the only system he couldi? not break into then I want to see that in a full page ad in the,E Toronto Globe and Mail, the Wall Street Journal and every other placea the PHB will see it.   -- Peter Weaver   ------------------------------  + Date: Tue, 20 Jun 2000 14:30:03 -0600 (MDT)-) From: John Nebel <nebel@athena.csdco.com>-- Subject: Re: Mitnick (was Re: Fun VMS Facts?)dG Message-ID: <Pine.OSF.4.21.0006201424120.30553-100000@athena.csdco.com>n   Peter,  D I called the Office of the Chairman of the Senate Government Affairs@ Committee (Fred Thompson) and they promised to e-mail a hearing  transcript.)  D If it actually arrives, I'll put it up on an ftp server and post the relevant bit here.  E Interestingly enough, the aid answering the phone knew about Mitnick.    John  ( On Tue, 20 Jun 2000, Peter Weaver wrote:  ! > John Nebel wrote in message ...h > >p > >..rH > >I'll call a local congresscritter and request a transcript copy if no# > >one else has easy access to one.n > > = > >The source document in this case would make the story more 
 > convincing.k > >  >  > H > The source would be a good thing to have. If anyone out there does getC > a copy from their "local congresscritter" then let me know, it ise& > kinda hard for us Canadians to do :) >  > ' > Terry C. Shannon wrote in message ...s > > ... C > > Kevie-boy must have broken into a VMS system. After all, he did  > manage todE > > abscond with the VMS source code after penetrating DEC's EASYNET.m > > ...u > H > I agree, he must have gotten into a VMS system or two somewhere, but I@ > don't care if he did. IMHO Mitnick was not a hacker and only aG > want-to-be cracker, he was (and may be still) a great social engineeraF > and no operating system is going to stop a good social engineer. TheH > important thing is that the PHB and public in general view him as "theD > world's most notorious hacker." And if "the world's most notoriousG > hacker" told the US Congress that he VMS was the only system he couldbA > not break into then I want to see that in a full page ad in theyG > Toronto Globe and Mail, the Wall Street Journal and every other placea > the PHB will see it. >  > -- > Peter Weaver >  >  >  >    ------------------------------  % Date: Tue, 20 Jun 2000 22:52:11 +0100 5 From: "Adrian Lumsden" <A.Lumsden@spamtrap.xdt.co.uk>R- Subject: Re: Mitnick (was Re: Fun VMS Facts?) / Message-ID: <8iosjo$ktc$1@newsg3.svr.pol.co.uk>   8 Cyberpunk: Outlaws and Hackers on the Computer Frontier. Katie Hafner and John Markoff.$ ISBN 0-552-13963-7, Corgi Books 1993  8 If the book is to be believed and isn't all journalistic8 exaggeration, then Mitnick did get deeply inside Digital1 and VMS. He did (as Terry Shannon says) manage ton9 get away with some or all of the VMS sources (it claims).o  : There are some descriptions of things that he did with VMS= and the methods he used that don't ring quite true for peopled: who know VMS. He is supposed to have used the Chaos Club's< loginout hack on systems that he gained access to. It sounds; as though most of his initial access was obtained by sociale1 engineering and admins being sloppy with securityr> (damn. I MUST take down that sticky note from my terminal :-))   regards,   Adrian --( Adrian Lumsden, XDT Computer Systems, UK" A dot Lumsden at xdt dot co dot uk  1 <Steve.Spires@yellowpages.co.uk> wrote in message ) news:00256904.004751BF.00@quegw01.btyp...p? > Contact:   Tel: 3063  -  VSSG, 1st Floor, Bridge Street Plazat >rH > I'm sorry I don't have the book any more, and my memory might be a bit fuzzy,G > but doesn't he talk about hacking VMS in the "Cyberpunk : Outlaws andt
 Hackers on > the Computer Frontier"  book?  >cC > I can't remember if he said he could or couldn't though. Sorry...p >e > Steve Spires > VMS System Manager > BT/Yellow Pagesi >u >f >s >I> > Tim Shoppa <shoppa@trailing-edge.com> on 19/06/2000 15:31:31 >t" > To:        Info-VAX@Mvb.Saic.Com- > cc:         (bcc: Steve Spires/YellowPages) F > From:      Tim Shoppa <shoppa@trailing-edge.com>, 19 June 2000, 3:31 p.m. >s > Re: Fun VMS Facts? >m >r >v >  > Peter Weaver wrote:i > >rE > > I took a look at http://www.kevinmitnick.com/sentest.html since IeG > > thought a printout of the actual statement posted on the wall woulde= > > look good. The closest thing I can find is Mitnik saying;v > >h > > ==========A > > I have 20 years experience circumventing information securityq > > measures, and canhB > > report that I have successfully compromised all systems that I > > targeted for! > > unauthorized access save one.  > > ========== > > H > > I could not find any place where he said what that one system was. IH > > could not find any mentioned of VMS, Digital or DEC in the document.E > > If anyone finds a quote where he says that the one system was VMS: then > > let us know. >tC > I'm sure he's broken into VMS systems - Kevin Mitnick is a master.F > of "human factors" weaknesses, and calling up the VMS system managerD > and saying that you're a user who has lost his password works just@ > as well there as it does anywhere else.  And 12+ years ago theE > "FIELD SERVICE" account and password tricks were in place in a hugen$ > fraction of the sites running VMS. >e > Tim. >  >  >o >e >d   ------------------------------  % Date: Tue, 20 Jun 2000 12:29:29 -0700 ! From: Shane.F.Smith@Healthnet.com(- Subject: Re: Mitnick (was Re: Fun VMS Facts?)sC Message-ID: <OF364DC2A6.630236AE-ON88256904.006B0657@HEALTHNET.COM>i  C Maybe there's a destinction being made here between breaking in and   socially engineering his way in?   Shaner          C "Terry C. Shannon" <shannon@world.std.com>@world.std.com (Mr Usenetc" Himself) on 06/20/2000 06:10:09 AM  < Please respond to "Terry C. Shannon" <shannon@world.std.com>  0 Sent by:  news@world.std.com (Mr Usenet Himself)     To:   Info-VAX@Mvb.Saic.Comc cc:   . Subject:  Re: Mitnick (was Re: Fun VMS Facts?)         > Peter Weaver wrote:r > > E > > I took a look at http://www.kevinmitnick.com/sentest.html since I G > > thought a printout of the actual statement posted on the wall would = > > look good. The closest thing I can find is Mitnik saying;  > >  > > ==========A > > I have 20 years experience circumventing information securitys > > measures, and canlB > > report that I have successfully compromised all systems that I > > targeted for! > > unauthorized access save one.o > > ========== > >eH > > I could not find any place where he said what that one system was. IH > > could not find any mentioned of VMS, Digital or DEC in the document.J > > If anyone finds a quote where he says that the one system was VMS then > > let us know. >)C > I'm sure he's broken into VMS systems - Kevin Mitnick is a mastertF > of "human factors" weaknesses, and calling up the VMS system managerD > and saying that you're a user who has lost his password works just@ > as well there as it does anywhere else.  And 12+ years ago theE > "FIELD SERVICE" account and password tricks were in place in a huge $ > fraction of the sites running VMS.  I Kevie-boy must have broken into a VMS system. After all, he did manage totA abscond with the VMS source code after penetrating DEC's EASYNET.f   ------------------------------  # Date: Tue, 20 Jun 2000 19:56:37 GMTi- From: "Richard D. Piccard" <piccard@ohio.edu>'* Subject: Re: Mitnick -- was Fun VMS Facts?( Message-ID: <394FCC6A.6A0F897F@ohio.edu>  $ alphaman@hsv.sungardtrust.com wrote: [snip]9 > Actually, it was a CVAX (uV 3000 & 6200's) and it said:D6 >  "VAX - when you care enough to steal the very best"  ( So the Kevin Mitnick "quote" would be...  5 	"VMS - when you care enough to steal the very best."e   :-)     < I doubt he said that.  His behavior would seem to imply it.    					RDP   -- aB ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------  # Date: Tue, 20 Jun 2000 23:56:27 GMT  From: "KBHR" <KBHR@nx57.com>0 Subject: Monitoring Tool for CIS app on Open VMS; Message-ID: <LwT35.1694$j92.213338@typhoon.mw.mediaone.net>i  J Has anyone tried to monitor a CIS app on an Open VMS?  Tool considerationsG are Compuware's EcoTOOLS, BMS's Patrol, and CAUnicenter's version.  Has 3 anyone used any of these tools to monitor Open VMS?c   Thanks   ------------------------------  % Date: Tue, 20 Jun 2000 21:54:05 -0400-+ From: "Main, Kerry" <Kerry.Main@compaq.com>N7 Subject: RE: OpenVMS clusters vs other systems clusters J Message-ID: <910612C07BCAD1119AF40000F86AF0D805284436@kaoexc4.kao.dec.com>   JF,u  K While Tru64 now has some of the capabilities that is in OpenVMS clustering,y) the OpenVMS world is not standing still. a  I This is the same argument that folks have said about other OS's (like NT)uK that will "soon" have the same features as OpenVMS. When they catch up in asK few years to where OpenVMS is today, they find that OpenVMS has moved on ups a number of notches already.  K So, if you are a mission critical Customer that needs high availability, do-I you implement a departmental OS today because in a few years, you feel itpL will have the same features as your current OS? Or, do you realize that whenL the dept OS reachs where you are today, the current mission critical OS will be 2 or 3 levels higher again?  J It is a constantly sliding upward scale. As each new release of a OS comesD out, it is usually better, more improved than the last. W2K has moreD improved features and is more stable than NT4. Absolutely. For thoseC Customers that have implemented NT solutions, this is a good thing.I  I However, OpenVMS V7.2-1 is also more improved, and has more features thanaJ OpenVMS V7.1. OpenVMS V7.3 will raise the RASS (reliability, availability,( scalability, security) bar even higher.   H With respect to Tru64 now having some of the OpenVMS cluster features, IK view this as a strength of having multiple OS offerings. Tru64 gets some ofeL the good stuff from OpenVMS. OpenVMS gets some of the good stuff from Tru64.= Same goes with respect to sharing with the Tandem NSK folks. q  F I would be surprised if the IBM folks did not look at this in the sameF manner. Sharing of technologies between multiple OS's is a good thing.  K For those vendors that offer only one OS, enhancements, ideas and new stuffl( is usually coming from the same sources.  H >>> I do not know if that is really true or not. If it is true, it meansK that any vendor can develop clustering technology that rivals VMS in a veryv short time.<<<  E Not. No matter how one slices it, clustering is really tough stuff to J design, implement and support - especially if you plan to put into mission critical environments. n   Regards,  
 Kerry Main Senior Consultant,
 Compaq Canadao Professional Services  Voice : 613-592-4660 FAX   : 819-772-7036 Email : kerry.main@compaq.comr       -----Original Message-----4 From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]& Sent: Saturday, June 17, 2000 10:09 PM To: Info-VAX@Mvb.Saic.Comt7 Subject: Re: OpenVMS clusters vs other systems clusters-     Larry Kilgallen wrote:C > I doubt that you will find Compaq funding such a study for publicnD > release.  The only "good" result possible from a Compaq standpointC > is one that measured Tru64 and VMS as absolutely identical, sinced9 > otherwise one departement or another would be offended.   D The Montreal Compaq office has said a few times that Tru64's currentJ clustering capabilities now include ALL the functionality that was present in) openVMS (past tense is theirs, not mine).r  I I do not know if that is really true or not. If it is true, it means thatt any0H vendor can develop clustering technology that rivals VMS in a very short time.e   ------------------------------  % Date: Wed, 21 Jun 2000 00:48:33 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>y7 Subject: Re: OpenVMS clusters vs other systems clusterse, Message-ID: <3950491D.24E49D03@videotron.ca>   "Main, Kerry" wrote:K >> With respect to Tru64 now having some of the OpenVMS cluster features, IhM > view this as a strength of having multiple OS offerings. Tru64 gets some ofdN > the good stuff from OpenVMS. OpenVMS gets some of the good stuff from Tru64.> > Same goes with respect to sharing with the Tandem NSK folks.  M But is the local DEC/Compaq office correct when it states that the new True64.K clustering software brings to Unix all of the VMS clustering capabilities ?d  N If not, what are the features that VMS has and that True64 doesn't in terms of clustering ?  M The problem with this is that if the missing features in True64 are needed byhH only a small percentage of cuslters who require a cluster, it means thatJ True64 will fit the bill for the vast majority of those needing a cluster,% further narrowing VMS's niche market.    ------------------------------  % Date: Wed, 21 Jun 2000 01:01:26 -0400u' From: "Bill Todd" <billtodd@foo.mv.com>d7 Subject: Re: OpenVMS clusters vs other systems clustersy( Message-ID: <8ipi70$r5c$1@pyrite.mv.net>  4 Main, Kerry <Kerry.Main@compaq.com> wrote in messageD news:910612C07BCAD1119AF40000F86AF0D805284436@kaoexc4.kao.dec.com... > JF,t >sA > While Tru64 now has some of the capabilities that is in OpenVMSu clustering,s* > the OpenVMS world is not standing still. >DK > This is the same argument that folks have said about other OS's (like NT)-K > that will "soon" have the same features as OpenVMS. When they catch up inw alJ > few years to where OpenVMS is today, they find that OpenVMS has moved on up > a number of notches already.  F As usual, you're putting as good a face on things as is possible.  ButJ another way of looking at the situation is that even with its current leadD VMS isn't setting the world on fire (in terms of market penetration)K compared to its competition, and since the competition appears to be movingMF a good deal faster than VMS is this situation seems likely only to get worse.  I Some of the blame can be placed on Compaq's (and DEC's before it) abysmal K (non-)marketing, so improvements in that area should temporarily give VMS amF bounce or at least halt its downward slide (yes, its numbers have beenG relatively constant over time, but in a growing market that constitutesmJ losing ground).  But over anything but the short run, VMS is going to haveD to develop functionally at the same rate as its competition to avoid returning to decline.l   > J > So, if you are a mission critical Customer that needs high availability, doK > you implement a departmental OS today because in a few years, you feel it-I > will have the same features as your current OS? Or, do you realize that  whenI > the dept OS reachs where you are today, the current mission critical OSn will  > be 2 or 3 levels higher again?  K VMS has no lock on high availability any more - well, it never did, but now-L its competition includes 'standard' Unix and even Windows environments.  TheJ eagerness with which customers are accepting such solutions makes it clearL that VMS's advantages, real though they may be, are not decisive compared toG other considerations (in other words, the competition offers *adequate*p6 availability plus many attractions that VMS does not).  D Compaq can certainly derive some incremental revenue and profit fromJ allowing VMS out of the closet.  But it won't get anything like the marketJ penetration it *could* get without a good deal of development work as well5 (IMO a good deal *more* than its road maps indicate).n   - bill   >gL > It is a constantly sliding upward scale. As each new release of a OS comesF > out, it is usually better, more improved than the last. W2K has moreF > improved features and is more stable than NT4. Absolutely. For thoseE > Customers that have implemented NT solutions, this is a good thing.h >eK > However, OpenVMS V7.2-1 is also more improved, and has more features thangL > OpenVMS V7.1. OpenVMS V7.3 will raise the RASS (reliability, availability,) > scalability, security) bar even higher.i >eJ > With respect to Tru64 now having some of the OpenVMS cluster features, IJ > view this as a strength of having multiple OS offerings. Tru64 gets some ofG > the good stuff from OpenVMS. OpenVMS gets some of the good stuff from  Tru64.> > Same goes with respect to sharing with the Tandem NSK folks. > H > I would be surprised if the IBM folks did not look at this in the sameH > manner. Sharing of technologies between multiple OS's is a good thing. >cG > For those vendors that offer only one OS, enhancements, ideas and newP stuff.* > is usually coming from the same sources. >mJ > >>> I do not know if that is really true or not. If it is true, it meansH > that any vendor can develop clustering technology that rivals VMS in a very > short time.<<< >uG > Not. No matter how one slices it, clustering is really tough stuff tohL > design, implement and support - especially if you plan to put into mission > critical environments. >0
 > Regards, >  > Kerry Main > Senior Consultant, > Compaq Canada  > Professional Servicesl > Voice : 613-592-4660 > FAX   : 819-772-7036 > Email : kerry.main@compaq.com  >o >n >  > -----Original Message-----6 > From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]( > Sent: Saturday, June 17, 2000 10:09 PM > To: Info-VAX@Mvb.Saic.Comh9 > Subject: Re: OpenVMS clusters vs other systems clustersh >l >m > Larry Kilgallen wrote:E > > I doubt that you will find Compaq funding such a study for publicgF > > release.  The only "good" result possible from a Compaq standpointE > > is one that measured Tru64 and VMS as absolutely identical, sincer; > > otherwise one departement or another would be offended.t >vF > The Montreal Compaq office has said a few times that Tru64's currentL > clustering capabilities now include ALL the functionality that was present > in+ > openVMS (past tense is theirs, not mine).o >aK > I do not know if that is really true or not. If it is true, it means thats > anyhJ > vendor can develop clustering technology that rivals VMS in a very short > time.f >h   ------------------------------  % Date: Tue, 20 Jun 2000 22:49:08 -0400e+ From: "Main, Kerry" <Kerry.Main@compaq.com> J Subject: RE: OpenVMS commentaries (was Re: Gartner commentary on Wildfire)J Message-ID: <910612C07BCAD1119AF40000F86AF0D805284439@kaoexc4.kao.dec.com>   Bill,   J >>> As I said, concurrent disk-sharing per se is markedly superior only inD addressing relatively rare scaling issues that resist efficient data partitioning.>>>  L Would you not say that data partitioning is extremely tough to do unless youI have very experienced DBA's or application resources that understand whataJ the production loads are going to be ie. the marketing folks were accurate( in their forcast of the expected loads ?  K What happens when the loads increase dramatically above what was expected ?aK Does the database / application not have to be re-partitioned to re-balancesL the load?  Does this not mean the application and database are offline untilK such time as all of this repartitioning has taken place ? Of course, before K you can re-partition the data, backups need to be done, so that adds to thee outage.c  J In a 24x7 shop, is database / application re-partitioning not a really big; thing that IT shops want to avoid at all costs if they can?.   Regards,  
 Kerry Main Senior Consultant,
 Compaq Canadae Professional Servicesd Voice : 613-592-4660 FAX   : 819-772-7036 Email : kerry.main@compaq.com        -----Original Message-----, From: Bill Todd [mailto:billtodd@foo.mv.com]# Sent: Friday, June 16, 2000 1:24 PM0 To: Info-VAX@Mvb.Saic.Comd@ Subject: Re: OpenVMS commentaries (was Re: Gartner commentary on	 Wildfire)r    H Since a shared-disk (or even virtual-shared-disk) architecture is whollyG unnecessary to achieve the clustering goals (reliability, availability, L redundancy) you have described below, the entire basis for your disagreementG disappears.  I suspect you may not understand the distinction between a H shared-disk architecture and non-shared-disk architectures that use fastL file system fail-over (which can complete nearly as quickly as a VMS cluster+ state transition) to achieve the same ends.   F As I said, concurrent disk-sharing per se is markedly superior only inD addressing relatively rare scaling issues that resist efficient dataE partitioning.  It can also offer *marginally* better performance thantI alternatives, though the potential performance advantage increases if theME alternatives don't support a distributed caching mechanism (which therE shared-disk approach virtually requires, but alternatives don't; samea0 comment applies to distributed lock management).   - bill  0 jlsue <jlsuexxxz@dialupnet.com> wrote in message2 news:61fkkskd35tl01hio6t8be0thb8r25k9qb@4ax.com...F > On Tue, 6 Jun 2000 20:47:01 -0400, "Bill Todd" <billtodd@foo.mv.com> > wrote: >t > > 8 > >Rob Young <young_r@eisner.decus.org> wrote in message( > >news:hDa+dY7YNfQk@eisner.decus.org... >  > >>E > >> Linux is great and Linux is fast, yada yada.   But Linux doesn'taC > >> have 4 or 5 nodes in a shared disk cluster.  Shared disk?  Whot > >> needs shared disk.... > >'G > >Good question:  most installations don't, at all.  While shared-disksF > >configurations are the *only* way to address some (extreme) scaling8 > >situations well, those situations aren't that common. >eC > Now, see, this I completely disagree with - or, at least a little-F > anyway.  In my experience, I've found it very common that businessesG > expect some redundancy in their applications.  Most I deal with can't-D > afford to be down for hours - or even minutes - while problems areE > fixed.  These situations are all that extreme... it's just that they? > shared clustering concept makes it easier to add more compute</ > resources with little impact on availability.  >s > >Lacking such a0I > >scaling problem, if you can successfully partition your data such that  it'sJ > >usually local to the node that needs it (the common case, especially inG > >read-mostly web-server environments), your performance will often bee betterK > >than in a shared-disk cluster where you *haven't* paid attention to such J > >partitioning, because in the latter case the nodes will be caching dataG > >redundantly (using up memory they could be using more effectively in  other K > >ways) and fighting each other over the occasional need to update it (ands XFC B > >won't eliminate these problems, though it may ameliorate them). > E > Again, my perspective, as a system administrator, was that I'd much G > prefer *not* configuring a critical system such that my arse would betG > in a sling every time some errant software or hardware action decidedE
 > to show up.n > ? > Scaling is only one of the business problems solved by shared H > clusters.  Redundancy is another.  Yes, having the same data in cachesH > on seperate nodes is redundant, but it also improves availability.  ToH > me, this is a *good* thing, I try to push for this whenever I have theE > chance - and I can easily couch my arguments in completely business+F > terms to justify that position.  It's not just a techie thing to me. > A > There are trade-offs in everything, though, and this redundancyh@ > doesn't come for free.  To me it is a business decision, not aE > technical one.  But in my experience, time and time again, managers-G > make the decision *not* to buy into redundancy.  Unless they see realcE > dangers to the business, they won't be interested.  However, in allMD > cases where their jobs depend on the systems being available, they! > *always* go for the redundancy.u >yG > There will be some computing models under which the trade-offs should D > not be accepted, and some scientific computing environments can beH > included there.  On the other hand, I have implemented shared clustersE > for centralized computational resources at some companies, and theyRF > value the performance and reliability aspects of that configuration. >= > 3 > Not speaking for anyone, certainly not DEC/Compaqo/ > (get rid of the xxxx in my address to e-mail)    ------------------------------  % Date: Wed, 21 Jun 2000 01:54:09 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>-J Subject: Re: OpenVMS commentaries (was Re: Gartner commentary on Wildfire)( Message-ID: <8ipl9p$s0o$1@pyrite.mv.net>  4 Main, Kerry <Kerry.Main@compaq.com> wrote in messageD news:910612C07BCAD1119AF40000F86AF0D805284439@kaoexc4.kao.dec.com... > Bill,  >oL > >>> As I said, concurrent disk-sharing per se is markedly superior only inF > addressing relatively rare scaling issues that resist efficient data > partitioning.>>> >-J > Would you not say that data partitioning is extremely tough to do unless yourK > have very experienced DBA's or application resources that understand what L > the production loads are going to be ie. the marketing folks were accurate* > in their forcast of the expected loads ?   I would say "It depends."   J First, if you're talking databases, only Oracle Parallel Server and DB2 onB IBM's Parallel Sysplex even give you the *option* of avoiding dataJ partitioning to accommodate (or plan for) loads exceeding the capabilitiesB of a single database (SMP) node - and even they still benefit fromJ partitioning.  So the range of situations in which, say, OPS allows you toL avoid data partitioning when non-shared-disk approaches would not is limitedI to those where the database load exceeds that supportable by a single SMPnE node but does not exceed that at which the unpartitioned cluster lockdH management overhead becomes excessive (and you really ought to partitionJ OPS's data to reduce it).  Given the extremely respectable capabilities ofG single SMP nodes these days, the narrowness of that range of situationsmC justifies the characterization of 'relatively rare', in my opinion.u  K Second, much data is trivially partitionable, whether in a database or in aOI file system (where randomly distributing users and other entities such as7E development groups across partitions is a good start).  And databasesbJ provide utilities that can ease the process even for newbies (and identifyC bad choices if they make them).  So it's often standard practice to J pre-partition easily-partitioned data even in single-node environments, toI make it easy to spread it out (without having to shuffle it:  just changer6 the ownership of its storage) if the need ever arises.   >hK > What happens when the loads increase dramatically above what was expected  ?w  D In the case of a file system (where presumably little automated helpK exists), you assign new users to storage on new nodes that you add, or moveo> some existing users' data to new nodes that you add (if you'veE pre-partitioned as described above, just move some storage to the newhJ nodes).  My guess would be that typical increases in file systems are moreL gradual than the dramatic fluctuations things like Internet server databases2 can see, so such mechanisms may be quite adequate.  B > Does the database / application not have to be re-partitioned to
 re-balance > the load?   I Yes, and at least some databases largely automate this process.  DB2, for I example, allows one to break up relations based on key ranges or based ondL hash functions that distribute the relation across a specified set of nodes,A and my vague recollection is that other platforms provide similarrL facilities.  In the case of hashed distribution, I think I remember that DB2F uses a fixed number (4096) of hash targets, which are then distributedK across the specified set of nodes:  this makes it easy to move some of themdH to new nodes to relieve hot spots or help spread out generally-increased	 activity.f  C   Does this not mean the application and database are offline until ; > such time as all of this repartitioning has taken place ?M  G I happen to remember that DB2 can do it on line (e.g., redistribute viaeF hashing over a larger set of nodes), but don't know for sure for other
 platforms.    Of course, beforeI > you can re-partition the data, backups need to be done, so that adds to  the0	 > outage.0  D I think you're 'way out of date in your thinking:  modern relational4 databases allow most restructuring to occur on line.   >.L > In a 24x7 shop, is database / application re-partitioning not a really big= > thing that IT shops want to avoid at all costs if they can?a  B If that were true, they'd use nothing but OPS (which still doesn'tK completely avoid the problem, but does allow more leeway in addressing it).aJ Since OPS represents a small percentage of Oracle installations, let aloneG total database installations, I'd say your perception of the problem isi greatly exaggerated.   - bill   > 
 > Regards, >c > Kerry Main > Senior Consultant, > Compaq CanadaV > Professional Servicese > Voice : 613-592-4660 > FAX   : 819-772-7036 > Email : kerry.main@compaq.coma   ------------------------------  % Date: Tue, 20 Jun 2000 14:04:30 -0400u5 From: "Sue Skonetski" <susan.skonetski@compaq.nospam>f& Subject: Re: OpenVMS Customer Database5 Message-ID: <8ioblr$4k$1@mailint03.im.hou.compaq.com>-   Brian,  9 Please give me a call.  I think you have my phone number.r   Suel  3 ___________________________________________________u  . Brian Schenkenberger, VAXman- wrote in message' <009EBE46.1874C658@SendSpamHere.ORG>...KG >In article <8ioa7i$str$1@mailint03.im.hou.compaq.com>, "Sue Skonetski"F' <susan.skonetski@compaq.nospam> writes:tJ >>Based on the response from this newsgroup regarding the VMS poster a fewF >>months ago.  The Compaq OpenVMS Group is in the process of gathering+ >>customer names for our customer database.h >O0 >What was this poster?  Ne'er did agit me one... >u >--s3 >VAXman- OpenVMS APE certification number: AAA-0001w VAXman(at)TMESIS(dot)COM   ------------------------------   Date: 20 Jun 2000 19:29:48 GMT* From: helbig@astro.rug.nl (Phillip Helbig)& Subject: Re: OpenVMS Customer Database. Message-ID: <8iognc$api$1@info.service.rug.nl>  F In article <8ioa7i$str$1@mailint03.im.hou.compaq.com>, "Sue Skonetski"( <susan.skonetski@compaq.nospam> writes:   I >Based on the response from this newsgroup regarding the VMS poster a fewME >months ago.  The Compaq OpenVMS Group is in the process of gatheringm* >customer names for our customer database. >tJ >Once folks are added to the database they receive a hardcopy package on aJ >regular basis.  This package will contain a letter from Richard Marcello,E >our Vice President and either brochures/collateral, posters,  and ono >occasion a small gift.) >BE >If you would like to be included in this database please send me then >following information.e  ? I got something today (dated May 22, but it had to come to the fI Netherlands) which sounds like this: a letter and "Compaq OpenVMS on the oI New AlphaServer GS Series".  It would be nice if you could send an email  I to all folks on the list, to avoid people signing up twice etc.  Thus, I h think I'm on, but I'm not sure.u  H Great brochure.  Just what is needed.  I think it is a good idea to ask H folks who are not yet converted to VMS if you can put their name on the F list.  The brochure is informative, correct but also good marketing.   Just what we need.     --M Phillip Helbig                       Email .............. helbig@astro.rug.nlsM Kapteyn Instituut                    Email ................. helbig@man.ac.ukdM Rijksuniversiteit Groningen          Tel. ................... +31 50 363 6647 M Postbus 800                          Fax .................... +31 50 363 6100eM NL-9700 AV Groningen                 Web ... http://www.astro.rug.nl/~helbig/   5 My opinions are not necessarily those of my employer.o  N <A HREF=" http://gladia.astro.rug.nl:8000/helbig/hire/hire.html ">HIRE ME!</A>   ------------------------------  % Date: Tue, 20 Jun 2000 20:40:08 -0500.7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>b& Subject: Re: OpenVMS Customer Database- Message-ID: <39501CF8.B79E5257@earthlink.net>e   Sue Skonetski wrote: >  > Brian, > ; > Please give me a call.  I think you have my phone number.h >    Sue,  B Please contact a former employer of mine: Metromail Corporation in@ Lombard, IL. Not only are they the home of the National ConsumerC Database, but they are one of the biggest suppliers of lists in ther direct marketing industry.  F I think we need more than "preaching to the choir", we need to get the word out "into the streets".   -- o David J. Dachteras dba DJE Systems." http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/i   ------------------------------  % Date: Tue, 13 Jun 2000 22:04:45 -0500n+ From: "Randy Jung" <rpjung@mb.sympatico.ca>.. Subject: OpenVMS UCX/FTP and Internet Explorer1 Message-ID: <g9W35.14357$Pz6.99975@news1.mts.net>y   Hi,   I My site was looking for an easy way of transferring files to and from our.H VMS systems and we hit upon the idea of using the FTP option in InternetI Explorer. This works for linux, NT and just about everything else. If youoI try it for VMS, say putting FTP://vmsnode.com in the address bar it comes L back with a graphical representation of the directory but the file names areK just garbage. I've tracked this down to the fact that Inernet Explorer uses J the information from the output of the FTP directory command to create theJ graphical representation and makes assumptions on which columns are files,J file sizes and so on. I've tried it with UCX 4.2 and 5.0a and no luck. HasJ anyone been able to get it to work? Any way of forcing VMS to generate theF results of the FTP directory command in a UNIX format instead of a VMSH format? It works for Netscape which I assume is using the ls command (noI file information in that command). Any ideas or help that can get this tot work appreciated.a   Cheers,b   Randyi   ------------------------------  % Date: Tue, 20 Jun 2000 16:52:35 -0400d) From: Bob Ricci <maxx0623@concentric.net>i Subject: print files< Message-ID: <038001bfdaf9$76939ac0$585b5cc0@socrates.Subway>  L Is there anyway to take a .rpt file from vms and print it as a pdf file fromK a pc. Our current .rpt file when sent to a pc wraps around and is difficulet to read. Robert V. Riccid Systems Manager  Drs. Associates (SUBWAY) 325 Bic Dr.o Milford, Ct 06460   tel  203 877 4281 ext 1144-  fax 203 876 6682u email ricci_r@subway.com  or     maxx0623@concentric.netp http://www.subway.comO   ------------------------------   Date: 21 Jun 2000 01:20:33 GMT/ From: morris@iridium.mv.net (Skipper W. Morris)a> Subject: Re: Proxy problem: Why does node:: work but 0:: fail?( Message-ID: <8ip591$qgh$1@pyrite.mv.net>  C If this problem occured on a Phase IV system it would be related to  the use of the cluster alias.o  D When you do a "directory node::..." command the session layer does aG lookup in the node database to translate the name to the address.  When D you do a command "directory nnn::..." this session control lookup is7 bypassed since you're already supplying the nodenumber.s  C A side effect of this is typing the name causes the local system totE send the cluster alias address of the source node.  Typing the number D causes the system to send the local node address and not the clusterB address should one exist. This side effect was deliberate to allow7 a user to control which address was sent as the source.n  F I haven't tried it in years so I'm not sure what the current behaviour is, but it's probably the same.   A So if you have clusters, the problem might be that you don't haveh> a proxy for the other possible nodename in the proxy database.  A Easiest thing is do a "set host 0" vs "set host foo" and when you-< login look at where the system thinks the connect came from.   /Skip    ------------------------------  % Date: Wed, 21 Jun 2000 10:08:37 +1200:. From: Nivlesh Chandra <NChandra001@itc.gov.fj> Subject: QUEUE ENTRY NUMBERS...rM Message-ID: <791C2856E8FDD211BAFB0008C759919591F971@exchange01.govnet.gov.fj>-   Hi guys and girls...I I have a problem on my hands which I hope someone will be able to help meyG with.. the entry numbers for the queues have increased to a really highrJ number.. the current one is 2007939 ... I tried to restart the que managerL in the hope that it will reinitialise the numbers but it did not do any such things   stop/que/mana/clustern< start/que/manager /on=(itcs01,itcs02,itcs03) disk28:[queues]    K the entry numbers are still as high as before... can someone please help mee* to get the numbers start from zero again??   Nivleshg   ------------------------------  % Date: Tue, 20 Jun 2000 22:28:58 -0400n# From: John Vottero <John@MVPSI.com>n# Subject: RE: QUEUE ENTRY NUMBERS...nD Message-ID: <C15945A9D9EFCF11BA8B08002BBF1CCC0CD728@berry.mvpsi.com>   You have to do a:(  " $ START/QUE/MANAGER/NEW_VERSION...  L BUT,  You will LOSE all jobs, queues, forms and characteristics. You have toH recreate everything.  Also, if you are using more than one queue managerK then you will have big queue entry numbers anyway, no matter what.  And, if2J you put more than 10,000 jobs in the queues at any one time, you will have" big (7 digit) queue entry numbers.   K The only reason to go through the pain of recreating your queue database is I if something strange happened which dumped more than 10,000 jobs into thenH queues and you want to recover from that so that you only have to type 4 digit entry numbers again.   > -----Original Message-----7 > From: Nivlesh Chandra [mailto:NChandra001@itc.gov.fj]*& > Sent: Tuesday, June 20, 2000 6:09 PM > To: Info-VAX@Mvb.Saic.Comu! > Subject: QUEUE ENTRY NUMBERS...o >  >  > Hi guys and girls...< > I have a problem on my hands which I hope someone will be  > able to help me > > with.. the entry numbers for the queues have increased to a 
 > really high = > number.. the current one is 2007939 ... I tried to restart e > the que managera? > in the hope that it will reinitialise the numbers but it did t > not do any suchc > thing  >  > stop/que/mana/clusterd> > start/que/manager /on=(itcs01,itcs02,itcs03) disk28:[queues] >  > ? > the entry numbers are still as high as before... can someone t > please help me, > to get the numbers start from zero again?? > 	 > Nivleshh >  >    ------------------------------   Date: 20 Jun 2000 18:32:40 GMT2 From: mathog@seqaxp.bio.caltech.edu (David Mathog)4 Subject: request for new linker error: "multinclude"+ Message-ID: <8iodc8$tq@gap.cco.caltech.edu>r  I Could the folks who maintain the LINKER please look into adding a warninguJ "MULTINCLUDE"?  It would be emitted whenever an object file is passed into the linker twice.  e  H Currently, if a large, complex LINK command accidentally happens to have> the same object file twice (usually as the result of a typo orK screwy substitution, but it happens) the error message is quite confusing. s  	 Example: r   $ create killme.cs #include <stdio.h> int main(void){o   (void) printf("Hi\n"); }  $ cc killme  $ link killme,killme, %LINK-W-MULDEF, symbol MAIN multiply defined@         in module KILLME file USRDISK:[USERS.MATHOG]KILLME.OBJ;1. %LINK-W-MULDEF, symbol __MAIN multiply defined@         in module KILLME file USRDISK:[USERS.MATHOG]KILLME.OBJ;11 %LINK-W-MULTFR, multiply defined transfer addresse@         in module KILLME file USRDISK:[USERS.MATHOG]KILLME.OBJ;1 $m  E Usually you get the MULDEF message when there really are two separatehG instances of a function in different modules.  Here what's really wrong D is that KILLME.OBJ went in twice, so of course, everything in it is E duplicated.  In this case it's easy to see what's wrong with the LINKcE command, but that isn't always the case, and one can go a little nutsoG trying to find the nonexistant function duplication in the source code,  as there isn't one!t   Thanks,b   David Mathog mathog@seqaxp.bio.caltech.eduu? Manager, sequence analysis facility, biology division, Caltech h   ------------------------------  % Date: Wed, 21 Jun 2000 17:06:52 +1200r/ From: "Jason Irons" <jason.irons@telecom.co.nz>a Subject: SLS and TL891 Robot6 Message-ID: <M3Y35.2556$lE26.16777371@news.xtra.co.nz>   Hello Everyone  H I am currently trying to setup Compaq SLS 2.9C to backup to a TL891 tape robot.  L Does anyone have successful SLS scripts for performing multiple backups to aJ TL891 robot that I could have a look at to gain an understanding on how to7 perform these operations (Saves re-inventing the wheel)o   Any help would be appreciated.   Jason Ironss   ------------------------------  + Date: Tue, 20 Jun 2000 14:44:03 -0600 (MDT) ) From: John Nebel <nebel@athena.csdco.com>nJ Subject: Re: Storage Works / Snapshots / Maybe it's (NOT) time to skip VMSG Message-ID: <Pine.OSF.4.21.0006201430560.30553-100000@athena.csdco.com>e   David,   This is from memory:  I According to a presentation on VMS v7.3 volume shadowing at DFW days, one>G will be able to break a disk out of a shadow set and there will be some K i/o synchronization so what is left and what is broken-out are identical.  eE Then a bit map will be maintained for the writes which the broken-outfH member missed so it can be reintroduced into the shadow set with minimum/ updating, given the granularity of the bit map.t  H Up to six such bit maps may be maintained (I believe that was per shadow set) for up to eight years.d  F The presumption was that one could add back in a different disk with aJ full copy, then break that out, and so on.  The thought was that one couldJ maintain a full working-week's (OK, ordinary 5-day working-week) snapshots as of a particular time of day.n   It seemed pretty darned nifty.  
 John Nebel      + On Tue, 20 Jun 2000 d.webb@mdx.ac.uk wrote:r   > In articleF > <05E9483E465FF40C.DBE5A72396AEDFFB.0693B6D86E224ECB@lp.airnews.net>,% >   kuff@tessco.com (Hal Kuff) wrote:e > >  > >yI > >    What we're looking for is a snapahot via command files or API thatyI > > allows us to only take users offline for 5 mins.... cloning a stripedfJ > > mirrorset would defeat the purpose....  Adding mirrors and taking themB > > away to convert them to units for mounting would be clumsy and
 > probably > > unscriptable >  >  > H > There was going to a product to do precisely this - snapshot services.( > Unfortunately it was cancelled on VMS. > It sounded so great. > E > Stop your applications for a second. Take a snapshot of your disks. % > Continue on. Backup your snapshots.sG > The snapshots used little disk space - you didn't need to have doubleiE > your disk capacity - because they just duplicated metadata and onlyh; > redirected blocks over time as those blocks were updated.a > G > If I recall correctly the software was produced for NT - then the VMSa > version got canned.s > I > We were promised that the functionality would be rolled into the futuree  > improvements in shadowing etc. > B > So anyone - Will the new file system work etc in VMS 7.3 include > snapshot services ?  >  >  > David Webb > VMS and Unix team leader > CCSS > Middlesex University > >eB > > In article <4.3.2.7.0.20000617144256.00bbb650@24.8.96.48>, Dan
 > Sugalski > > <dan@sidhe.org> wrote: > >t0 > > > At 04:30 PM 6/16/00 -0400, Hal Kuff wrote: > > >u > > >a> > > > >    IS there any kind of snapshot supported by OpenVMS?I > > > >    We'd sure like to buy about $200,000 worth of new Storage, but  > theoI > > > >ability to do snapshots from OpenVMS is not negotiable. This needs  > to beu9 > > > >scripted and run several times per day unattended.s > > >iI > > > What kind of snapshots? If you're just talking about cloning disks,e	 > you canaF > > > do that now and have been able to for ages. Either use the CLONE > support inD > > > the HSx controllers to snapshot individual drives or, for RAID
 > volumes andnI > > > such, make and break shadow sets. Rebuilds on the shadow sets are ae > bit of > > > a pain, but it works.  > > >t > > >l1 > > >                                         Dano > > > 6 > > > --------------------------------------"it's like > this"-------------------8 > > > Dan Sugalski                          even samuraiE > > > dan@sidhe.org                         have teddy bears and evenrA > > >                                       teddy bears get drunk  > >o >  > ( > Sent via Deja.com http://www.deja.com/ > Before you buy.e >  >    ------------------------------  % Date: Tue, 20 Jun 2000 22:21:32 -0700n! From: Koloth <koloth@tmisnet.com> J Subject: Re: Storage Works / Snapshots / Maybe it's (NOT) time to skip VMS+ Message-ID: <395050DC.ECDD14B1@tmisnet.com>y  0 Get a briefing on the new Storageworks products.  2 They have snapshots and cloning.  Very very nifty.  8 What Compaq is doing and planning on doing is fantastic.       John Nebel wrote:e   > David, >i > This is from memory: >nK > According to a presentation on VMS v7.3 volume shadowing at DFW days, oneaI > will be able to break a disk out of a shadow set and there will be some K > i/o synchronization so what is left and what is broken-out are identical.CG > Then a bit map will be maintained for the writes which the broken-out7J > member missed so it can be reintroduced into the shadow set with minimum1 > updating, given the granularity of the bit map.e >oJ > Up to six such bit maps may be maintained (I believe that was per shadow > set) for up to eight years.m >iH > The presumption was that one could add back in a different disk with aL > full copy, then break that out, and so on.  The thought was that one couldL > maintain a full working-week's (OK, ordinary 5-day working-week) snapshots! > as of a particular time of day.  >o  > It seemed pretty darned nifty. >> > John Nebel >F- > On Tue, 20 Jun 2000 d.webb@mdx.ac.uk wrote:a >  > > In articleH > > <05E9483E465FF40C.DBE5A72396AEDFFB.0693B6D86E224ECB@lp.airnews.net>,' > >   kuff@tessco.com (Hal Kuff) wrote:t > > >  > > >mK > > >    What we're looking for is a snapahot via command files or API thatgK > > > allows us to only take users offline for 5 mins.... cloning a striped L > > > mirrorset would defeat the purpose....  Adding mirrors and taking themD > > > away to convert them to units for mounting would be clumsy and > > probably > > > unscriptable > >D > >o > >pJ > > There was going to a product to do precisely this - snapshot services.* > > Unfortunately it was cancelled on VMS. > > It sounded so great. > >oG > > Stop your applications for a second. Take a snapshot of your disks.h' > > Continue on. Backup your snapshots.eI > > The snapshots used little disk space - you didn't need to have doublecG > > your disk capacity - because they just duplicated metadata and onlyr= > > redirected blocks over time as those blocks were updated.M > >lI > > If I recall correctly the software was produced for NT - then the VMS  > > version got canned.  > >IK > > We were promised that the functionality would be rolled into the futurei" > > improvements in shadowing etc. > > D > > So anyone - Will the new file system work etc in VMS 7.3 include > > snapshot services ?C > >  > >M > > David Webb > > VMS and Unix team leader > > CCSS > > Middlesex University > > >oD > > > In article <4.3.2.7.0.20000617144256.00bbb650@24.8.96.48>, Dan > > Sugalski > > > <dan@sidhe.org> wrote: > > >u2 > > > > At 04:30 PM 6/16/00 -0400, Hal Kuff wrote: > > > >  > > > > @ > > > > >    IS there any kind of snapshot supported by OpenVMS?K > > > > >    We'd sure like to buy about $200,000 worth of new Storage, buta > > the.K > > > > >ability to do snapshots from OpenVMS is not negotiable. This needst	 > > to be ; > > > > >scripted and run several times per day unattended.h > > > >.K > > > > What kind of snapshots? If you're just talking about cloning disks,3 > > you cantH > > > > do that now and have been able to for ages. Either use the CLONE > > support inF > > > > the HSx controllers to snapshot individual drives or, for RAID > > volumes andeK > > > > such, make and break shadow sets. Rebuilds on the shadow sets are a/
 > > bit of > > > > a pain, but it works.- > > > >- > > > >-3 > > > >                                         Danm > > > >J8 > > > > --------------------------------------"it's like > > this"-------------------: > > > > Dan Sugalski                          even samuraiG > > > > dan@sidhe.org                         have teddy bears and evenhC > > > >                                       teddy bears get drunk  > > >i > >p > >o* > > Sent via Deja.com http://www.deja.com/ > > Before you buy.s > >  > >a   ------------------------------  # Date: Tue, 20 Jun 2000 18:22:21 GMTr From: d.webb@mdx.ac.ukH Subject: Re: Storage Works / Snapshots / Maybe it's time to skip OpenVMS) Message-ID: <8iocob$kqg$1@nnrp1.deja.com>c  
 In articleD <05E9483E465FF40C.DBE5A72396AEDFFB.0693B6D86E224ECB@lp.airnews.net>,#   kuff@tessco.com (Hal Kuff) wrote:: >t >/G >    What we're looking for is a snapahot via command files or API that G > allows us to only take users offline for 5 mins.... cloning a stripedyH > mirrorset would defeat the purpose....  Adding mirrors and taking them@ > away to convert them to units for mounting would be clumsy and probably > unscriptable      F There was going to a product to do precisely this - snapshot services.& Unfortunately it was cancelled on VMS. It sounded so great.  C Stop your applications for a second. Take a snapshot of your disks. # Continue on. Backup your snapshots.iE The snapshots used little disk space - you didn't need to have double C your disk capacity - because they just duplicated metadata and only 9 redirected blocks over time as those blocks were updated.t  E If I recall correctly the software was produced for NT - then the VMSs version got canned.   G We were promised that the functionality would be rolled into the future0 improvements in shadowing etc.  @ So anyone - Will the new file system work etc in VMS 7.3 include snapshot services ?o    
 David Webb VMS and Unix team leader CCSS Middlesex University >p@ > In article <4.3.2.7.0.20000617144256.00bbb650@24.8.96.48>, Dan Sugalski > <dan@sidhe.org> wrote: >a. > > At 04:30 PM 6/16/00 -0400, Hal Kuff wrote: > >d > > < > > >    IS there any kind of snapshot supported by OpenVMS?G > > >    We'd sure like to buy about $200,000 worth of new Storage, butl theeG > > >ability to do snapshots from OpenVMS is not negotiable. This needsy to bet7 > > >scripted and run several times per day unattended.  > > G > > What kind of snapshots? If you're just talking about cloning disks,o you canoD > > do that now and have been able to for ages. Either use the CLONE
 support inB > > the HSx controllers to snapshot individual drives or, for RAID volumes andyG > > such, make and break shadow sets. Rebuilds on the shadow sets are a- bit of > > a pain, but it works.J > >0 > >2/ > >                                         Dan  > >s4 > > --------------------------------------"it's like this"-------------------6 > > Dan Sugalski                          even samuraiC > > dan@sidhe.org                         have teddy bears and evena? > >                                       teddy bears get drunk  >e    & Sent via Deja.com http://www.deja.com/ Before you buy.o   ------------------------------  % Date: Tue, 20 Jun 2000 18:18:38 -0400n  From: kuff@tessco.com (Hal Kuff)H Subject: Re: Storage Works / Snapshots / Maybe it's time to skip OpenVMSO Message-ID: <3E5EC94AC27E4386.D26E5BDAB54A4480.5A1B3C3225E6F830@lp.airnews.net>e  I    yes sadly we are running one application using RMS files..... Guess weaG could do Journaling but can't get a straight answer from Compaq on thatr either.l  J    How would you script this, if no supportable tool is out there?  RumorsG on HXTerm have abounded for ages.....    Would love to hear about theseo options....e          I In article <cVxVcTJMSKlp@eisner.decus.org>, young_r@eisner.decus.org (Rob 
 Young) wrote:b   > In articleD <05E9483E465FF40C.DBE5A72396AEDFFB.0693B6D86E224ECB@lp.airnews.net>," kuff@tessco.com (Hal Kuff) writes: > >  > > I > >    What we're looking for is a snapahot via command files or API that-I > > allows us to only take users offline for 5 mins.... cloning a striped0J > > mirrorset would defeat the purpose....  Adding mirrors and taking themK > > away to convert them to units for mounting would be clumsy and probably  > > unscriptable > >  > J >         It would be scriptable using HSDSA but I believe that is for HSJ! >         use only (pretty sure).l > D >         I went back and read your original post .. there is little >         detail here..h > + >         Going to make a couple guesses.  t > = >                 1)  You are using older database technologyoD >                         (old but good) that allows FREEZING of the$ >                         databases. > H >                 2)  You're not using Oracle as you can perform backupsJ >                         online with that and there would be no downtime. > L >                 3)  Since you are spending now or shortly, you are lookingK >                         at an ESA1000 (or follow-on) using Fibre Channel.( > G >         Yes, this can be done and in the timeframe you are looking atsL >         via DCL if the above are true and you have a reasonable number of  >         volumes.   > D >         The FREEZE mentioned in 1) causes writes to be flushed if C >         it is what I think it is... drop us more info out here ory >         drop me an email.  > % >                                 Roby   ------------------------------  % Date: Tue, 20 Jun 2000 19:00:16 -0400m' From: "Bill Todd" <billtodd@foo.mv.com> H Subject: Re: Storage Works / Snapshots / Maybe it's time to skip OpenVMS( Message-ID: <8iosq3$58e$1@pyrite.mv.net>  I Last I knew was the document included (as plain text) below.  I'm sure it:L was from an official Compaq source, but I've forgotten what that source was:    H Questions and Answers for Online Backup and Snapshot Services on OpenVMS
 April 2, 1999e    F Q:  What is OpenVMS doing about online backup and the shrinking backup window?e  H A: OpenVMS Engineering and Product Management have spent a great deal ofG time investigating the problem of backup and talking with key customersaJ about their online backup needs.  We have clearly heard from our customersE that there is an urgent need for a better backup solution on OpenVMS. H Instead of using the Snapshot Services code to address this need, we areG implementing enhancements to Volume Shadowing and to the OpenVMS BACKUPe utility.    - Q:  What are the plans for Snapshot Services?-  L A: OpenVMS Engineering and Product Management have decided not to productizeK Snapshot Services for OpenVMS.  Internal testing has identified significantuC technical and performance issues within the product in the areas of F scalability and cluster support that would be lengthy and difficult toJ resolve. In its present form, we feel that Snapshot Services will not meetI the high quality standards that OpenVMS customers expect.  We believe thehL quickest way to solve customer needs is through the changes described below.    * Q:  How will online backup be implemented?  L A: We are implementing a series of online backup solutions built on software write logging technology: J Splitting shadow sets and using fast shadow copy when a member is restoredD to a shadow set. (Copy time depends on update volume, not total data volume.)E "Catch-up copy" in which the write log is used to incorporate ongoing  updates into the backup.1 Physical incremental backup based on a write log. G System-wide "quiet point" to attain application-level data consistency.:@ Other performance and functional improvements to OpenVMS BACKUP.+ These solutions will be released in phases.n    ; Q:  What changes to Volume Shadowing are being implemented?   H A:  Volume Shadowing will be enhanced to deliver high performance onlineJ backup via shadow set splitting. This will enable a member of a shadow setI to be split off, used offline for backup, and then re-integrated into theiJ shadow set with minimal performance degradation.  Write logging technologyG will be used to reincorporate the shadow member with minimum copy time.e    9 Q:  What changes to OpenVMS BACKUP are being implemented?-  F A:  The BACKUP utility will be enhanced to take advantage of the write logging technology:sI A "catch-up" copy feature that allows BACKUP to keep up with ongoing disk2# updates while it is copying a disk. L Physical incremental backup based on a write log where only blocks that have actually changed are backed up.n" Improved backup support for tapes.@ Other performance and functional improvements to OpenVMS BACKUP.    > Q: How will this new online backup strategy benefit customers?  L A:  The phased implementation we are doing means customers will see progressG and get solutions faster than if we waited to ship all these new backup0 capabilities at once.b  G The enhancements we are doing to Volume Shadowing and BACKUP will alloweK customers to do backups without shutting down the application for hours and1D without suffering a significant performance penalty when a member is restored to a shadow set.v  K Some customers currently split shadow sets and use the removed member to dohI backups without stopping the application for the entire backup.  However,hL when the removed member is restored to the shadow set there is a significantI performance penalty while the restored member is updated. This is becausetK the entire shadow set is copied to the restored member. The enhancements we L are implementing will substantially reduce this performance impact. Only theE blocks that have actually been changed will be copied to the restoredc member.f  L The changes we are doing to support online backup will allow BACKUP to get aG consistent copy of a disk that is being written by an application. ThisgE means the application does not have to shutdown for the duration of ad backup.t  E All of these enhancements aim to increase application availability by ! minimizing the impact of backups.5    G Q: When will these changes to Volume Shadowing and BACKUP be available?)  I A: A project plan is being developed and resources are being allocated to J deliver these changes to Volume Shadowing and BACKUP.  We are developing aJ schedule and expect to deliver this functionality in phases.  We feel thatI we can begin to deliver these changes to Volume Shadowing and BACKUP in a I more timely manner than we could fix and productize the existing Snapshota Services code.  K We expect to have phase 1 ready by the beginning of YR2000.  We are looking K at alternatives to shipping these changes with an operating system release.h    3 Q:  Will a real "snapshot" capability be available?s  E A:  At this time, we feel that a solution to customers' online backupiJ problems is paramount.  After we address this issue with the work proposedF above (in Volume Shadowing and the BACKUP utility) we will examine the* requirements for a "snapshots" capability.    J Q:  What implication does this decision have for Snapshot Services that is) already a shipping product on Windows NT?e  E A: None.  Snapshot Services on Windows NT will continue to ship.  TheyC product is running very well and is meeting the needs of Windows NTa
 customers.    G <d.webb@mdx.ac.uk> wrote in message news:8iocob$kqg$1@nnrp1.deja.com...e > In articleF > <05E9483E465FF40C.DBE5A72396AEDFFB.0693B6D86E224ECB@lp.airnews.net>,% >   kuff@tessco.com (Hal Kuff) wrote:  > >, > >KI > >    What we're looking for is a snapahot via command files or API thattI > > allows us to only take users offline for 5 mins.... cloning a stripedwJ > > mirrorset would defeat the purpose....  Adding mirrors and taking themB > > away to convert them to units for mounting would be clumsy and
 > probably > > unscriptable >  >  >hH > There was going to a product to do precisely this - snapshot services.( > Unfortunately it was cancelled on VMS. > It sounded so great. >eE > Stop your applications for a second. Take a snapshot of your disks.d% > Continue on. Backup your snapshots. G > The snapshots used little disk space - you didn't need to have double E > your disk capacity - because they just duplicated metadata and only ; > redirected blocks over time as those blocks were updated.- >-G > If I recall correctly the software was produced for NT - then the VMSa > version got canned.  > I > We were promised that the functionality would be rolled into the futures  > improvements in shadowing etc. > B > So anyone - Will the new file system work etc in VMS 7.3 include > snapshot services ?. >/ >  > David Webb > VMS and Unix team leader > CCSS > Middlesex University > > B > > In article <4.3.2.7.0.20000617144256.00bbb650@24.8.96.48>, Dan
 > Sugalski > > <dan@sidhe.org> wrote: > >T0 > > > At 04:30 PM 6/16/00 -0400, Hal Kuff wrote: > > >t > > > > > > > >    IS there any kind of snapshot supported by OpenVMS?I > > > >    We'd sure like to buy about $200,000 worth of new Storage, butn > theiI > > > >ability to do snapshots from OpenVMS is not negotiable. This needsm > to ben9 > > > >scripted and run several times per day unattended.g > > > I > > > What kind of snapshots? If you're just talking about cloning disks,l	 > you can F > > > do that now and have been able to for ages. Either use the CLONE > support inD > > > the HSx controllers to snapshot individual drives or, for RAID
 > volumes andiI > > > such, make and break shadow sets. Rebuilds on the shadow sets are ah > bit of > > > a pain, but it works.p > > >  > > >t1 > > >                                         Dand > > >e6 > > > --------------------------------------"it's like > this"-------------------8 > > > Dan Sugalski                          even samuraiE > > > dan@sidhe.org                         have teddy bears and evenkA > > >                                       teddy bears get drunkr > >  >d > ( > Sent via Deja.com http://www.deja.com/ > Before you buy.    ------------------------------  % Date: Tue, 20 Jun 2000 22:06:12 -0400E+ From: "Main, Kerry" <Kerry.Main@compaq.com>C, Subject: RE: Techwise report on availabilityJ Message-ID: <910612C07BCAD1119AF40000F86AF0D805284437@kaoexc4.kao.dec.com>   Peter,  J >>> Never heard of this company before then, and so did our managers. ThisG very positive VMS Message was simply discarded by them, because of thisiG fact. GARTNER Group and sometimes IDC is their source. And when did theiG Gartner Group did write something positive about VMS the last time ?<<<p  	 My $.02 -a  @ I think it was back in the early '80's but I may be mistaken :-)  J Course, the mainnframe was also supposed to be dead in 1995 as well .. andI distributed computing was the model of the future in the mid 90's (servertJ consolidation is now the hot button) and Linux was not even on their radarK screen as an OS of the future in early 1998 either ... my favourite exampledK is a prediction that there was a 20% chance that Compaq would drop Alpha in L the next two years - as opposed to saying there was a 80% chance that Compaq would NOT drop Alpha.   H All in the eyes of the beholder I guess. Is the glass half empty or half full ?  A But, who ever looks back at how accurate these analysts were eh? o   :-)    Regards,  
 Kerry Main Senior Consultant,
 Compaq Canadan Professional Services  Voice : 613-592-4660 FAX   : 819-772-7036 Email : kerry.main@compaq.come       -----Original Message-----0 From: eplan@kapsch.net [mailto:eplan@kapsch.net]# Sent: Monday, June 19, 2000 8:00 AMe To: Info-VAX@Mvb.Saic.Com , Subject: Re: Techwise report on availability    H In article <39490377.99DC4FE5@gtech.com>, Arne =?iso-8859-1?Q?Vajh=F8j?=  <arne.vajhoej@gtech.com> writes:7 >Have you read the Techwise report on availability thath >is on www.openvms.compaq.com ?o   Yes. Months ago.   >It looks pretty good !    Indeed.   8 >But what I wonder about is: how independent & reputable >is this company Techwise ?   K Never heard of this company before then, and so did our managers. This very H positive VMS Message was simply discarded by them, because of this fact.I GARTNER Group and sometimes IDC is their source. And when did the Gartner < Group did write something positive about VMS the last time ?     -- l< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888 < FBFV/Information Services           E-mail  eplan@kapsch.netF <<< KAPSCH AG  Wagenseilgasse 1     PSImail PSI%(0232)281001141::EPLANH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"B "VMS is today what Microsoft wants Windows NT V8.0 to be!" Compaq, 22-Sep-1998    ------------------------------  % Date: Tue, 20 Jun 2000 13:06:59 -0500o% From: Chris Scheers <asi@airmail.net>b Subject: Re: VAX on Intel?O Message-ID: <EF5DC06EB7B6C04F.C792FFB7131D5CE3.A696BD7F6717D757@lp.airnews.net>a   Keith Brown wrote: >  > Chris Scheers wrote: > >' > > Glen Martin wrote: > > >- > > > Christopher Smith wrote: > > >nP > > > > Well, it would still be just as justifiable as an IA64 port, then (which1 > > > > has been tossed about as an idea here...)a > > > L > > > I agree with you here. No point in porting to a platform which doesn'tN > > > really give you an edge (although a PPC port would provide a boost in FPM > > > performance over either Alpha or x86 - this is where PPC really shines,  > > > not to mention AltiVec). > >bD > > You are missing the point.  A VMS port isn't needed to provide aL > > performance edge.  A port is needed to provide a market edge.  The point? > > of this port would be to provide an affordable entry level.h > > I > > It may be a poor analogy, but consider Linux.  An Alpha port of LinuxlI > > exists.  This is arguably the most powerfull Linux port available, soe1 > > why should there be any other ports of Linux?d > >kJ > > If the only port of Linux was for a DS20, it might be a nice port, butG > > do you think that the market at large would even be aware of Linux?  > >sJ > > That Linux can run on the hardware !!!THAT YOU ALREADY HAVE!!! is what+ > > has let Linux spread as much as it has.l  y= > You are assuming that IA64 will be priced lower that Alpha.i+ > Everything I have read so says otherwise.e     No I'm not.p  F Even if IA64 systems cost more than Alpha (note that the systems mightD cost less, even if the chip costs more), IA64s are going to get sold6 into many companies that have no reason to buy Alphas.  G I'm not talking about the companies that have already made a commitment C to VMS.  They will buy Alphas.  They have no need for an IA64 port.p  H But if you go into a company that does not currently have a VMS presenceE and try to sell them on a VMS based product, they will generally show ? you the door the moment that you tell them they have to buy new 	 hardware.b  D If VMS could be run on the hardware already present, a software saleH becomes possible.  And possibly a VMS convert is created.  Once you haveG proven the benefits of VMS, hopefully the customer starts buying "real" G VMS systems as their needs grow.  Some of these customers grow into the < high end customers.  That's how the VMS customer base grows.  G Without some way to get significant growth at the low end, the high end   may disappear through attrition.  G ----------------------------------------------------------------------- $ Chris Scheers, Applied Synergy, Inc.  G 817-237-3360 (Voice)    817-237-3074 (Fax)    Internet: asi@airmail.net-   ------------------------------  % Date: Tue, 20 Jun 2000 16:38:38 -0400u- From: JF Mezei <jfmezei.spamnot@videotron.ca>W Subject: Re: VAX on Intel?, Message-ID: <394FD647.64AD829F@videotron.ca>   Chris Scheers wrote:F > If VMS could be run on the hardware already present, a software saleJ > becomes possible.  And possibly a VMS convert is created.  Once you haveI > proven the benefits of VMS, hopefully the customer starts buying "real" # > VMS systems as their needs grow. h    J It would probably cost Compaq less to just make its DS10 systems priced so9 that potential customers don't see it as a entry barrier.s  I There has to be a cheasp VMS solution so that companies can start a piloteM project on VMS and grow it when they realise how succesful it is and how wells$ behaved and easy to maintain VMS is.   ------------------------------   Date: 20 Jun 2000 21:34:42 GMT* From: helbig@astro.rug.nl (Phillip Helbig) Subject: Re: VAX on Intel?. Message-ID: <8ioo1i$cvh$1@info.service.rug.nl>  5 In article <394FD647.64AD829F@videotron.ca>, JF Mezeiv' <jfmezei.spamnot@videotron.ca> writes: l   > Chris Scheers wrote:H > > If VMS could be run on the hardware already present, a software saleL > > becomes possible.  And possibly a VMS convert is created.  Once you haveK > > proven the benefits of VMS, hopefully the customer starts buying "real".% > > VMS systems as their needs grow. e >eL > It would probably cost Compaq less to just make its DS10 systems priced so; > that potential customers don't see it as a entry barrier.  >tK > There has to be a cheasp VMS solution so that companies can start a pilottO > project on VMS and grow it when they realise how succesful it is and how wellh& > behaved and easy to maintain VMS is.  F As I've said many times, this is needed, but it applies to SOFTWARE.  I Hardware is so cheap these days, even ALPHA, compared to the other costs nD of a business that I really don't think hardware prices are what is I stopping the spread of VMS.  I don't think it is software prices either, a except in the case of startups..  H I've posted often here on this subject, no-one has come up with any realE objections, but I haven't seen any official response (Terry: is there G anything in the works?).  Briefly, make licenses available at a nominal D cost to businesses until the profits exceed a certain fraction.  Or I charge 1% of last year's profits.  Easy for startup firms (who would pay /A nothing the first year) and Compaq gets 1% of the profits of the 8H successful firms, in return for giving them the license on the cheap at  the beginning. e  . Fiddle with the details, but you get the idea.   ------------------------------  % Date: Tue, 20 Jun 2000 19:50:18 -0400u& From: "Jeff Killeen" <Jeff@Killeen.cc> Subject: Re: VAX on Intel?2 Message-ID: <8iovvs$728$1@slb6.atl.mindspring.net>  I > Oh, yeah:  the zle white paper glowingly describes how Himalaya, Tru64,a andtL > Proliant work together to achieve this marketing breakthrough.  No mention > of VMS, though.n  L Do you think a message is there given this is one of their prime strategies?H I read the message as, whether technically valid or not, OVMS's greatestJ threat is a Compaq mindset of seeing Tru64 as the future _general purpose_H high reliability high performance big box.  Think with that mindset they& have VMS on IA32 will do much for VMS?     --     Jeff Killeen - www.Killeen.ccmE =====================================================================e2 "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:8io75n$8ks$1@pyrite.mv.net...L > Didn't find anything new there to change my first impression when I lookedK > at 'zle' a while ago that it was marketing fluff based on a configurationsI > that could have been put together by anyone with access to a reasonablyWG > high-end (in this case, Tandem Himalaya) system and satellites.  ThiseL > impression was reinforced by the fatuous statement in the white paper that? > adding a millisecond to the transaction time in a 350 millionaK > transactions-per-day envrironment would make the system untenable - as ifoI > there were no parallism involved and the transaction latency was in the / > hundred-microsecond range in the first place.  >wH > Tandem could have put together such a system before its acquisition byD > Compaq - they just would have had to resell the PC parts of it (orK > coordinate the integration of PCs purchased by the client) and substitute H > Tandem components for the Alpha parts.  Or some third party could have doneI > the job.  The fact that Compaq happens to own all the components of thedL > system is a relatively small advantage (though does play well to customersK > who want a single point of contact):  all the integration is via industry F > standards that anyone can take advantage of, and it's not clear that CompaqH > is doing a particularly better job in this case than anyone else could haveC > (and IBM could certainly have matched the single-point-of-contact 	 advantagea > as well).M >AG > The existence of this amalgam demonstrates neither the kind of uniqueoI > (hence, leverageable) integration nor pan-system credibility that I wasrD > talking about.  Tandem remains a niche (though an important niche)@ > architecture which it seems likely Compaq will be reluctant to
 'commoditize'lK > and bring within the price range of common customers, while Tru64 remains  aeH > distant also-ran in the Unix sweeps (and seems unlikely to improve itsI > position as the Unix market moves toward commoditization around Linux -h andiI > maybe Monterey, though that's more debatable) and VMS languishes in theiL > Compaq doghouse (though they've at least started to patch its roof).  It'sF > been two years since the DEC acquisition (and three since the TandemL > acquisition, though in that case Compaq seems content to leave well enoughG > alone):  Compaq likely has a very limited amount of time to bring itse AlphaeF > systems into the limelight where they can reinforce its PC offerings beforeH > its remaining customers turn elsewhere for solutions because they just don't F > trust Tru64's and VMS's (and hence to a significant degree Compaq's) futureE > viability - compared to their trust in IBM's and HP's single-vendort productiL > lines, or in multi-vendor options that include Dell, or even single-vendor! > PC configurations sold by Dell.u >aI > Oh, yeah:  the zle white paper glowingly describes how Himalaya, Tru64,  andcL > Proliant work together to achieve this marketing breakthrough.  No mention > of VMS, though.c >  > - bill >C1 > Jeff Killeen <Jeff@Killeen.cc> wrote in messagen! > news:394f44a7@news.toast.net... 6 > > "Bill Todd" <billtodd@foo.mv.com> wrote in message& > > news:8in1sp$dqv$1@pyrite.mv.net...K > > > I believe that Compaq won't survive (as anything like the force it isp > now,C > > > even in its relative disarray) without solidifying its non-PCU	 offeringsb > to$ > > > make them as credible as IBM's > >r > > http://www.compaq.com/zle/ > >i > >h > >h > > -- > >m > >d! > > Jeff Killeen - www.Killeen.ccgI > > =====================================================================h > >e > >b > >t >e >e   ------------------------------  % Date: Tue, 20 Jun 2000 20:55:38 -0500a7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>v Subject: Re: VAX on Intel?- Message-ID: <3950209A.C93576DE@earthlink.net>W   Bill Todd wrote: > [large snip]4 > Your closing statement ("Margins be damned if theyN > lose business (read: profits) to your competitors.") indicates a fundamentalK > misunderstanding of the relationship between margins and profits (without.C > the first, you have none of the second), which may explain a lot.e  F ...as does your consistent tendency to swing to extremes and avoid the middle ground.  G Perhaps I should have been more specific: EXHORBITANT margins be damnedv if ...  
 Happy now?  E ...and yes, since you are obviously not willing to take the word fromoD someone in the trenches, it stands to reason that you might possibly@ believe (admittedly brash assumption) your OWN experience if youD yourself were out here in the trenches with those of us in the know.  F ...and if you do, remember: if you're not approaching the Fortune 100,G you're barking up the wrong tree (according to you), since that's whereo( you seem to find Compaq's target market.   -- t David J. Dachtera  dba DJE Systemss" http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/m   ------------------------------  % Date: Wed, 21 Jun 2000 00:39:43 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>t Subject: Re: VAX on Intel?( Message-ID: <8ipgu7$o9j$1@pyrite.mv.net>  @ David J. Dachtera <djesys.nospam@earthlink.net> wrote in message' news:3950209A.C93576DE@earthlink.net...s   ...o  G > ...and yes, since you are obviously not willing to take the word from- > someone in the trenches,  H Well, comp.os.vms seems like the most likely forum in which to find suchC people.  Now, I can hear *you* loud and clear, but support for your I assertions (from the congregation most likely to be in a position to giveeH it, and the congregation most likely to be enthusiastic in giving it) is conspicuously lacking.  L I'm sure most people here would *like* to see VMS systems priced at par withI Wintel systems (or even Linux systems), but they don't seem to share your F conviction that this is the most effective route for Compaq to take inK revitalizing VMS.  In other words, they are able to differentiate what's ind6 their own interests from what's in Compaq's interests.  ,  it stands to reason that you might possiblyB > believe (admittedly brash assumption) your OWN experience if youF > yourself were out here in the trenches with those of us in the know.  G So I'll join you in asking everyone else here who is convinced that VMS H systems at Wintel prices are an important *immediate* step for Compaq toL take (or at least to start taking:  an IA port would take years, and whetherJ Alpha systems can be sold profitably at sub-$2K, let alone sub-$1K, pricesF is debatable), rather than a step that might be considered after VMS'sK position in markets with more need for its stengths, more profit potential,eL and less entrenched competition has shown signs of a turn-around, to step upJ and help you make the case that the volume necessary for simple break-even) performance in the very low end is there.'  L After all, if you're *really* 'in the know', you can generate the numbers toI prove it.  Since PCs sell in hundreds of millions of units in this marketaK segment and many companies (including Compaq and IBM) *still* have problems J just breaking even, the numbers you'll need to find evidence for are large ones.-   >-H > ...and if you do, remember: if you're not approaching the Fortune 100,I > you're barking up the wrong tree (according to you), since that's wherei* > you seem to find Compaq's target market.  K I find Compaq's potential market for VMS just about everywhere *except* the I very low end, where VMS's strengths are least conspicuous, its weaknessesiJ (lack of applications, lack of hardware support, lack of user familiarity,L lack of support-personnel familiarity) most conspicuous, and its competitionL most entrenched.  My guess is that, like Willie Sutton, Compaq will first goH where the money is, and if successful there explore areas where at leastJ some additional profit can be found, and only after enough success to makeE VMS perceived as a 'hot' system - if ever - consider taking on WinteltI directly in the commodity environment (though with the right software VMSr8 could take it on much earlier in server configurations).   - bill   >e > -- > David J. Dachteram > dba DJE Systemsa$ > http://home.earthlink.net/~djesys/ >s< > Unofficial Affordable OpenVMS Home Page and Message Board:- > http://home.earthlink.net/~djesys/vms/soho/I   ------------------------------  % Date: Wed, 21 Jun 2000 00:58:43 -0400c- From: JF Mezei <jfmezei.spamnot@videotron.ca>a Subject: Re: VAX on Intel?, Message-ID: <39504B7E.F4ECB7E3@videotron.ca>   Bill Todd wrote:N > I'm sure most people here would *like* to see VMS systems priced at par withK > Wintel systems (or even Linux systems), but they don't seem to share youryH > conviction that this is the most effective route for Compaq to take in > revitalizing VMS.i  8 It all depends on your definition of "revitalizing VMS".  N If you mean to only make VMS healthy in its remaining small market niche, thenM you're right. Making VMS priced competitively isn't necessary because the few 4 customers left are stuck with VMS and can be milked.  J But if you want VMS to regain some of the markets it used to have then youJ need to compete against those systems that stole your customers during the last decade.   ------------------------------  % Date: Wed, 21 Jun 2000 01:13:46 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>A Subject: Re: VAX on Intel?( Message-ID: <8ipiu2$ref$1@pyrite.mv.net>  8 JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message& news:39504B7E.F4ECB7E3@videotron.ca... > Bill Todd wrote:K > > I'm sure most people here would *like* to see VMS systems priced at parp withH > > Wintel systems (or even Linux systems), but they don't seem to share yourJ > > conviction that this is the most effective route for Compaq to take in > > revitalizing VMS.o >t: > It all depends on your definition of "revitalizing VMS". >-K > If you mean to only make VMS healthy in its remaining small market niche,  thenK > you're right. Making VMS priced competitively isn't necessary because the4 few26 > customers left are stuck with VMS and can be milked. >wL > But if you want VMS to regain some of the markets it used to have then youL > need to compete against those systems that stole your customers during the > last decade.  K Wouldn't that be more the Unix crowd than Windows?  Competing at that level H (and against Windows as it attempts to encroach upon that level) is what I've been advocating.g  L But, just as there is no conspicuous support for David Dachtera's assertionsL that very-low-end VMS systems are the key to a revival, there is also littleI obvious support for your assertions that VMS is priced uncompetitively inn& mid-range-to-high-end market segments.  F My impression is that most people here would find VMS pricing at leastL fairly reasonable (today - and tomorrow if it tracks general price movementsC in its market segments) if they could see Compaq taking the actionsiG necessary to maintain VMS's leadership and improve its acceptability todK wider audiences - i.e., keep it vital and make it more competitive - rather K than simply appearing to milk it.  And again, if my impression is mistaken, K this is the forum most likely to correct it (and if that doesn't happen, itdF will at least strongly suggest that yours is the mistaken perception).   - bill   ------------------------------  % Date: Tue, 20 Jun 2000 08:59:00 +0045 ( From: erktjm@dvkrdsvomg.cie-pub1.etat.luY Subject: ~-~ Save up to 70% on Your Life Insurance -FREE Quote                       +a#nt8 Message-ID: <73swojqc3w4r3df0ycs7.0yy48o@202.234.64.204>  < <HTML><HEAD><TITLE>Insurance</TITLE><STYLE>td {font-family:  arial}</STYLE></HEAD> N <BODY BGCOLOR=#FDF5E6><DIV ALIGN=CENTER STYLE=FONT-FAMILY:TIMES><FONT SIZE=+3 M COLOR=RED>Save up to 70% on your Life Insurance!</FONT><BR><FONT SIZE=+2>Why tO Spend More Than You Have To?</FONT><BR>Check out these example monthly rates...rG <BR>10-year level premium term insurance<BR>(20 and 30 year rates also h available><td></DIV><BR>, <TABLE WIDTH=500 ALIGN=CENTER BGCOLOR=WHITE> <TR>
 <TD></TD> ) <TD COLSPAN=2 ALIGN=CENTER>$250,000</TD> p) <TD COLSPAN=2 ALIGN=CENTER>$500,000</TD>  + <TD COLSPAN=2 ALIGN=CENTER>$1,000,000</TD> h </TR>  <TR BGCOLOR=#003366>   <TD STYLE=COLOR:WHITE>Age</TD> .  <TD STYLE=COLOR:WHITE>Male</TD> " <TD STYLE=COLOR:WHITE>Female</TD>   <TD STYLE=COLOR:WHITE>Male</TD> " <TD STYLE=COLOR:WHITE>Female</TD>   <TD STYLE=COLOR:WHITE>Male</TD> & <TD STYLE=COLOR:WHITE>Female</TD></TR> <TR>N <TD>30</TD><TD>$12</TD><TD>$11</TD><TD>$19</TD><TD>$15</TD><TD>$31</TD><TD>$27 </TD>p </TR>n <TR>N <TD>40</TD><TD>$15</TD><TD>$13</TD><TD>$26</TD><TD>$21</TD><TD>$38</TD><TD>$37 </TD>- </TR>- <TR>N <TD>50</TD><TD>$32</TD><TD>$24</TD><TD>$59</TD><TD>$43</TD><TD>$107</TD><TD>$7 8</TD> </TR>o <TR>N <TD>60</TD><TD>$75</TD><TD>$46</TD><TD>$134</TD><TD>$87</TD><TD>$259</TD><TD>$ 161</TD> </TR>: </TABLE>N <DIV ALIGN=CENTER>(Smoker rates also available)<P><FONT SIZE=+1>Take a minute L to fill out the simple form below and receive a FREE quote<BR>comparing the H best values from among hundreds of the nation's top insurance companies!J </FONT></DIV><HR SIZE=1><TABLE><TD><FORM ACTION='mailto:asavevv@china.com?; subject=1m-msc' METHOD=POST ENCTYPE=TEXT/PLAIN>*All Fields i1 required</TD></TR><TD>First Name:</TD><TD><INPUT V< NAME=FIRST_NAME></TD></TR><TR><TD>Last Name:</TD><TD><INPUT K NAME=LAST_NAME></TD></TR><TR><TD>Address:</TD><TD><INPUT NAME=ADDRESS></TD>n" </TR><TR><TD>City:</TD><TD><INPUT = NAME=CITY></TD></TR><TR><TD>State:</TD><TD><INPUT NAME=STATE m- SIZE=2></TD></TR><TR><TD>Zip:</TD><TD><INPUT :J NAME=ZIP_CODE></TD></TR><TR><TD>Day Phone:</TD><TD><INPUT NAME=DAY_PHONE> > (xxx-xxx-xxxx)</TD></TR><TR><TD>Evening Phone:</TD><TD><INPUT C NAME=EVENING_PHONE></TD></TR><TR><TD>Fax:</TD><TD><INPUT NAME=FAX> dF (xxx-xxx-xxxx)</TD></TR><TR><TD>Email:</TD><TD><INPUT NAME=EMAIL></TD>, </TR><TR><TD>Male or Female:</TD><TD><INPUT D NAME=MALE_OR_FEMALE></TD></TR><TR><TD>Date of Birth:</TD><TD><INPUT  NAME=DATE_OF_BIRTH SIZE=13> ? (mm/dd/yy)</TD></TR><TR><TD>Type of Insurance:</TD><TD><SELECT C( NAME=TYPE_OF_INSURANCE SIZE=1><OPTION>30+ Yr Guaranteed Level Term<OPTION SELECTED>20eE Yr Guaranteed Level Term<OPTION>15 Yr Guaranteed Level Term<OPTION>10o@ Yr Guaranteed Level Term<OPTION>Universal Life<OPTION>2nd-to-die= (Survivorship Insurance)</SELECT></TD></TR><TR><TD>Insurance nK Amount:</TD><TD><SELECT NAME=INSURANCE_AMOUNT><OPTION>$100,000<OPTION>$150, @ 000<OPTION>$200,000<OPTION>$250,000<OPTION>$300,000<OPTION>$350,I 000<OPTION>$400,000<OPTION>$450,000<OPTION SELECTED>$500,000<OPTION>$550,a@ 000<OPTION>$600,000<OPTION>$650,000<OPTION>$700,000<OPTION>$750,N 000<OPTION>$800,000<OPTION>$850,000<OPTION>$900,000<OPTION>$950,000<OPTION>$1,L 000,000<OPTION>$1,500,000<OPTION>$2,000,000<OPTION>$2,500,000<OPTION>$3,000,H 000<OPTION>$3,500,000<OPTION>$4,000,000<OPTION>$4,500,000<OPTION>$5,000,M 000<OPTION>above $5,000,000</SELECT></TD></TR><TR><TD>Height:</TD><TD><INPUT s" NAME=HEIGHT SIZE=10></TD></TR><TR>L <TD>Weight:</TD><TD><INPUT NAME=WEIGHT SIZE=3> lbs</TD></TR><TR><TD>Tobacco E Use:</TD><TD><SELECT NAME=TOBACCO_USE SIZE=1><OPTION SELECTED>(Please L Select)<OPTION>Have never smoked or used nicotine<OPTION>Used to smoke, but & quit less than 1 yr ago<OPTION>Used toM smoke 1-3 yrs ago<OPTION>Used to smoke 3-5 yrs ago<OPTION>Used to smoke over ,8 5 yrs ago<OPTION>Currently smoke cigarettes<OPTION>OtherE nicotine use-cigars/pipe/chew/patch</SELECT></TD></TR><TR><TD>Health aC Status:</TD><TD><SELECT NAME=HEALTH_STATUS><OPTION SELECTED>(PleaserH Select)<OPTION>Excellent: trim and athletic, no medications<OPTION>Good:B no infirmities and no medications<OPTION>Fair: slightly overweight< or taking medication<OPTION>Poor: have/had a serious health  condition</SELECT></TD>eF </TR><TR><TD>Health conditions?<BR><INPUT NAME=HEALTHPROBS TYPE=RADIO 8 VALUE=YES>Yes<INPUT CHECKED NAME=HEALTHPROBS TYPE=RADIO * VALUE=NO>No</TD><TD>Explain:<BR><TEXTAREA K NAME=HEALTHPROBSDESC></TEXTAREA></TD></TR><TR><TD>Prescription medications?-J <BR><INPUT NAME=TAKERX TYPE=RADIO VALUE=YES>Yes<INPUT CHECKED NAME=TAKERX 5 TYPE=RADIO VALUE=NO>No</TD><TD>Explain:<BR><TEXTAREA @L NAME=TAKERXDESC></TEXTAREA></TD></TR><TR><TD>Do you engage in any hazardous C activities?<BR>(i.e. scuba,skydiving,private pilot,etc.)<BR><INPUT tG NAME=HAZAVOCOCC TYPE=RADIO VALUE=YES>Yes<INPUT CHECKED NAME=HAZAVOCOCC  5 TYPE=RADIO VALUE=NO>No</TD><TD>Explain:<BR><TEXTAREA sN NAME=HAZAVOCOCCDESC></TEXTAREA></TD></TR><TR><TD>Did your parents or siblings O have<BR> heart disease or cancer prior to age 60?<BR><INPUT NAME=FAMILYHISTORY a TYPE=RADIO d: VALUE=YES>Yes<INPUT CHECKED NAME=FAMILYHISTORY TYPE=RADIO * VALUE=NO>No</TD><TD>Explain:<BR><TEXTAREA M NAME=FAMILYHISTORYDESC></TEXTAREA></TD></TR></TABLE><DIV ALIGN=CENTER><INPUT tA TYPE=SUBMIT VALUE="Submit Quote Request"></DIV><P><TABLE><TR><TD fN STYLE=FONT-SIZE:10PT>All quotes will be from insurance companies rated A-, A, L A+ or A++ by A.M. Best. Actual premiums and coverage availability will vary O depending upon age, sex, state, health history and tobacco use. THIS IS NOT AN  G OFFER OR CONTRACT TO BUY INSURANCE PRODUCTS, but rather a confidential  O informational inquiry. All information submitted is strictly confidential, and  O will be given to an insurance professional licensed in your state of residence,hM  who will contact you and provide your quote directly. Further transmissions n3 of this email may be stopped at no cost to you. <A  H HREF="mailto:rem865@123india.com">PLEASE CLICK HERE</A> AND TYPE REMOVE.  </TD></TR></TABLE></BODY></HTML>   ------------------------------   End of INFO-VAX 2000.344 ************************G > The existence of this amalgam demonstrates neither the kind of uniqueoI > (hence, leverageable) integration nor pan-system credibility that I wasrD > talking about.  Tandem remains a niche (though an important niche)@ > architecture which it seems likely Compaq will be reluctant to
 'commoditi