1 INFO-VAX	Sun, 18 Jun 2000	Volume 2000 : Issue 338       Contents:8 Co-existence of O/S's in a Galaxy/Wildfire configuration< Re: Co-existence of O/S's in a Galaxy/Wildfire configuration< Re: Co-existence of O/S's in a Galaxy/Wildfire configuration  Re: comments on filesystems etc. Re: CONV$RECLAIM question  Re: CONV$RECLAIM question  DEC EQUIPMENT FOR SALE Re: Disk Size in OpenVMS 7.1 Re: Disk Size in OpenVMS 7.1* Disk taking itself offline during install?. Re: Disk taking itself offline during install?3 Euro2000 football divination service and  more..... * Re: Files-11 ODS-2 Readability for FreeBSD* Re: Files-11 ODS-2 Readability for FreeBSD Re: Fun VMS Facts? Re: Fun VMS Facts?- RE: How do I calculate CONNECT TIME from DCL? - Re: How do I calculate CONNECT TIME from DCL? - Re: How do I calculate CONNECT TIME from DCL? > Installing OpenVMS on VAX 3100 30/40: System Password problemsB Re: Installing OpenVMS on VAX 3100 30/40: System Password problems. Re: OpenVMS clusters vs other systems clusters. Re: OpenVMS clusters vs other systems clusters. Re: OpenVMS clusters vs other systems clusters. Re: OpenVMS clusters vs other systems clusters# Pathworks ( AS v7.2a) vs MSDEV VC++  Re: Q: Maintainance mode? ? 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: Storage Works / Snapshots / Maybe it's time to skip OpenVMS ? Re: Storage Works / Snapshots / Maybe it's time to skip OpenVMS  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?  Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX on Intel?  Re: VAX on Intel? , VMSeti CGI script update - for VMS SETI@home  F ----------------------------------------------------------------------  ( Date: Sat, 17 Jun 2000 22:51 +0100 (BST)* From: craig@adamson.org.uk (Craig Adamson)A Subject: Co-existence of O/S's in a Galaxy/Wildfire configuration @ Message-ID: <memo.20000617225103.19315A@adamson.compulink.co.uk>   Hi!   ? Is it possible for OpenVMS, Windows NT and Unix to co-exist in    a Galaxy and/or Wildfire system?   Craig.   ------------------------------  % Date: Sat, 17 Jun 2000 19:00:48 -0500 ) From: "John E. Malmberg" <wb8tyw@qsl.net> E Subject: Re: Co-existence of O/S's in a Galaxy/Wildfire configuration 7 Message-ID: <0a9101bfd8b8$43e0a0c0$020a0a0a@xile.realm>   6 Craig Adamson <craig@adamson.org.unitedkingdom> wrote: > Hi!  > @ > Is it possible for OpenVMS, Windows NT and Unix to co-exist in" > a Galaxy and/or Wildfire system?  J Such a configuration has been demoed a few times, however I do not know if8 it is available as a officially supported configuration.   -John  wb8tyw@qsl.network   ------------------------------  # Date: Sun, 18 Jun 2000 01:57:51 GMT 9 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) E Subject: Re: Co-existence of O/S's in a Galaxy/Wildfire configuration + Message-ID: <uGOGRfBH49Pu@eisner.decus.org>   m In article <memo.20000617225103.19315A@adamson.compulink.co.uk>, craig@adamson.org.uk (Craig Adamson) writes:   A > Is it possible for OpenVMS, Windows NT and Unix to co-exist in  " > a Galaxy and/or Wildfire system?  A Wildfire systems support "hard partitioning" which allow multiple > operating systems to co-exist.  Depending on how big a machine? you buy up to 8 different operating systems could be used.  But ? you might choose to have only two (or one) hard partitions even = with a maximum number of CPUs.  One purpose of all this is to < run multiple versions of the same operating system.  So far,< the only operating systems supported on Wildfire are VMS and: Tru64 Unix.  Compaq has said that Linux support is coming.7 For VMS and Tru64, only the very latest versions run on 8 this hardware, so mixing versions is not a reality until; they have a second version compatible with the hardware :-)   : Galaxy software is currently a VMS-only feature, providing; "soft partitioning" on Wildfire, older GS, 8400, 8200, 4100 8 and ES40 machines.  It allows either total separation or9 partial separation allowing for more efficient contention  for operating system resources.    ------------------------------  % Date: Sat, 17 Jun 2000 21:25:08 -0500 , From: "Glenn C. Everhart" <Everhart@GCE.com>) Subject: Re: comments on filesystems etc. ' Message-ID: <394BECB3.246D1FA4@GCE.com>   > I'm afraid I lost Bill's last reply but there are small points to make.= 1. My less than sanguine evaluation of 3rd party filesystems, < even where interfaces are published, is based on experiences> of myself and others I know having had such interfaces changed< (often unexpectedly) by the OS vendor. This is why I counsel> people to be cautious about such things these days, unless the9 OS vendor is routinely including the 3rd party app in its A regression test suite. Internal interface specs can and do change ; or get shortcut at times. Whoso doubts, I wish luck: he has ! not had the elephant roll on him. =   This is not to say never to buy such apps, just to be aware ; that there are dangers. I also hoped to give some clues why @ a reaction other than enthusiasm might greet a proposed business; plan to build and sell such a thing. Some vendors have been = able to do it, where enough misfeatures can be overcome by no < lesser means. The strategy remains risky for both vendor and; customer compared to the OS vendor supplying the functions.   : 2. I've pointed out that misapplied caching can cause data8 corruption. (Those who have had files lost after a power: failure on a unix box will recognize this; it has happened< to many of my colleagues running on sun.) This is not always? due to the OS, nor to the app; it can be operator error. Simple : example: someone runs a privileged app that turns on drive; caching on a disk drive, unbeknownst to the apps running on : top. Power fails and data is lost. Fault: clearly with the5 user. My colleagues who lost files on their Sun boxes < of course did nothing so weird; the filesystem simply wasn't8 backing up its data often enough. It gained speed by not: having to touch the disk every time, but became vulnerable? to the local power company's vagaries. (This particular kind of ? damage is one of the selling points of one of the third parties = selling replacement filesystems; they take measures to reduce  it.)    9 The points here are based on experiences, not conjecture.   9 They do not imply that all unix filesystems lose data nor : that it is completely impossible to replace vendor pieces.$ Neither of those assertions is true.  > The more pervasive the need to programatically say "I mean it"= when writing, of course, the more pervasive are opportunities = to omit some. (VMS tends to have the opposite problem, namely @ ignoring I/O status returned). VMS offers some very fine grained: abilities to ensure data gets to disk (including datacheck> options if they are wanted), and your $qio write when complete9 tells you it's there. This makes some test issues simple. < Write back caching introduces an added element of complexity: which is traded for speed, and even reputable vendors have= had difficulty with dealing with that complexity. I note that < the 3rd party Sun vendor offers a switch to avoid writeback,> so customers can choose behavior. Its existence tends to prove5 the need NOT to have writeback behavior at all times.    Enough of this.    ------------------------------  % Date: Sat, 17 Jun 2000 23:14:02 -0400 * From: David A Froble <davef@tsoft-inc.com>" Subject: Re: CONV$RECLAIM question- Message-ID: <394C3E7A.F292C6B4@tsoft-inc.com>   : > JF Mezei <jfmezei.spamnot@videotron.ca> wrote in message( > news:394A8E37.A34CCAAC@videotron.ca... >  > ...  > N > > I don't see why people want to avoid indexed files like the plague. Once IL > > know what the best way of building one and cleaning up, it is not such a > bad issue.  O If I remember the start of this thread correctly, you're using the indexed file N for some type of queue.  Quite do-able for this purpose.  But most of the timeN when people set up a queue file, expecting to store and forward some data, andM also expecting specific data to have a limited life, some type of linked list N structure is one of the most favored design decisions.  With such a structure,M you have unused nodes on a list, and a list for each of the data types you're O temporarily storing.  Need a node, pop it off the ununed list, set up the data, M push it onto the appropriate list.  Finished with a node, pop it off the list I and push it on the unused list.  Quite efficient, allows FIFO or LIFO, or H whatever, re-uses nodes quite easily, (once you've got your push and popE routines working well), and your clean-up problem just doesn't exist.   O Not saying your idea is wrong.  Just stating what is usually used for this type J of application.  Maybe that's why people may be negative on the ISAM file.   Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Sun, 18 Jun 2000 01:07:31 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> " Subject: Re: CONV$RECLAIM question, Message-ID: <394C5911.A273DB5B@videotron.ca>   David A Froble wrote: Q > If I remember the start of this thread correctly, you're using the indexed file P > for some type of queue.  Quite do-able for this purpose.  But most of the timeP > when people set up a queue file, expecting to store and forward some data, andO > also expecting specific data to have a limited life, some type of linked list 9 > structure is one of the most favored design decisions.    B But using RMS makes it easier to implement a clusterable solution.  G CONV$RECLAIM is no big deal to use.  And as someone suggested, if I use N buckets large enough, chances are that the reader portion of the queue will beK able to delete records in the bucket fast enough to prevent the bucket from P getting full. (which means that the deleted records inside a bucket get reused).  I Also, using RMS instead of a proprietary home grown equivalent means that H VMS's standard tools can be used to diagnose and recover a corrupt file.  J RMS may not be the fastest solution for my application, but I would ratherE have a robust solution that works fast enough on a Microvax II than a K potentially less robust solution that will corrupt the queue much faster on  real VMS systems.    ------------------------------   Date: 17 Jun 2000 19:02:03 GMT% From: chain28906@aol.com (CHain28906)  Subject: DEC EQUIPMENT FOR SALE : Message-ID: <20000617150203.15881.00008352@ng-md1.aol.com>  	 VAX 7840  	 VAX 4705A 	 VAX 4700A  AS 8400  AS 4100  AS 1200  MS7AA-FA  2GB FOR VAX 7000 MS7AA-DA 1GB FOR VAX 7000  MS7CC-FA  2GB FOR 8400 MS7CC-GA 4GB FOR 8400  MS332-GA  2GB FOR AS 4100  MS332-FA   1GB FOR AS 4100 MS330-EA  512  FOR AS 4100 HSZ50-AF HSD50-AF HSJ50-AF HSG80-BJ	 AS255/233 	 AS255/300 	 AS500/333 	 AS500/400 	 AS800/500  CIPCA-BA CIPCA-AA DS-RZ1DD-VW  DS-RZ1ED-VW  DS-RZ1EF-VW  DS-RZ1EA-VW  DS-RZ1FC-VW   & MUCH MORE IN STOCK NEW AND REFURBISHED: ALL EQUIPMENT IS FULLY TESTED AND CONFIGURED WITH WARRANTY TRADE IN OFFERED ON SURPLUS $ CALL OR EMAIL WITH YOUR REQUIREMENTS   WWW.GOACSI.COM P 716-339-9932 F 716-339-9163   ------------------------------  % Date: Sat, 17 Jun 2000 22:12:25 +0400 * From: "Yuri Ermakov" <ermak@cbr.ryazan.su>% Subject: Re: Disk Size in OpenVMS 7.1 . Message-ID: <8igcs2$ha$1@summer.cbr.ryazan.su>  $ > Thank you very much for your help. > L > Below is what I got. Am I correct to say I have one disk of 4.3 Gb on that
 > machine?  *     Your have 2 disks 4.3Gb DKA0:, DKA100:     DKA400: - this CD-ROM      DVA0: - floppy    > Thank you again for your help. >  >  >  > G > Device                  Device           Error    Volume         Free  Trans  > Mnt H >  Name                   Status           Count     Label        Blocks Count  > Cnt H > BLOL1$DKA0:             Mounted              0  AXPVMSSYS       411381 876  > 1 H > BLOL1$DKA100:           Mounted              0  USER            602082 1  > 1 0 > BLOL1$DKA400:           Online wrtlck        00 > BLOL1$DVA0:             Online               0 > $ sh device blol1$dka0 /full > A > Disk BLOL1$DKA0:, device type DEC RZ1CB-CS, is online, mounted, 
 file-oriented H >     device, shareable, available to cluster, error logging is enabled. > > >     Error count                    0    Operations completed
 > 619815183 >     Owner process                 ""    Owner UIC 
 > [SYSTEM]2 >     Owner process ID        00000000    Dev Prot > S:RWPL,O:RWPL,G:R,W = >     Reference count              452    Default buffer size  > 512 ; >     Total blocks             8380080    Sectors per track  > 113 = >     Total cylinders             3708    Tracks per cylinder  > 20 > @ >     Volume label         "AXPVMSSYS"    Relative volume number > 0 ; >     Cluster size                   9    Transaction count  > 876 ? >     Free blocks               411381    Maximum files allowed  > 4190045 >     Extend quantity                5    Mount count  > 1 4 >     Mount status              System    Cache name > "_BLOL1$DKA0:XQPCACHE"H >     Extent cache size             64    Maximum blocks in extent cache > 41138 J >     File ID cache size            64    Blocks currently in extent cache > 1827F >     Quota cache size               0    Maximum buffers in FCP cache > 10302 >     Volume owner UIC           [1,1]    Vol Prot > S:RWCD,O:RWCD,G:RWCD,W:RWCD  > G >   Volume Status:  subject to mount verification, protected subsystems  enabled, > ? >       file high-water marking, write-through caching enabled.  >   > $ sh device blol1$dka100 /full > C > Disk BLOL1$DKA100:, device type DEC RZ1CB-CA, is online, mounted,  > file-oriented H >     device, shareable, available to cluster, error logging is enabled. > > >     Error count                    0    Operations completed	 > 2876408 3 >     Owner process                 ""    Owner UIC 
 > [SYSTEM]2 >     Owner process ID        00000000    Dev Prot > S:RWPL,O:RWPL,G:R,W = >     Reference count                1    Default buffer size  > 512 ; >     Total blocks             8380080    Sectors per track  > 113 = >     Total cylinders             3708    Tracks per cylinder  > 20 > @ >     Volume label              "USER"    Relative volume number > 0 ; >     Cluster size                   9    Transaction count  > 1 ? >     Free blocks               602082    Maximum files allowed  > 4190045 >     Extend quantity                5    Mount count  > 1 4 >     Mount status              System    Cache name > "_BLOL1$DKA0:XQPCACHE"H >     Extent cache size             64    Maximum blocks in extent cache > 60208 J >     File ID cache size            64    Blocks currently in extent cache > 53793 F >     Quota cache size               0    Maximum buffers in FCP cache > 10302 >     Volume owner UIC        [SYSTEM]    Vol Prot > S:RWCD,O:RWCD,G:RWCD,W:RWCD  > K >   Volume Status:  subject to mount verification, file high-water marking,  > write- >       back caching enabled.  >  >  >  > Yuri Ermakov wrote:  > 	 > > > Hi,  > > > 1 > > > I am new at openVMS and would like to know:  > > > J > > > 1. which commands I shall use for displaying the hard drive complete > > > size,  > >  > >     show device d $ > >     show device <disk_name>/full > > L > > > 2. which commands I shall use for displaying the harware configuration &  > > > the memory size  > >  > >     show memory /full/all  > >     analize/system > > L > > > 3. is there any place on Internet that provides a complete list of VMS > > > commands! > > > and usefull books about VMS  > > 1 > > http://www.openvms.compaq.com:8000/index.html  > >  > > >  > > > Thank you for your help. > > >  > > >  > > >  >    ------------------------------  % Date: Sat, 17 Jun 2000 22:43:44 +0200  From: x86 <x86@libertysurf.fr>% Subject: Re: Disk Size in OpenVMS 7.1 . Message-ID: <394BE2FF.E0601796@libertysurf.fr>   Thank you again!   Yuri Ermakov wrote:n  & > > Thank you very much for your help. > >iN > > Below is what I got. Am I correct to say I have one disk of 4.3 Gb on that > > machine? >o, >     Your have 2 disks 4.3Gb DKA0:, DKA100: >     DKA400: - this CD-ROM. >     DVA0: - floppy >o" > > Thank you again for your help. > >M > >O > >E > > I > > Device                  Device           Error    Volume         Freeo > Transr > > MntlJ > >  Name                   Status           Count     Label        Blocks > Counti > > CntoJ > > BLOL1$DKA0:             Mounted              0  AXPVMSSYS       411381 > 876y > > 1eJ > > BLOL1$DKA100:           Mounted              0  USER            602082 > 1  > > 1L2 > > BLOL1$DKA400:           Online wrtlck        02 > > BLOL1$DVA0:             Online               0  > > $ sh device blol1$dka0 /full > >mC > > Disk BLOL1$DKA0:, device type DEC RZ1CB-CS, is online, mounted,P > file-oriented J > >     device, shareable, available to cluster, error logging is enabled. > >t@ > >     Error count                    0    Operations completed > > 619815185 > >     Owner process                 ""    Owner UICM > > [SYSTEM]4 > >     Owner process ID        00000000    Dev Prot > > S:RWPL,O:RWPL,G:R,Wi? > >     Reference count              452    Default buffer sizei > > 512 = > >     Total blocks             8380080    Sectors per trackM > > 113t? > >     Total cylinders             3708    Tracks per cylindert > > 20 > > B > >     Volume label         "AXPVMSSYS"    Relative volume number > > 0n= > >     Cluster size                   9    Transaction countt > > 876 A > >     Free blocks               411381    Maximum files allowedI
 > > 4190047 > >     Extend quantity                5    Mount counte > > 1n6 > >     Mount status              System    Cache name > > "_BLOL1$DKA0:XQPCACHE"J > >     Extent cache size             64    Maximum blocks in extent cache	 > > 41138)L > >     File ID cache size            64    Blocks currently in extent cache > > 1827H > >     Quota cache size               0    Maximum buffers in FCP cache > > 10304 > >     Volume owner UIC           [1,1]    Vol Prot > > S:RWCD,O:RWCD,G:RWCD,W:RWCDa > >aI > >   Volume Status:  subject to mount verification, protected subsystems 
 > enabled, > >1A > >       file high-water marking, write-through caching enabled.: > >C" > > $ sh device blol1$dka100 /full > > E > > Disk BLOL1$DKA100:, device type DEC RZ1CB-CA, is online, mounted,  > > file-orientedcJ > >     device, shareable, available to cluster, error logging is enabled. > > @ > >     Error count                    0    Operations completed > > 2876408a5 > >     Owner process                 ""    Owner UICo > > [SYSTEM]4 > >     Owner process ID        00000000    Dev Prot > > S:RWPL,O:RWPL,G:R,Wn? > >     Reference count                1    Default buffer size0 > > 512 = > >     Total blocks             8380080    Sectors per track  > > 113:? > >     Total cylinders             3708    Tracks per cylindere > > 20 > >OB > >     Volume label              "USER"    Relative volume number > > 0s= > >     Cluster size                   9    Transaction counts > > 1 A > >     Free blocks               602082    Maximum files allowed 
 > > 4190047 > >     Extend quantity                5    Mount countr > > 1n6 > >     Mount status              System    Cache name > > "_BLOL1$DKA0:XQPCACHE"J > >     Extent cache size             64    Maximum blocks in extent cache	 > > 60208eL > >     File ID cache size            64    Blocks currently in extent cache	 > > 53793pH > >     Quota cache size               0    Maximum buffers in FCP cache > > 10304 > >     Volume owner UIC        [SYSTEM]    Vol Prot > > S:RWCD,O:RWCD,G:RWCD,W:RWCD  > >tM > >   Volume Status:  subject to mount verification, file high-water marking,r
 > > write- > >       back caching enabled.n > >r > >y > >l > > Yuri Ermakov wrote:i > >m > > > > Hi,t > > > >r3 > > > > I am new at openVMS and would like to know:t > > > >iL > > > > 1. which commands I shall use for displaying the hard drive complete
 > > > > size,l > > >h > > >     show device da& > > >     show device <disk_name>/full > > >nN > > > > 2. which commands I shall use for displaying the harware configuration > &  > > > > the memory size  > > >  > > >     show memory /full/allr > > >     analize/system > > > N > > > > 3. is there any place on Internet that provides a complete list of VMS > > > > commands# > > > > and usefull books about VMSk > > >M3 > > > http://www.openvms.compaq.com:8000/index.htmle > > >v > > > >i  > > > > Thank you for your help. > > > >e > > > >m > > > >  > >s   ------------------------------  % Date: Sat, 17 Jun 2000 22:16:32 -0500v' From: Bill Bradford <mrbill@mrbill.net>e3 Subject: Disk taking itself offline during install?S. Message-ID: <20000617221632.P18668@mrbill.net>  K I finally got media (and yes, the VMS Hobbyist license allows you to freelyrF copy OS media from others), got the install started, and ran into thisI problem.  Replaced the HD, and I still get the problem with the second HDo as well.   Here's what happens:  E * Enter name of drive holding the OpenVMS distribution media: DKA400:m3 * Is the OpenVMS media ready to be mounted? [N] YESlH %SYSTEM-I-MOUNTVER, DKA200: is offline.  Mount verification in progress.  ? Or, the system will properly mount the CD-ROM drive/media, and s@ give me the DKA200: offline message while its extracting OpenVMS library files, for instance.  B Any suggestion of why this might be happening?  When it does, I've> waited for up to 20 minutes before giving up and rebooting the box (via the power switch).p   Bill   -- f) +-------------------\ /-----------------+ ) | Bill Bradford      |  www.sunhelp.org |a) | mrbill@mrbill.net  |   www.decvax.org |o) | Austin, Texas USA  |    www.pdp11.org |e) +-------------------/ \-----------------+h   ------------------------------  % Date: Sun, 18 Jun 2000 00:20:01 -0400t* From: David A Froble <davef@tsoft-inc.com>7 Subject: Re: Disk taking itself offline during install?y- Message-ID: <394C4DF1.3DF34B05@tsoft-inc.com>n   Bill Bradford wrote: > M > I finally got media (and yes, the VMS Hobbyist license allows you to freelyrH > copy OS media from others), got the install started, and ran into thisK > problem.  Replaced the HD, and I still get the problem with the second HD 
 > as well. >  > Here's what happens: > G > * Enter name of drive holding the OpenVMS distribution media: DKA400:h5 > * Is the OpenVMS media ready to be mounted? [N] YESlJ > %SYSTEM-I-MOUNTVER, DKA200: is offline.  Mount verification in progress. > @ > Or, the system will properly mount the CD-ROM drive/media, andB > give me the DKA200: offline message while its extracting OpenVMS > library files, for instance. > D > Any suggestion of why this might be happening?  When it does, I've@ > waited for up to 20 minutes before giving up and rebooting the > box (via the power switch).  >  > Bill >  > --+ > +-------------------\ /-----------------+e+ > | Bill Bradford      |  www.sunhelp.org | + > | mrbill@mrbill.net  |   www.decvax.org |o+ > | Austin, Texas USA  |    www.pdp11.org | + > +-------------------/ \-----------------+e  M Several possibilities.  Invalid configuration/termination of the SCSI bus.  AhL bad disk drive.  Other possibilities, but those would be the first place I'd look.    What types of disks?  8 What are the SCSI IDs for each disk, and the controller?   How is the SCSI bus terminated?a   What type of VAX/Alpha?0   Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------   Date: 17 Jun 2000 16:40:55 GMT From: <anonymous@abc.com>w< Subject: Euro2000 football divination service and  more.....+ Message-ID: <8ig9mn$22dg$555@news.cz.js.cn>r       China five thousand year culture,be born I ching,the book of change,it be turn record china physics,mathematics,relativity and more universe algebraical basic knowledge,and provide in line with standard divination method.c  C    let your intuition  talking,chinese i-ching divination anything.t      About your future:t    I provided service: divination Fortune/Stock Exchange/Contract Signing/Partnership/Official/Sport Race/ Lawsuit / Weather/ Calamity   and more.....         http://iching.126.comn       Regards,
        lei   ------------------------------  % Date: Sat, 17 Jun 2000 20:43:18 -0500l, From: "Glenn C. Everhart" <Everhart@GCE.com>3 Subject: Re: Files-11 ODS-2 Readability for FreeBSD ' Message-ID: <394BE2E6.5D14AE37@GCE.com>   B The ods-2-reader.c and binaries that have been on the last severalB sigtapes runs in unix, reads ods-2 disks (even with long filenames? now). It lists directories or copies files, and knows enough to > copy ascii files and convert the common VMS types to something> unix can understand. Ditto the ods2.zip file on freeware or on= sigtapes, for reading ods-2 VMS disks under windows. There is @ also a filesystem for Linux which was on the sigtapes but I have@ not tried it. It appeared to have the record decoding stuff too.  9 Writing an ISO filesytem with mkisofs and putting it on a.< virtual disk (or copying the container to cd with cdwrite or cdrecord) works fine in VMS.  > While a filesystem for BSD might be nice, converting the LinuxA one would seem to offer a competing implementation, or just usinge6 one of the existing utilities would accomplish access.  A To be really useful, a filesystem of this kind needs considerable B special caching internally (from my experiences doing such a thing about 1994).   David J. Dachtera wrote: >  > mccrobie@my-deja.com wrote:r > >s1 > > In article <3946BC5F.D7481BF8@earthlink.net>,o> > >   "David J. Dachtera" <djesys.nospam@earthlink.net> wrote:! > > > mccrobie@my-deja.com wrote:,, > > > Can you write ISO-9660 on a hard disk? > >tF > > To a hard disk?  A couple of ideas come to mind.  Use some type ofL > > container file system available for both Unix and OpenVMS.  OpenVMS withK > > the LD driver shouldn't be a problem, although I haven't actually triedfF > > the LD driver with an ISO9660 container file - still, should work. > + > It does. I've used it with CD-ROM images.. >  > > UnixH > > would be the issue since "container file systems" seem to be a "new" > > idea there.a > D > It's called a "loop" device, I believe, and a LKM (loadable kernel! > module) is available for Linux.c > L > > Nothing in ISO9660, as far as I remember, prevents it from being written > > to a "raw" hard drive. >  > True.c >  > >2( > > UNIX:  mkisofs ... myisofile.iso9660/ > >        dd if=myisofile.iso9660 of=/dev/rda1. > >o6 > >        where rda1 eventually translates to DKB100:  > >              rda1 on FreeBSD& > >              rrz0c on Digital Unix > >A? > > OpenVMS:  mount /media=cd /noassist /system DKB100: cdlabel  > >3G > > If hard disk isn't your thing, then a CD-RW would do:  just blast aSE > > ISO9660 file system onto a CD-RW using a CD-writer.  CDRECORD and/J > > MKISOFS are available for both Unix and OpenVMS.  Use CD-RW so that it > > can be erased and reused.  > I > Well, sort of. Remember - most CD-ROM drives can't read CD-RW reliably.  >  > > Issues include:D' > >     File names from Unix -> OpenVMSU' > >     File attributse OpenVMS -> Unix2 > >11 > > but I would imagine such could be worked out.e > H > Yeah, well, that's the fly in the ointment. Remember: ODS is only halfH > (or less) of the equation. RMS is the "thingamabob that does the job", > record attributes wise.o >  > -- > David J. Dachtera  > dba DJE Systemso$ > http://home.earthlink.net/~djesys/ > < > Unofficial Affordable OpenVMS Home Page and Message Board:- > http://home.earthlink.net/~djesys/vms/soho/0   ------------------------------  % Date: Sun, 18 Jun 2000 04:24:06 +0200 & From: Bob Marcan <bob.marcan@aster.si>3 Subject: Re: Files-11 ODS-2 Readability for FreeBSD ( Message-ID: <394C32C6.3EF5F60C@aster.si>   Chuck McCrobie wrote:  >  > <sarcasm on> > E > Well, given the overwhelming response I've had so far, I doubt thisL- > product/project will make the light of day.S > H > Adding write support is far beyond the scope of what I planned to do -E > and I don't see any need for writing ODS-2 on FreeBSD to be read bylG > OpenVMS.  Why would you recommend adding write support?  Simply blast,G                                                            ^^^^^^^^^^^^,I > your data to a CD-RW in ISO9660 mode and have the VMS system read it...p  tG ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^e-       Doesn't this work to opposite side too?       J > There's lots of burner software available for FreeBSD and Windows NT andG > Macintosh and Digital Unix and ...  Then "erase" that CD-RW and blast0 > another image of data... > J > Perhaps a Windows NT/2000 installable file system driver would be betterJ > received...  Oh well, long live Microsoft - may Bill Gates get even more	 > richer!i > J > I suppose there's not much interest in software the extends the range ofG > OpenVMS systems.  After all, it may have held some incentive for some H > shops moving to Open Source to at least consider keeping their OpenVMS > systems around.  I guess? > the trend is to rid ourselves of all legacy systems and their  > "droppings". >  > <sarcasm off>  >   > Chuck McCrobie (** MAD VAX **) >  > "David J. Dachtera" wrote: > >7 > > mccrobie@my-deja.com wrote:  > > > M > > > I've been working on a READ-ONLY Files-11 ODS2 file system for FreeBSD. J > > > This file system is an installable kernel module and provides access< > > > to files as a "true" mountable file system on FreeBSD. > > >i > % > [ description of software snipped ]g >  > > K > > Well, for reasons which will become obvious when you check the links in F > > my sig., I would recommend either extremely low pricing or an Open > > Source release.l > >,E > > I would also recommend working on adding write capability as this K > > currently does not exist in any ODS-2 code (to my knowledge) outside of  > > the OpenVMS world. > >  > > -- > > David J. Dachtera0 > > dba DJE SystemsL& > > http://home.earthlink.net/~djesys/ > > > > > Unofficial Affordable OpenVMS Home Page and Message Board:/ > > http://home.earthlink.net/~djesys/vms/soho/    -- aA ----------------------------------------------------------------- @  Bob Marcan                         email:   bob.marcan@aster.si@  Aster                                tel:    +386 (61) 1894-329@  Nade Ovcakove 1                      fax:    +386 (61) 1894-201@  1000 Ljubljana, Slovenia                    http://www.aster.siA -----------------------------------------------------------------_   ------------------------------  % Date: Sat, 17 Jun 2000 11:56:22 -0700c5 From: "Larry D Bohan, Jr" <LBohan@dbc.spam_less..com>  Subject: Re: Fun VMS Facts?t2 Message-ID: <a8lLOW935UizyMkUGODvKOch=KUi@4ax.com>  0 On Wed, 14 Jun 2000 11:04:41 -0700, "Randy Park"& <rjpark@mindspring.com.nospaam> wrote:  : >From the early 1980s to 1998, Microsoft ran most of their7 >domestic order processing and accounts receivable on ar9 >cluster of VAXs using the Maxcim software package.  When : >they replaced it with SAP on Windows NT and SQL Server 7,5 >the number of people needed to support it tripled or  >quadrupled.  : I'd heard they had 14 TurboLasers (vms) at least one site.B for Internal finance apps, but also running Pathworks.  Go figure.   ------------------------------  % Date: Sat, 17 Jun 2000 23:37:24 -0400r* From: David A Froble <davef@tsoft-inc.com> Subject: Re: Fun VMS Facts? - Message-ID: <394C43F4.2F5A56F0@tsoft-inc.com>    David Mathog wrote:n > L > I'm not saying that there's not a plus side to OpenVMS, but IO performanceM > is so much worse than the competition that nobody in their right mind would K > buy one now for PC and small systems applications that were in any way IO-2 > intensive.   Ie, file serving, web serving, etc.  @ The reality of this is that you're running an application where:  3 Reliability of on-disk data is not a major concern,r  N You want your data to reside in memory as much as possible, re your remarks on
 Unix caching,   7 And you blame VMS for not doing it this way by default.n  L Well, besides the very hard fact that many VMS users consider reliability ofO data a major concern, and that many users are doing many different things, yourg, blaming VMS for all this is way out of line.  H First, you are using applications converted from Unix systems, that wereM probably written with Unix features in mind.  It's apparent that your idea of F porting this software is to do the minimum required to get it to run. 6 Defenitely no re-design to get it to use VMS features.  N Then, you know VMS does not have the type of file caching you desire, but evenI while knowing that, you dump on the file system and VMS as having bad I/O P performance, when the reality is that it just doesn't have the file caching thatP you want it to have.  This doesn't make it bad for everyone, just for the things you want, that it doesn't have.e  K I won't bother to describe an application where VMS will shine, and all the P other systems  fall kinda flat on their face.  Anyone who knows VMS capabilities( also knows that such applications exist.  M So, VMS doesn't have fast (and loose) file caching.  Some work in underway ine( this area.  Give it a break for a while.   Dave   --  4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  # Date: Sat, 17 Jun 2000 18:53:57 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)i6 Subject: RE: How do I calculate CONNECT TIME from DCL?0 Message-ID: <009EBBF4.541F59BD@SendSpamHere.ORG>  _ In article <1rePQ6zxM4VM@eisner.decus.org>, kaplow_r@eisner.decus.org.mars (Bob Kaplow) writes:  >In article <1137A4A23A51D311B2D600105A1D5213019AEEA8@seantexch.unitedad.com>, Terry Marosites <TMarosites@unitedad.com> writes:
 >{...snip...}  >> $Method_2@ >> $ PIPE ( SHOW PROCESS /ACCOUNTING /ID='F$GETJPI("","PID") | -) >>          SEARCH SYS$PIPE "connect" | -]K >>          ( READ SYS$PIPE $TMP$ ; DEFINE /JOB /NOLOG $TMP$ &$TMP$ ) ) ; -u >>        CONNECT_TIME == -pG >>     F$edit(F$trnlnm("$TMP$"),"TRIM,COMPRESS") - "Connect time: " ; -, >>        DEASSIGN /JOB $TMP$:! >> $ CONNECT_TIME == CONNECT_TIME0 >uJ >Well, yea. Something like this was my last resort. I'll see if I can talkG >folks into leting me install SYMBOL. If not, I may be stuck with this., >rK >BTW, I've only spent about 2 minutes playing with this, and it worked finerI >for my process, but I couldn't get the syntax right to specify the first I >parameter for the f$getjpi to look at another process. Just sticking therK >process number, or a symbol with the value, inside the quotes didn't work.aB >I'll post the error message when I get back to the office Monday.    7 Substitute P1 for the "" in the 'F$GETJPI("","PID") | -   L Then execute the procedure specifying the PID of the desired target process.K You do need to possess certain privies to do so, but then I'm sure you know  that!    --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMi   ------------------------------   Date: 17 Jun 2000 14:49 CST5' From: carl@gerg.tamu.edu (Carl Perkins)t6 Subject: Re: How do I calculate CONNECT TIME from DCL?- Message-ID: <17JUN200014490510@gerg.tamu.edu>   5 kaplow_r@eisner.decus.org.mars (Bob Kaplow) writes... 1 }I'm looking for a way in DCL to get connect timet
 }	Bob Kaplow	c  L The following only works up to 24 hours (after which it just says "more thanK 24 hours", but could be modified to remove that limitation without too much  difficulty.,  $ $ login_dt = F$GetJPI("","LOGINTIM")3 $ login_time = F$CVTime(login_dt,"ABSOLUTE","TIME")r1 $ login_day = F$CVTime(login_dt,"ABSOLUTE","DAY")n* $ now = F$CVTime("","ABSOLUTE","DATETIME")/ $ current_time= F$CVTime(now,"ABSOLUTE","TIME")a. $ current_day = f$CVTime(now,"ABSOLUTE","DAY")  $ If current_day .EQS. login_day $ ThenG $   connect_time = F$CVTIME("''now'-0-''login_time'","ABSOLUTE","TIME")d $ ElseD $   If (F$Integer(current_day) - F$Integer(login_day) .GT. 1) .OR. -L        (F$CVtime("''now'-0-''login_time'","ABSOLUTE","DAY") .NES. login_day) $   Then) $     connect_time = "more than 24 hours"r $   ElseA $     tmp1 = F$CVTIME("''now'-0-''login_time'","ABSOLUTE","TIME") F $     tmp2 = F$CVTIME("''login_dt'-0-''login_time'","ABSOLUTE","TIME")D $     connect_time = F$CVTIME("''tmp1'-0-''tmp2'","ABSOLUTE","TIME")	 $   EndIfe $ EndIf  $ write sys$output connect_timeo   --- Carl   ------------------------------   Date: 17 Jun 2000 17:34 CST-' From: carl@gerg.tamu.edu (Carl Perkins)v6 Subject: Re: How do I calculate CONNECT TIME from DCL?- Message-ID: <17JUN200017344530@gerg.tamu.edu>g  + carl@gerg.tamu.edu (Carl Perkins) writes...i6 }kaplow_r@eisner.decus.org.mars (Bob Kaplow) writes...2 }}I'm looking for a way in DCL to get connect time }}	Bob Kaplow	 } M }The following only works up to 24 hours (after which it just says "more thanhL }24 hours", but could be modified to remove that limitation without too much }difficulty. [...]u   Replying to my own post...  D OK. I said that when I originally posted that. So I went and did it.  D (As an added bonus, you get a subroutine that calculates the modifed julian day.)  J Here's a version that should work with pretty much any valid VMS date-timeG for the login and current time, up to a login time on 17-nov-1858 and ah7 curent time on 31-dec-9999 (I think it should, anyway).    $! connect_time.comv $! Calculate time since login.% $! Created: 17-Jun-2000, Carl Perkins  $!M $! Subroutine MJD calculates the modified julian day (days since 17-Nov-1858, > $! which is - not exactly coincidentally - the VMS base date). $MJD: Subroutine
 $ jddate = p1-* $ jdy = F$CVTime(jddate,"ABSOLUTE","YEAR")- $ jdm = F$CVTime(jddate,"COMPARISON","MONTH") ) $ jdd = F$CVTime(jddate,"ABSOLUTE","DAY")< $ jdy = jdy + 8000 $ If jdm .LT. 3s $ Then $   jdy = jdy-1u $   jdm = jdm+12 $ EndIF O $ mjday == (jdy*365)+(jdy/4)-(jdy/100)+(jdy/400)-3600821+(jdm*153+3)/5-92+jdd-1e $ Exit' $ EndSubtoutine ! end of MJD subtoutine  $!$ $ login_dt = F$GetJPI("","LOGINTIM")3 $ login_time = F$CVTime(login_dt,"ABSOLUTE","TIME"). $ Call MJD "''login_dt'" $ login_mjd = mjdayw* $ now = F$CVTime("","ABSOLUTE","DATETIME") $ Call MJD "''now'"  $ current_mjd = mjdayo  $ If current_mjd .EQS. login_mjd $ Then ! use shortcuteO $   connect_time = "0000-"+F$CVTIME("''now'-0-''login_time'","ABSOLUTE","TIME")f# $ Else ! calculate the whole schmoo." $   days = current_mjd - login_mjd@ $   login_hour = F$Integer(F$CVTime(login_dt,"ABSOLUTE","HOUR"))= $   current_hour = F$Integer(F$CVTime(now,"ABSOLUTE","HOUR"))a& $   hours = 24+current_hour-login_hourA $   login_min = F$Integer(F$CVTime(login_dt,"ABSOLUTE","MINUTE"))e> $   current_min = F$Integer(F$CVTime(now,"ABSOLUTE","MINUTE"))& $   minutes = 60+current_min-login_minB $   login_sec = F$Integer(F$CVTime(login_dt,"ABSOLUTE","SECONDS"))? $   current_sec = F$Integer(F$CVTime(now,"ABSOLUTE","SECONDS"))t& $   seconds = 60+current_sec-login_sec $   If (seconds .GE. 60) $   Then $     minutes = minutes+1t $     seconds = seconds-60	 $   EndIf  $   If (minutes .GE. 60) $   Then $     hours = hours+1  $     minutes = minutes-60	 $   EndIf  $   If (hours .GE. 24) $   Then $     days= days+1 $     hours = hours-24	 $   EndIf? $   If (days .LE. 9999)e $   ThenL $     connect_time = F$FAO("!4ZL-!2ZL:!2ZL:!2ZL",days,hours,minutes,seconds) $   ElseK $     connect_time = F$FAO("!ZL-!2ZL:!2ZL:!2ZL",days,hours,minutes,seconds)g	 $   EndIF  $ EndIF  $ write sys$output connect_timeo   --- Carl   ------------------------------  % Date: Sat, 17 Jun 2000 10:42:56 -0600 ) From: "Nick Ulrich" <njulrich@micron.com>yG Subject: Installing OpenVMS on VAX 3100 30/40: System Password problems.0 Message-ID: <8ig9qh$72h$1@admin-srv3.micron.com>  ( My knowledge is very limited so be kind:  J I am installing OpenVMS7.2 on a VAX 3100 30/40.  I have backed up VMS072.BK on the intended system disk DKA0:.  This went well without problem.  I have F now rebooted the system with the system disk, the system installed allG specified files which went well. I am now asked to set the password forv< SYSTEM.  When I type the password in I am getting the error:  -     %UAF-E-PWDSYNTAX, invalid password syntaxa;     %VMS-I-PWD_SET, primary password for account SYSTEM sete  @     New password not secure. Please select a different password.   The passwords I have tried are:G
     asdfghjklt     q1w2e3r4     qsxcfthc  > But I am getting the same error every time... Any suggestions?   Thanks in advance:   Nick Ulriche? Email Address (Take out the x in the com): njulrich@micron.xcomr   ------------------------------  % Date: Sat, 17 Jun 2000 18:51:55 -0500r7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>iK Subject: Re: Installing OpenVMS on VAX 3100 30/40: System Password problemst- Message-ID: <394C0F1B.43ACB6AF@earthlink.net>s   Nick Ulrich wrote: [snip]6 >  When I type the password in I am getting the error: > / >     %UAF-E-PWDSYNTAX, invalid password syntaxa= >     %VMS-I-PWD_SET, primary password for account SYSTEM setO > B >     New password not secure. Please select a different password.  D I'm guessing here, but may take is that the underlying proceedure isH simply sensitive to the failure of AUTHORIZE to change the password, nad! perhaps not the exact error code.n  ! > The passwords I have tried are:  >     asdfghjklc >     q1w2e3r4
 >     qsxcfthy > @ > But I am getting the same error every time... Any suggestions?  ? In my experience, this can come from an invalid line terminator @ character. I'd be curious to know what you're using as a consoleC terminal. Whatever it is, make sure that the RETURN (or main keypadJG ENTER) key is sending a <CR> (ASCII 13, %X0D) and not a <LF> (ASCII 10,cF %X0A) or <LF><CR> or <CR><LF> pair. I've found this to produce results ranging from annoying to dire.   -- m 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: Sat, 17 Jun 2000 11:46:38 -0700 * From: "Jack Peacock" <peacock@simconv.com>7 Subject: Re: OpenVMS clusters vs other systems clusterse< Message-ID: <JIP25.1147$v7.76016@news-west.usenetserver.com>  6 "Main, Kerry" <Kerry.Main@compaq.com> wrote in messageD news:910612C07BCAD1119AF40000F86AF0D805284412@kaoexc4.kao.dec.com... > Jack,e >bF > While this Techwise report shows OpenVMS continuing to be the leader inC > clustering compared to UNIX offerings, Tru64 UNIX is also winningf analyste@ > recognition as one of the leaders when just UNIX offerings are	 compared.D >0G The significance is that Compaq used VMS and not Tru64 in the study fornG comparison.  In nearly all Compaq advertising Tru64 is shown first, VMS B rarely or not at all, yet when it came to the big dollar potentialD customers they had to go back to VMS.  This seems to be inconsistent with their marketing of Tru64.  B I don't use Tru64.  We are migrating from VMS to NT, following theD customers, but I still maintain a few VMS clusters.  No customer hasG ever asked about Unix on Alpha.  I'm sure it's a good operating system,mG it's been around long enough to get the major bugs out.  However, I get H the impression there are no outstanding features vis a vis HP or Sun, at  least as far as clustering goes.  F My guess is, if it were to replace VMS in the study it would have beenG no better than average, which is why the report has VMS instead.  Tru64c< clustering doesn't have the learning curve advantage of VMS.    Jack Peacocki   ------------------------------  % Date: Sat, 17 Jun 2000 16:10:55 -0400.' From: "Bill Todd" <billtodd@foo.mv.com>-7 Subject: Re: OpenVMS clusters vs other systems clusters ( Message-ID: <8iglp9$7vg$1@pyrite.mv.net>  3 Jack Peacock <peacock@simconv.com> wrote in messages6 news:JIP25.1147$v7.76016@news-west.usenetserver.com...8 > "Main, Kerry" <Kerry.Main@compaq.com> wrote in messageF > news:910612C07BCAD1119AF40000F86AF0D805284412@kaoexc4.kao.dec.com...	 > > Jack,  > >yH > > While this Techwise report shows OpenVMS continuing to be the leader > inE > > clustering compared to UNIX offerings, Tru64 UNIX is also winningl	 > analyst.B > > recognition as one of the leaders when just UNIX offerings are > compared.  > > I > The significance is that Compaq used VMS and not Tru64 in the study for I > comparison.  In nearly all Compaq advertising Tru64 is shown first, VMS^D > rarely or not at all, yet when it came to the big dollar potentialF > customers they had to go back to VMS.  This seems to be inconsistent  > with their marketing of Tru64.  I Just as inconsistent today as it has been for most of the last decade, in0 other words.  J There's no indication yet that the trumpeted VMS 'Renaissance' is any moreJ than just some ratcheted-up promotion based on recognizing that VMS reallyJ is not going to go away any time soon so they might as well make some moreF money on it while they can - as long as it doesn't upset the corporateK stance (that one must assume is based on internal corporate politics, since I it certainly bears little relation to reality) that NT and Unix are theirtH first-tier offerings with VMS there to take up the slack when they can't' sell you a high-priced Tandem solution.D   - bill   > D > I don't use Tru64.  We are migrating from VMS to NT, following theF > customers, but I still maintain a few VMS clusters.  No customer hasI > ever asked about Unix on Alpha.  I'm sure it's a good operating system,oI > it's been around long enough to get the major bugs out.  However, I get J > the impression there are no outstanding features vis a vis HP or Sun, at" > least as far as clustering goes. >yH > My guess is, if it were to replace VMS in the study it would have beenI > no better than average, which is why the report has VMS instead.  Tru64d> > clustering doesn't have the learning curve advantage of VMS. >    Jack PeacockD >  >e >o   ------------------------------  % Date: Sat, 17 Jun 2000 22:09:16 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>h7 Subject: Re: OpenVMS clusters vs other systems clustersl, Message-ID: <394C2F45.BAD6D89C@videotron.ca>   Larry Kilgallen wrote:C > I doubt that you will find Compaq funding such a study for public-D > release.  The only "good" result possible from a Compaq standpointC > is one that measured Tru64 and VMS as absolutely identical, since69 > otherwise one departement or another would be offended.   D The Montreal Compaq office has said a few times that Tru64's currentM clustering capabilities now include ALL the functionality that was present in-) openVMS (past tense is theirs, not mine).e  M I do not know if that is really true or not. If it is true, it means that anysN vendor can develop clustering technology that rivals VMS in a very short time.   ------------------------------  % Date: Sat, 17 Jun 2000 23:46:10 -0400d* From: David A Froble <davef@tsoft-inc.com>7 Subject: Re: OpenVMS clusters vs other systems clustersr- Message-ID: <394C4602.FB73A100@tsoft-inc.com>c   JF Mezei wrote:g >  > Larry Kilgallen wrote:E > > I doubt that you will find Compaq funding such a study for publiceF > > release.  The only "good" result possible from a Compaq standpointE > > is one that measured Tru64 and VMS as absolutely identical, sincen; > > otherwise one departement or another would be offended.- > F > The Montreal Compaq office has said a few times that Tru64's currentO > clustering capabilities now include ALL the functionality that was present in4+ > openVMS (past tense is theirs, not mine).w > O > I do not know if that is really true or not. If it is true, it means that anynP > vendor can develop clustering technology that rivals VMS in a very short time.  N 1) Not, I do not believe it's true.  I'm pretty sure thay cannot run clusteredH machines 500 km, or whatever the maximum distance is, apart.  Don't know( details, but I bet there's more missing.  K 2) What other vendor, other than MS, will be handed the DLM and other code,t& running natively on the CPU of choice?  ( I'm sure more can be added to this list.  L However, maybe they are playing with words.  I could say that MS-DOS has theK same cluster capabilities as VMS. Of course the 'had' will mean I'm talking K about pre-V4 or thereabouts VMS.  In both cases those same capabilities arehN none.  Surely by now you carry around a 50 pound block of salt when talking to	 salesmen.a   Dave   -- y4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Sat, 17 Jun 2000 12:27:56 -0700o5 From: "Larry D Bohan, Jr" <LBohan@dbc.spam_less..com>e, Subject: Pathworks ( AS v7.2a) vs MSDEV VC++2 Message-ID: <Es9LOY22qAYL4Ww8gQUNryccc3R0@4ax.com>  6 Does anyone here, have users using the MSDEV VC++ IDE @ (any one of v4.x, 5.x, 6.x) on/against source files residing on ) Pathwork shares, (AS v7.2 in particular).   F If can I find out that at least *one* site is doing this sucessfully, ; then I can figure on a configuration problem of some sort.    8 But I'd rather not chase it down, until I know it's not - the MSDEV VC++ at fault.  (it looks that way)   5 I've quite a few things/angles that I've tried so far  if this interests anyone.a   ------------------------------  % Date: Sun, 18 Jun 2000 08:40:02 +0900 2 From: Mike Rechtman <michael.rechtman@digital.com>" Subject: Re: Q: Maintainance mode?+ Message-ID: <394C8AE2.343289E2@digital.com>a   Georg Brein wrote: >  > Hi,  >  <...snip...>F > That's my problem: I do not have a password (neither normal user norI > SYSTEM); the company I got the machine from switched it on for the last.A > time three years ago, and all passwords they remembered proofed. > incorrect. > D > Is there a way to enter a VMS system via something like the systemR > maintainance mode of *ix systems (I solved a similar problem with a <...snip...>  , 1. Look for the VMS FAQ - one possibility is# http://eisner.decus.org/faq/faq.htm)  ; 2. Go to topic MGMT5: I've forgotten the SYSTEM password...    3. Follow the instructions  
 Best of luck,& ~Mike    --  E ---------------------------------------------------------------------PE Usual disclaimer: All opinions are mine alone, perhaps not even that.N? Mike Rechtman                            *rechtman@tzora.co.il*aF Kibbutz Tzor'a.                          Voice (home): 972-2-9908337  B   "20% of a job takes 80% of the time, the rest takes another 80%"E ---------------------------------------------------------------------s   ------------------------------  % Date: Sat, 17 Jun 2000 14:45:00 -0400r" From: Dan Sugalski <dan@sidhe.org>H Subject: Re: Storage Works / Snapshots / Maybe it's time to skip OpenVMS: Message-ID: <4.3.2.7.0.20000617144256.00bbb650@24.8.96.48>  * At 04:30 PM 6/16/00 -0400, Hal Kuff wrote:    8 >    IS there any kind of snapshot supported by OpenVMS?G >    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 be 3 >scripted and run several times per day unattended.r  L What kind of snapshots? If you're just talking about cloning disks, you can L do that now and have been able to for ages. Either use the CLONE support in K the HSx controllers to snapshot individual drives or, for RAID volumes and 0K such, make and break shadow sets. Rebuilds on the shadow sets are a bit of I a pain, but it works.      					Dan  I --------------------------------------"it's like this"-------------------w2 Dan Sugalski                          even samurai? dan@sidhe.org                         have teddy bears and eveny;                                       teddy bears get drunkC   ------------------------------  % Date: Sat, 17 Jun 2000 15:42:27 -0400T  From: kuff@tessco.com (Hal Kuff)H Subject: Re: Storage Works / Snapshots / Maybe it's time to skip OpenVMSO Message-ID: <05E9483E465FF40C.DBE5A72396AEDFFB.0693B6D86E224ECB@lp.airnews.net>   E    What we're looking for is a snapahot via command files or API thatME allows us to only take users offline for 5 mins.... cloning a striped.F mirrorset would defeat the purpose....  Adding mirrors and taking themG away to convert them to units for mounting would be clumsy and probably  unscriptable      G In article <4.3.2.7.0.20000617144256.00bbb650@24.8.96.48>, Dan SugalskiT <dan@sidhe.org> wrote:  , > At 04:30 PM 6/16/00 -0400, Hal Kuff wrote: >  > : > >    IS there any kind of snapshot supported by OpenVMS?I > >    We'd sure like to buy about $200,000 worth of new Storage, but the-K > >ability to do snapshots from OpenVMS is not negotiable. This needs to bei5 > >scripted and run several times per day unattended.  > N > What kind of snapshots? If you're just talking about cloning disks, you can N > do that now and have been able to for ages. Either use the CLONE support in M > the HSx controllers to snapshot individual drives or, for RAID volumes and gM > such, make and break shadow sets. Rebuilds on the shadow sets are a bit of u > a pain, but it works.m >  > - >                                         Dan. > K > --------------------------------------"it's like this"-------------------.4 > Dan Sugalski                          even samuraiA > dan@sidhe.org                         have teddy bears and evenv= >                                       teddy bears get drunke   ------------------------------  + Date: Sat, 17 Jun 2000 14:00:48 -0600 (MDT)t) From: John Nebel <nebel@athena.csdco.com>yH Subject: Re: Storage Works / Snapshots / Maybe it's time to skip OpenVMSG Message-ID: <Pine.OSF.4.21.0006171352050.31516-100000@athena.csdco.com>e  J Check the 7.3 enhancements to volume shadowing!  Write bitmap will make it4 a lot faster to bring a disk back into a shadow set.  
 John Nebel    ( On Sat, 17 Jun 2000, Dan Sugalski wrote:  , > At 04:30 PM 6/16/00 -0400, Hal Kuff wrote: >  > : > >    IS there any kind of snapshot supported by OpenVMS?I > >    We'd sure like to buy about $200,000 worth of new Storage, but the6K > >ability to do snapshots from OpenVMS is not negotiable. This needs to beS5 > >scripted and run several times per day unattended.G > N > What kind of snapshots? If you're just talking about cloning disks, you can N > do that now and have been able to for ages. Either use the CLONE support in M > the HSx controllers to snapshot individual drives or, for RAID volumes and mM > such, make and break shadow sets. Rebuilds on the shadow sets are a bit of i > a pain, but it works." >  > 
 > 					Dan > K > --------------------------------------"it's like this"-------------------g4 > Dan Sugalski                          even samuraiA > dan@sidhe.org                         have teddy bears and evenc= >                                       teddy bears get drunkn >  >  >  >    ------------------------------  % Date: Sat, 17 Jun 2000 16:16:03 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> H Subject: Re: Storage Works / Snapshots / Maybe it's time to skip OpenVMS( Message-ID: <8igm2t$7vu$1@pyrite.mv.net>  - Dan Sugalski <dan@sidhe.org> wrote in messagen4 news:4.3.2.7.0.20000617144256.00bbb650@24.8.96.48..., > At 04:30 PM 6/16/00 -0400, Hal Kuff wrote: >n > : > >    IS there any kind of snapshot supported by OpenVMS?I > >    We'd sure like to buy about $200,000 worth of new Storage, but the K > >ability to do snapshots from OpenVMS is not negotiable. This needs to be95 > >scripted and run several times per day unattended.L >ZI > What kind of snapshots? If you're just talking about cloning disks, you2 canZJ > do that now and have been able to for ages. Either use the CLONE support inL > the HSx controllers to snapshot individual drives or, for RAID volumes andL > such, make and break shadow sets. Rebuilds on the shadow sets are a bit of > a pain, but it works.3  H Yes, but it sounds as if it would likely add $100,000 to the cost of the@ system ($200,000 if the storage wasn't additionally mirrored forK availability while the snapshot was being taken).  That's kind of expensivetB compared to any reasonable price for software snapshot capability.   - bill   >e >s > Danh >eK > --------------------------------------"it's like this"------------------- 4 > Dan Sugalski                          even samuraiA > dan@sidhe.org                         have teddy bears and even = >                                       teddy bears get drunkf >a >u   ------------------------------  % Date: Sat, 17 Jun 2000 16:42:58 -0500s, From: "Glenn C. Everhart" <Everhart@GCE.com>H Subject: Re: Storage Works / Snapshots / Maybe it's time to skip OpenVMS' Message-ID: <394BAA92.75BB61E3@GCE.com>s  H Suppose you build a virt disk driver that initially reads all blocks off: some disk or file, but which keeps a "modified" bitmap (or? other structure) such that writes go to some other r/w storage.e; The initial disk never changes, is in effect your snapshot.nC The written stuff would have to record where it came from and wouldCA need to be addressable quickly (for the thing to be usable). Thist@ can be cobbled together using already published vms virtual disk@ drivers as starting points. In fact one could in principle layer a few of them together.   @ Existing drivers would produce new devices of course. To make an> existing disk look like this, one would have to steal start-io@ (and watch out lest some disk drivers invalidate that particular: intercept, as dkdriver did between alpha vms 6.2 and 7.1).> Alternatively one could build a switch into an existing driver> to start/stop letting everything thru untouched. That at least( would not be subject to VMS driver mods.  B The question I have about it is how interesting this is to anyone.; To my mind it would be a way to treat VMS CDs as read/writet< devices, or perhaps to update compressed readonly disks, but7 begins to get convoluted with no obvious pressing need.S# Is the notion worth bothering with?F Glenn Everhart     Hal Kuff wrote:s > G >    What we're looking for is a snapahot via command files or API thattG > allows us to only take users offline for 5 mins.... cloning a striped H > mirrorset would defeat the purpose....  Adding mirrors and taking themI > away to convert them to units for mounting would be clumsy and probably  > unscriptable > I > In article <4.3.2.7.0.20000617144256.00bbb650@24.8.96.48>, Dan Sugalskiu > <dan@sidhe.org> wrote: > . > > At 04:30 PM 6/16/00 -0400, Hal Kuff wrote: > >y > >r< > > >    IS there any kind of snapshot supported by OpenVMS?K > > >    We'd sure like to buy about $200,000 worth of new Storage, but thewM > > >ability to do snapshots from OpenVMS is not negotiable. This needs to be 7 > > >scripted and run several times per day unattended.  > >oO > > What kind of snapshots? If you're just talking about cloning disks, you caniO > > do that now and have been able to for ages. Either use the CLONE support inIN > > the HSx controllers to snapshot individual drives or, for RAID volumes andN > > such, make and break shadow sets. Rebuilds on the shadow sets are a bit of > > a pain, but it works.o > >e > >i/ > >                                         Dan. > >aM > > --------------------------------------"it's like this"-------------------e6 > > Dan Sugalski                          even samuraiC > > dan@sidhe.org                         have teddy bears and evenl? > >                                       teddy bears get drunks   ------------------------------  % Date: Sat, 17 Jun 2000 17:05:21 -0400r* From: David A Froble <davef@tsoft-inc.com> Subject: Re: VAX on Intel?- Message-ID: <394BE811.D450F7BB@tsoft-inc.com>    "David J. Dachtera" wrote: >  > Larry Kilgallen wrote: > >nk > > In article <39498CB2.6C9BD0D1@earthlink.net>, "David J. Dachtera" <djesys.nospam@earthlink.net> writes:, > >uJ > > > For example: how would YOU go about expanding the OpenVMS user base? > > >VH > > > ...or is it that you are not convinced that it SHOULD be expanded? > >>E > > As with Macintosh, I am convinced that one of the major strengths4D > > of VMS is tight integration with the hardware and the ability of+ > > the OS group to influence the hardware.7 > = > This, however, increases hardware costs and keeps OpenVMS's H > cost-effectiveness in the unfavorable range. Note that most MACs todayJ > use common VGA-type monitors, "standard" SCSI devices, and focus less onE > proprietary network protocols and media and more on UTP and TCP/IP.X >  > > I believe that throwing , > > that away is to lessen the value of VMS, > F > Obviously, I disagree. In the first place, no one is "throwing away"E > anything. What this would actually do is to put OpenVMS on a "leveleH > playing field" with other o.s.-es which are more tolerant of "diverse" > hardware.   L Ok, now you hit a sensitive nerve.  What direction would VMS be moving to beK level with other operating systems running on intel hardware?  Sure as hellcF isn't 'up'.  (Using 'up' as a 'positive' for performance, reliability,D scalability, etc.)  I also don't think it involves VMS pulling otherH environments up a bit.  No, you've got to be talking about lowest commonO denominator bullshit.  Hate to have to break this to you, but the lowest commono- denominator is still the cave.  No thank you!o  @ > Strange that diversity among the work-force is viewed as good,   You said that!  H > while diversity in the technical world is viewed as bad. Being able toI > sucessfully use more third-party hardware with OpenVMS systems can only H > help expand the user/installed base, while at the same time preserving0 > the level of quality we've all come to expect.  # And there sadly is a contridiction.I    That is, expect aJ > high-quality device, but do not reject something which "plays nice" mostG > of the time, and let the user be responsible for the results of usinga > lower quality gear.e  P That happens now.  What you must be complaining about is when the responsibilityL comes home to roost.  I'm using VMS 7.2 and 7.2-1, and I haven't yet found aK (working) drive I cannot use.  Can't say I've tried them all, but that's mye1 experiences.  These are cheap third party drives.-  O Now, if you're complaining about older versions of VMS not handling drives thatfO were not designed when that version of VMS was released,  I suggest you also gotL get a mid 1980s version of mess-doss and try a new 20 GB EIDE drive.  And ifL you're complaining about older DEC systems, then also try an original IBM PC with the 20 GB drive.u   >  > > and I am not interestedtB > > in approaches that widen the interest in VMS at the expense of > > decreasing the quality.n > J > In what way would increasing the user/installed base in any way threaten
 > quality? > F > > Widening the VMS user base is a great goal, but should not be done) > > at the expense of existing strengths.e >  > Same question again... >  > > Personally, I would suggest E > > they go for a "quality" approach, but that might be attributed toy= > > my fantasy that the world will give up on trash products.- > E > Agreed. However, quality can no more be "legislated" than morality.a >@F > > Of course for Marketing the appropriate characteristic is "in yourC > > face", and "remember the brand", so that means I do not want my G > > all-time favorite commercial spokesman (Stan Freberg) pitching VMS.n > H > Actually, marketing can simply mean sufficient repetition to embed the
 > message.   Now you're getting somewhere!d  4 > Here's a classic example - complete this sentence: > : > "Winston taste good like a ______________  ___________." > G > That ad has been off the air for almost thirty years; yet, I'll bet agI > good portion of the US folks on the newsgroup were able to complete then# > sentence almost without thinking.w   You definitely win on this one.a   -- e4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  # Date: Sat, 17 Jun 2000 21:10:55 GMTt& From: Wolfgang Rupp <wolfgang@rupp.nu> Subject: Re: VAX on Intel?3 Message-ID: <zPR25.78324$yR.1363520@news.chello.at>   5 In comp.os.vms Bill Todd <billtodd@foo.mv.com> wrote:lF > To me, this suggests that expansion of the VMS user base (which I doL > consider a desirable goal, and suspect Larry does as well) is not going toL > come via the route you're advocating - at least not in the present climateJ > and with VMS's present (lack of) industry visibility and acceptance.  WeK > should be thankful that it's possible to purchase a new (DS10) VMS system I > for $5000 - $6500 (depending on options), which puts it well within the F > range of any small business that needs VMS, and look to other marketH > segments (all of which offer greater margins and profit potential) for > expansion opportunities.  I I think there is a much overlooked fact in this "expanding VMS user base" F discussion. I've followed many of these threads for some time, but oneH thing was _never_ mentioned: the awareness about VMS within the decisionG making IT management. Take me for example. During my brief stunt at uni G I got into contact with VMS in a Pascal programming course. This course F could have happened on PC also, and in fact we were allowed to hack at) home. Fast forward ten years (i.e. 1999).'  I The next contact with VMS came through my first own VAX - through peronal G interest in collecting and using old hardware. I played around with VMS H because of a) the acclaimed stability, b) it was on the box and c) I wasJ curious. I got my hobbyist license. Several more VAXen and a PDP followed.F This can't be typical, and no company should count it. Had it not beenF for personal (hardware) interest, I'd never given VMS a try. CertainlyF not because of convincing marketing attempts from DEC or later Compaq.  G At my present job I have to develop network and server standards for a .H group with multinational locations. We use ERP software from one of the K well known vendors. Before, I worked for that vendor. When I mentioned VMS,yE I got blank looks. People just did not know it. Of course, like it's tC competitors, the software does not run on VMS. You get versions forp9 different Unices, NT and OS/390. Nobody thinks about VMS.'  I Since the business _really_ depends on zero downtime, VMS might have been K worth a consideration for me... BUT: first showstopper is the ERP software,-G or rather it's lack of VMS support, the second showstopper would be thenH lack of even basic VMS awareness within the company brass, and then lack# of VMS-knowledgeable IT personell.    ; It seems that there would be three important steps to take: 6 a) raise the awareness about the system's capabilities' b) get mission-critical software ported-F  (which is easier when RealBigCorps demand it, needs Problem a solved)6 c) interest "normal" IT people in VMS and VMS training   Comments, please...e  
 Wolfgang Rupps   ------------------------------  % Date: Sat, 17 Jun 2000 17:25:20 -05000, From: "Glenn C. Everhart" <Everhart@GCE.com> Subject: Re: VAX on Intel?' Message-ID: <394BB480.112E07E0@GCE.com>b   Bill Todd wrote: [...]l > M > And VMS has been dragged, kicking and protesting that DECnet was a superiorfM > interconnect protocol, into support for TCP/IP (though bundling it with theeI > base system - as other low-end systems do - would help the low-end costo	 > issue).d  = My recollection of this is rather different. DEC was informedr< by various governments that TCP/IP would be dropped from the= Internet as the IMP protocol had before it and that OSI wouldk: take over. Therefore it went and implemented OSI, awaiting: the promised government action, which never came. Its UCX < offering was expected to be a stopgap, which led at least in9 part to its not being done very carefully and to Multinet  eating its lunch.   7 The characterization of VMS being dragged... is at best ; uncharitable. DEC got snookered by the governments involved-; though it did its best to be ready for the Next Great Thingc that was forecast.  : There were many who considered OSI to be shaping up as the7 Next Great Turkey instead (for the foreigners: domestic09 turkeys have been known to drown in the rain because theyo< are looking up and aren't smart enough to lower their heads,9 hence the slang usage for something inept and ill adaptedi> to its environment).  Nevertheless, the OSI hype continued for= several years and appeared serious in at least some quarters.y8 It is at least ungenerous to take VMS to task for having) believed and built an OSI implementation.g   ------------------------------  % Date: Sat, 17 Jun 2000 17:40:14 -0500t7 From: "David J. Dachtera" <djesys.nospam@earthlink.net>d Subject: Re: VAX on Intel?- Message-ID: <394BFE4E.C917D722@earthlink.net>a   Bill Todd wrote: [snip]N > Larry's point, however, is valid:  the fact that a much higher percentage ofN > the hardware found on typical VMS systems is supported directly (or at leastJ > thoroughly qualified) by VMS engineering than the percentage of hardwareG > found on typical Wintel systems supported/qualified by MS engineeringsK > contributes significantly to the relative stability of those VMS systems,sL > and (though probably to a lesser extent) the ability of VMS engineering toK > influence hardware development contributes to that hardware's quality and- > compatibility.  F On the other hand, all the "other o.s.-es" really try to do is put theC data into the drive's buffer (we ARE talking about SCSI disk drive,eB right?) and issue a write command and see that the write operation; returns a success status. That's all ANYone really expects.   ,L > Whether there's any significant value (under current conditions) to makingG > VMS systems cost-competitive with Windows systems - especially on theS > desktop - is debatable:1  6 ...however unecessary that debate may be (read on),...  6 >  due to lack of familiar applications, familiar userK > interface, and availability of support personnel, VMS is not currently in K > any position to compete effectively on the desktop, and arguably not in aHH > good position to compete as a 'commodity' (low-end) back-end server to> > Windows desktops (Pathworks improvements could help there),   E ...let's not forget Samba, and the NFS functions available in most oftH the third party TCP/IP stacks currently available (current only MultinetG and TCPware, both from Process Software, which has itself fallen victimg% to the corporate take-over frenzy)...e  	 > but its  > strengths (and e   ...debatably...   ! > *reasonable*, even if not equal   ! ...correction: greatly unequal...s   > , cost) make it a viableE > option in any situation where those weaknesses are less applicable.  > J > Cost-reduction is always desirable.  But when it requires heroic effortsJ > (and an IA port certainly meets that description), those efforts must beM > justified by the anticipated gains.  That's (IMO) really hard to do at this  > point in time.  B I've said it before, and I'll say it again (and again and again...E however many times it takes to get someone to listen and understand):mF there are some 450,000 VMS machines in the world vs. 200+ million IA16F and IA32 (IA64 is, as yet, still vaporware in the marketplace), not toG mention the Alphas that face the possibility of being scrapped with the0A demise of Alpha/NT. How much more justification does anyone need?,  l > >  > > > I believe that throwing . > > > that away is to lessen the value of VMS, > >'H > > Obviously, I disagree. In the first place, no one is "throwing away"G > > anything. What this would actually do is to put OpenVMS on a "levelsJ > > playing field" with other o.s.-es which are more tolerant of "diverse"L > > hardware. Strange that diversity among the work-force is viewed as good,< > > while diversity in the technical world is viewed as bad. > L > The main reason people have for viewing technical diversity as bad (to theN > extent that this is true) is that systems don't generally play all that well  A True. However, for our purposes, I think we're talking more about$F peripherals than entire systems. The business world has, IMO, seen theH error of its "buy the app. you need regardless of what it runs on" ways:C down-time and increased costs due to incompatible and non"standard"rF systems and communication protocols. Nowadays, everyone's enamoured ofG "point and click" and "web based" systems (thanx - for nothing, Bill!).s  8 > [snip]  If people want an alternative, they've alreadyI > got Linux and other free (and not free) Unixes, which enjoy far greater J > application availability and user and support familiarity than VMS does:  = A situation which VMS and can view as either a handicap or anr3 opportunity. I choose to view it as an opportunity./  K > VMS would have difficulty being noticed by anyone except those people whoEL > are already sufficiently motivated to use it that they likely already have > it.o  D ...which is why we gotta push app. development which is why we gottaE push "affordable". Get it? Folks won't develop for system that no onevC can afford to buy. __T_H_A_T__ is what "affordable" is all about!!!e    >  Being able toK > > sucessfully use more third-party hardware with OpenVMS systems can onlye( > > help expand the user/installed base, > F > Expanding the user/installed base does not in and of itself increaseM > Compaq's profits if it's barely breaking even because the market segment inuL > which that base is expanding is as cut-throat price-wise as the one you'reK > talking about.  Add in the significant cash outlay required for the port    E ...to what? Doesn't OpenVMS already run on Alpha? Alpha systems _ARE_lF __E_X_T_R_E_M_E_L_Y__ difficult to sell due to their pricing, but it'sA not as impossible as trying to push OpenVMS vs. the alternatives.s  E ...and Alpha systems these days have PCI just like Intel mobo's don'ttC they? ...even the "high end" servers? Is not KZPSA a PCI SCSI card?   F OpenVMS/x86 is simply a favor that Digital should have done for itselfD many years ago. Agreed - now such a task is roughly akin to adding aF lane to a road that built too narrow in the first place: it would haveF been GREATLY cheaper to build three lanes each way then as compared toD the cost of adding another lane each way now. Same applies here: hadC Emerald been completed through to salable product back before laborkH costs spiralled upward at a phenomenal rate, they'd have been infinitelyE better off. But, that's a debate for another thread. Let's not pursue0E that here. For now, we're just trying save a market and a few hundredtH thousand jobs, and trying to make a few hundred million dollars (or moreH - don't limit the scope of your thinking artificially) that will instead go to Micro$hit.   > andSH > subsequent support of the new (Intel and third-party) hardware, and it+ > becomes a loss item on the balance sheet.   D ...if not managed astutely. Managing volume vs. margin is a delicateG balancing act, but is not as impossible as most folks think, and can beaC done without locking yourself out of the most lucrative markets, asSD OpenVMS is currently locked out of the so-called "commodity" market.   L > Putting equivalent effort and money into profitable market segments is notL > only more fiscally responsible but more likely to succeed - and successes,J > rather than highly-speculative ventures, are what VMS needs right now to# > return it to non-'legacy' status.   D Without some radical changes, how to you propose to accomplish that?   $ >  while at the same time preserving2 > > the level of quality we've all come to expect. > M > No, supporting a great deal more third-party hardware will almost certainly F > lower that level of perceived quality.  You say as much in your next > sentence.    Perceptions can be managed.   C > That's not necessarily an unthinkable trade-off, but it shouldn't  > be papered over.  F So who is trying to "paper it over"? All I'm saying is don't refuse toC talk to a {disk,tape,cdrom} drive just because it doesn't meet your C expectations. Let the user decide what's acceptable and what isn't.nC We're not in a position to second-guess the user anyway, much as we  might like to.  o >  That is, expect aL > > high-quality device, but do not reject something which "plays nice" mostI > > of the time, and let the user be responsible for the results of usingw > > lower quality gear.M > >  > > > and I am not interestedaD > > > in approaches that widen the interest in VMS at the expense of > > > decreasing the quality.d > >sL > > In what way would increasing the user/installed base in any way threaten > > quality? > 6 > In the ways described above:  weren't you listening?  D No, you were writing this post and hadn't posted it yet. How could I
 have read it?   tG > That said, I don't agree with Larry that this is unthinkable:  it's anG > trade-off, and in some circumstances could be the right one.  But youaN > haven't made the case that such circumstances currently exist, and until the9 > market perception of VMS changes I don't think you can.a  A I've made the case several hundred times over. However, until thepA marketing for OpenVMS finally makes its twenty-plus years overdue G appearance, I'll probably have to make this case several thousand timestE more before I chuck the whole thing and open a fast-food franchise tok secure my retirement.   E Someday, perhaps in some steam room or on some golf course somewhere, F someone from Compaq is going to say to another, "y'know, that DachteraA asshole is not a COMPLETE idiot - he's got SOMEthing on the ball,gG shithead though he may be. Maybe our biggest f__-up was in not offeringsG him an executive position in our marketing department. He's just enough D of a stubborn, bone-headed jerk that he probably could make us a fewD tens of billions of dollars that we let slip through our hands! But,G with all this break-up stuff going on, I guess Bill needs the money, so,3 what the f___? Can't afford to piss HIM off, huh?".s   --   David J. Dachterae dba DJE Systemsn" http://home.earthlink.net/~djesys/  : Unofficial Affordable OpenVMS Home Page and Message Board:+ http://home.earthlink.net/~djesys/vms/soho/a   ------------------------------  % Date: Sat, 17 Jun 2000 18:23:31 -0500m* From: Keith Brown <kbrown780@usfamily.net> Subject: Re: VAX on Intel?, Message-ID: <394C0873.DEED618F@usfamily.net>   Bill Todd wrote: > B > David J. Dachtera <djesys.nospam@earthlink.net> wrote in message) > news:394AF9E4.D0F7BDDC@earthlink.net...- > > Larry Kilgallen wrote: > > >.G > > > In article <39498CB2.6C9BD0D1@earthlink.net>, "David J. Dachtera"i' > <djesys.nospam@earthlink.net> writes:  > > >nL > > > > For example: how would YOU go about expanding the OpenVMS user base? > > > > J > > > > ...or is it that you are not convinced that it SHOULD be expanded? > > >lG > > > As with Macintosh, I am convinced that one of the major strengthsaF > > > of VMS is tight integration with the hardware and the ability of- > > > the OS group to influence the hardware.  > > ? > > This, however, increases hardware costs and keeps OpenVMS'shJ > > cost-effectiveness in the unfavorable range. Note that most MACs todayL > > use common VGA-type monitors, "standard" SCSI devices, and focus less onG > > proprietary network protocols and media and more on UTP and TCP/IP.r > M > And VMS has been dragged, kicking and protesting that DECnet was a superior M > interconnect protocol, into support for TCP/IP (though bundling it with theSI > base system - as other low-end systems do - would help the low-end costd	 > issue).s > N > Larry's point, however, is valid:  the fact that a much higher percentage ofN > the hardware found on typical VMS systems is supported directly (or at leastJ > thoroughly qualified) by VMS engineering than the percentage of hardwareG > found on typical Wintel systems supported/qualified by MS engineering K > contributes significantly to the relative stability of those VMS systems,-L > and (though probably to a lesser extent) the ability of VMS engineering toK > influence hardware development contributes to that hardware's quality andd > compatibility. > L > Whether there's any significant value (under current conditions) to makingG > VMS systems cost-competitive with Windows systems - especially on thelN > desktop - is debatable:  due to lack of familiar applications, familiar userK > interface, and availability of support personnel, VMS is not currently in K > any position to compete effectively on the desktop, and arguably not in adH > good position to compete as a 'commodity' (low-end) back-end server toE > Windows desktops (Pathworks improvements could help there), but itseH > strengths (and *reasonable*, even if not equal, cost) make it a viableE > option in any situation where those weaknesses are less applicable.S > J > Cost-reduction is always desirable.  But when it requires heroic effortsJ > (and an IA port certainly meets that description), those efforts must beM > justified by the anticipated gains.  That's (IMO) really hard to do at thisx > point in time. >  > >  > > > I believe that throwingd. > > > that away is to lessen the value of VMS, > > H > > Obviously, I disagree. In the first place, no one is "throwing away"G > > anything. What this would actually do is to put OpenVMS on a "levelaJ > > playing field" with other o.s.-es which are more tolerant of "diverse"L > > hardware. Strange that diversity among the work-force is viewed as good,< > > while diversity in the technical world is viewed as bad. > L > The main reason people have for viewing technical diversity as bad (to theN > extent that this is true) is that systems don't generally play all that wellH > with each other and don't present sufficiently identical interfaces toI > enable portability of user and support expertise.  Supporting VMS on IAXJ > hardware won't change that much (save for hardware support), and lackingD > that change such support won't make VMS much more competitive withN > 'standard' systems in that space that already are perceived as covering thatK > space's needs adequately.  If people want an alternative, they've alreadyrI > got Linux and other free (and not free) Unixes, which enjoy far greatereJ > application availability and user and support familiarity than VMS does:K > VMS would have difficulty being noticed by anyone except those people whotL > are already sufficiently motivated to use it that they likely already have > it.  >  >  Being able toK > > sucessfully use more third-party hardware with OpenVMS systems can onlyn( > > help expand the user/installed base, > F > Expanding the user/installed base does not in and of itself increaseM > Compaq's profits if it's barely breaking even because the market segment incL > which that base is expanding is as cut-throat price-wise as the one you'reN > talking about.  Add in the significant cash outlay required for the port andH > subsequent support of the new (Intel and third-party) hardware, and it+ > becomes a loss item on the balance sheet.n > L > Putting equivalent effort and money into profitable market segments is notL > only more fiscally responsible but more likely to succeed - and successes,J > rather than highly-speculative ventures, are what VMS needs right now to# > return it to non-'legacy' status.j > $ >  while at the same time preserving2 > > the level of quality we've all come to expect. > M > No, supporting a great deal more third-party hardware will almost certainly F > lower that level of perceived quality.  You say as much in your nextN > sentence.  That's not necessarily an unthinkable trade-off, but it shouldn't > be papered over. >  >  That is, expect aL > > high-quality device, but do not reject something which "plays nice" mostI > > of the time, and let the user be responsible for the results of using  > > lower quality gear.o > >  > > > and I am not interestediD > > > in approaches that widen the interest in VMS at the expense of > > > decreasing the quality., > >hL > > In what way would increasing the user/installed base in any way threaten > > quality? > 6 > In the ways described above:  weren't you listening? > G > That said, I don't agree with Larry that this is unthinkable:  it's a G > trade-off, and in some circumstances could be the right one.  But you N > haven't made the case that such circumstances currently exist, and until the9 > market perception of VMS changes I don't think you can.w >  > - bill  = I find myself agreeing with you on this Bill. Porting to IA32 > should not happen because IA32 will be dead in 3-5 years. IA64< will cost more that Alpha and won't be as fast (according to2 Compaq). So what would a port to Intel accomplish?   -- l Keith Brownr kbrown780@usfamily.net   ------------------------------  + Date: Sun, 18 Jun 2000 01:18:30 +0000 (   )n3 From: Christopher Smith <chriss@Mufasa.pubserv.com>  Subject: Re: VAX on Intel?J Message-ID: <Pine.LNX.4.05.10006180115490.15883-100000@Mufasa.pubserv.com>  ' On Sat, 17 Jun 2000, Keith Brown wrote:h  ? > I find myself agreeing with you on this Bill. Porting to IA32s@ > should not happen because IA32 will be dead in 3-5 years. IA64> > will cost more that Alpha and won't be as fast (according to4 > Compaq). So what would a port to Intel accomplish?  G Ok, fine -- it's not that you _have_ to get VMS ported to intel.  ThereeG are plenty of other options that would probably increase marketshare...t   iMac VMS, anyone?s  B Not so crazy as it may sound... the endianness of a powerpc cpu isF switchable, and it's a 64-bit platform, so it wouldn't be such a largeE step back as a port to IA32 would be.  It would also allow you closer B control over the hardware, since apple is very specific with their systems.  ' ... and it would be translucent blue ;)s   Regards,   Chrisn  O ===============================================================================e@ "My two cents"			(http://rootworks.com/twocentsworth.cgi?128562)= Christopher Smith(chriss@pubserv.com)			Prgramer^W Programmeri Prime Synergy of Champaign, IL.S% -------------------------------------vI "Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes andrH weighs 30 tons, computers in the future may have only 1,000 vacuum tubes; and weigh only 1.5 tons." -- Popular Mechanics, March 1949 fO -------------------------------------------------------------------------------    ------------------------------  % Date: Sat, 17 Jun 2000 22:27:56 -0400r& From: "Jeff Killeen" <Jeff@Killeen.cc> Subject: Re: VAX on Intel?% Message-ID: <394c3248@news.toast.net>   ? > My recollection of this is rather different. DEC was informedt> > by various governments that TCP/IP would be dropped from the? > Internet as the IMP protocol had before it and that OSI would < > take over. Therefore it went and implemented OSI, awaiting; > the promised government action, which never came. Its UCXo> > offering was expected to be a stopgap, which led at least in; > part to its not being done very carefully and to Multinetd > eating its lunch.t  K I was on the DECUS team that was working with Digital closely on networkingtI and they never said this at least to this group that was working hand andeG glove with them - which would be strange because they shared everythinglG else.  What they did say publicly was they wanted to promote OSI as thetJ standard and implementing TCP/IP would slow that adoption.  What they saidH in private was far less benign than that public statement.  Whatever theL factual truth is behind the statement above the overall truth is Digital wasL a primary _initiating_ force behind OSI attempting to replace TCP/IP and not& someone just going along for the ride.  I There were "T"wo "G"uys and "V"AX who are eternally grateful Digital took  that position.  9 > The characterization of VMS being dragged... is at bestt= > uncharitable. DEC got snookered by the governments involveds= > though it did its best to be ready for the Next Great Thing  > that was forecast.  H Digital's goal was to gain control of the corporate network backbone andL their strategy was to do it through making OSI the standard.  Their positionJ on TCP/IP was to cut it off and kill it as quickly as possible.  They wereJ going to do nothing to promote TCP/IP.  Remember this is when Jack ShieldsI was effectively driving the environment that made these decisions and noteL Ken Olsen.  Jack Shields was ruthless.  The overall goal was to wipe out SNAJ and not let TCP/IP replace it.  They weren't snookered by the government -I they were snookered by their own hubris that they could ram this standardc into the marketplace.'  L I am sure IBM has some sort of public spin for token ring base networks thatK tries to put a benign face on their strategy but the motivation was exactlyi, the same as Digital's and OSI versus TCP/IP.  H While we would all like to believe a bucolic view of Digital - they wereC like any other company in attempting to execute schemes to hurt theaL competition and press their advantage.  Don't confuse ineptitude with benign	 intent...e     --     Jeff Killeen - www.Killeen.cctE =====================================================================h   ------------------------------  % Date: Sat, 17 Jun 2000 22:33:35 -0400p' From: "Bill Todd" <billtodd@foo.mv.com>b Subject: Re: VAX on Intel?( Message-ID: <8ihc6t$4vd$1@pyrite.mv.net>  L My comment would be that Michael Capellas, Bill Heil, and Rich Marcello needJ to get a copy of this story, and a separate copy of every individual storyJ like it, until the situation changes.  In particular, since the history ofF the situation appears to make it clear that Marcello does not have theI resources to change things himself, it's important that Heil and CapellaspI recognize that  a) the situation exists and  b) customers want - *really*  want - it changed.   - bill  1 Wolfgang Rupp <wolfgang@rupp.nu> wrote in messageM- news:zPR25.78324$yR.1363520@news.chello.at..._7 > In comp.os.vms Bill Todd <billtodd@foo.mv.com> wrote:gH > > To me, this suggests that expansion of the VMS user base (which I doK > > consider a desirable goal, and suspect Larry does as well) is not goingt toF > > come via the route you're advocating - at least not in the present climate L > > and with VMS's present (lack of) industry visibility and acceptance.  WeF > > should be thankful that it's possible to purchase a new (DS10) VMS systemK > > for $5000 - $6500 (depending on options), which puts it well within theeH > > range of any small business that needs VMS, and look to other marketJ > > segments (all of which offer greater margins and profit potential) for > > expansion opportunities. > K > I think there is a much overlooked fact in this "expanding VMS user base"fH > discussion. I've followed many of these threads for some time, but oneJ > thing was _never_ mentioned: the awareness about VMS within the decisionI > making IT management. Take me for example. During my brief stunt at uni I > I got into contact with VMS in a Pascal programming course. This course H > could have happened on PC also, and in fact we were allowed to hack at+ > home. Fast forward ten years (i.e. 1999).s >tK > The next contact with VMS came through my first own VAX - through peronalaI > interest in collecting and using old hardware. I played around with VMSeJ > because of a) the acclaimed stability, b) it was on the box and c) I wasL > curious. I got my hobbyist license. Several more VAXen and a PDP followed.H > This can't be typical, and no company should count it. Had it not beenH > for personal (hardware) interest, I'd never given VMS a try. CertainlyH > not because of convincing marketing attempts from DEC or later Compaq. >nH > At my present job I have to develop network and server standards for aI > group with multinational locations. We use ERP software from one of thehH > well known vendors. Before, I worked for that vendor. When I mentioned VMS,F > I got blank looks. People just did not know it. Of course, like it'sE > competitors, the software does not run on VMS. You get versions forp; > different Unices, NT and OS/390. Nobody thinks about VMS.a > K > Since the business _really_ depends on zero downtime, VMS might have beenrC > worth a consideration for me... BUT: first showstopper is the ERPr	 software,uI > or rather it's lack of VMS support, the second showstopper would be theaJ > lack of even basic VMS awareness within the company brass, and then lack$ > of VMS-knowledgeable IT personell. > = > It seems that there would be three important steps to take:t8 > a) raise the awareness about the system's capabilities) > b) get mission-critical software portedoH >  (which is easier when RealBigCorps demand it, needs Problem a solved)8 > c) interest "normal" IT people in VMS and VMS training >e > Comments, please...g >e > Wolfgang Rupp  >    ------------------------------  % Date: Sat, 17 Jun 2000 19:21:22 -0700 * From: "Nikita V. Belenki" <kit@nospam.net> Subject: Re: VAX on Intel?: Message-ID: <LrW25.2089$Qf6.70672@nuq-read.news.verio.net>  B "David J. Dachtera" <djesys.nospam@earthlink.net> wrote in message' news:394BFE4E.C917D722@earthlink.net...d  L > > Cost-reduction is always desirable.  But when it requires heroic effortsL > > (and an IA port certainly meets that description), those efforts must beJ > > justified by the anticipated gains.  That's (IMO) really hard to do at this > > point in time.D > I've said it before, and I'll say it again (and again and again...G > however many times it takes to get someone to listen and understand):tH > there are some 450,000 VMS machines in the world vs. 200+ million IA16H > and IA32 (IA64 is, as yet, still vaporware in the marketplace), not toI > mention the Alphas that face the possibility of being scrapped with theoC > demise of Alpha/NT. How much more justification does anyone need?e  * Actually, I can see no justification here.  : > > [snip]  If people want an alternative, they've alreadyK > > got Linux and other free (and not free) Unixes, which enjoy far greatersL > > application availability and user and support familiarity than VMS does:? > A situation which VMS and can view as either a handicap or ant5 > opportunity. I choose to view it as an opportunity.e   Opportunuty for what?n   Kit. kit # kits.net   ------------------------------  % Date: Sat, 17 Jun 2000 23:11:33 -0400l' From: "Bill Todd" <billtodd@foo.mv.com>  Subject: Re: VAX on Intel?( Message-ID: <8ihee1$70i$1@pyrite.mv.net>  5 Glenn C. Everhart <Everhart@GCE.com> wrote in messagea! news:394BB480.112E07E0@GCE.com...m > Bill Todd wrote: > [...]m > >eF > > And VMS has been dragged, kicking and protesting that DECnet was a superiorK > > interconnect protocol, into support for TCP/IP (though bundling it withn theaK > > base system - as other low-end systems do - would help the low-end cost  > > issue).n >t? > My recollection of this is rather different. DEC was informedd> > by various governments that TCP/IP would be dropped from the? > Internet as the IMP protocol had before it and that OSI would < > take over. Therefore it went and implemented OSI, awaiting; > the promised government action, which never came. Its UCXn> > offering was expected to be a stopgap, which led at least in; > part to its not being done very carefully and to Multineto > eating its lunch.a  J I think that's putting the cart before the horse:  my recollection is thatD the OSI model was to a significant degree modeled on DECnet, not theI reverse.  And given that close connection, DEC pushed for OSI adoption oncF the Internet.  We agree that it implemented UCX (or predecessors) as aK stop-gap, but not on the background against which that took place (though InJ wasn't a part of that background so can't speak authoritatively about it).  G And VMS engineering (at least the people I still have contact with) has F always sneered (perhaps rightly so) at IP's capabilities compared withI DECnet's in areas of routing, addressing, and others I can't recall righti now.  F Those informal observations were the basis for my comment.  Possibly IG should have added the observation that this was one case where superior J engineering (DECnet) lost to a more popular standard, since what was in myE mind was that Dave Dachtera was advocating something at least vaguelyy* similar in supporting 'commodity' devices.   >n9 > The characterization of VMS being dragged... is at besth= > uncharitable. DEC got snookered by the governments involved = > though it did its best to be ready for the Next Great ThingM > that was forecast.  L See above:  while DEC may have been mislead about the outcome, I don't thinkI there's any doubt that it was pushing hard for OSI and against IP, rathern! than just an innocent by-stander.a   >c< > There were many who considered OSI to be shaping up as the9 > Next Great Turkey instead (for the foreigners: domesticb; > turkeys have been known to drown in the rain because they > > are looking up and aren't smart enough to lower their heads,; > hence the slang usage for something inept and ill adaptede@ > to its environment).  Nevertheless, the OSI hype continued for? > several years and appeared serious in at least some quarters.w: > It is at least ungenerous to take VMS to task for having+ > believed and built an OSI implementation.=  H I'd be curious to hear how other people remember this particular part ofF history:  my impressions are pretty distinct, but they could be wrong.   - bill   ------------------------------  % Date: Sun, 18 Jun 2000 00:38:31 -0400t& From: "Jeff Killeen" <Jeff@Killeen.cc> Subject: Re: VAX on Intel?% Message-ID: <394c517d@news.toast.net>r  D > I've said it before, and I'll say it again (and again and again...G > however many times it takes to get someone to listen and understand):cH > there are some 450,000 VMS machines in the world vs. 200+ million IA16H > and IA32 (IA64 is, as yet, still vaporware in the marketplace), not toI > mention the Alphas that face the possibility of being scrapped with theoC > demise of Alpha/NT. How much more justification does anyone need?.  J Actually it is the number of "eyeballs" looking at OVMS driven applicationG windows and not the number of licenses.  If you want to "save" OVMS thecE issue shouldn't be deploying it on IA32 - that is yesterday's battle.iK Tomorrow's battle will be who builds the best ASP box.  OVMS actually couldtI capture a lot of "eyeballs" if Compaq wanted to produce a set of tools toiJ make OVMS a robust ASP box.  Building successful ASP applications is goingJ to require a change in application design which means OVMS has a window ofL opportunity.  You can't take existing PC application designs and just scrapeJ the interface off into a browser.  It may be technically possible to do itI but in reality the application won't perform well if it was built using a   full fat client PC design model.  K Even Gates knows that for shared data enterprise business applications (notoI decision support applications) the fat client PC application is a sittingSJ duck.  If you don't think they are in a panic over this study their VisualL Studio V7 and NGWS strategies.  MS knows the ASP model will be the model the future.s  L OVMS's greatest opportunity is NOT to try to out PC Microsoft but instead toK catch the next wave which will be the ASP model.  OVMS would be a fantastic K platform for this if Compaq deploys the right tools yesterday.  Chasing thegJ IA32 platform is the wrong way for them to spend their money.  The biggestJ treat to OVMS becoming a world class ASP box is Compaq deciding that Tru64L is the platform for that.  In fact one could make the case that the greatest> threat to OVMS's future isn't the Borg in Redmond but Tru64...     --     Jeff Killeen - www.Killeen.cc E =====================================================================    ------------------------------  % Date: Sun, 18 Jun 2000 01:10:29 -0400v' From: "Bill Todd" <billtodd@foo.mv.com>i Subject: Re: VAX on Intel?( Message-ID: <8ihld2$rqa$1@pyrite.mv.net>  @ David J. Dachtera <djesys.nospam@earthlink.net> wrote in message' news:394BFE4E.C917D722@earthlink.net...  > Bill Todd wrote: > [snip]B > > Larry's point, however, is valid:  the fact that a much higher
 percentage ofcJ > > the hardware found on typical VMS systems is supported directly (or at leasteL > > thoroughly qualified) by VMS engineering than the percentage of hardwareI > > found on typical Wintel systems supported/qualified by MS engineeringSD > > contributes significantly to the relative stability of those VMS systems,K > > and (though probably to a lesser extent) the ability of VMS engineeringl toI > > influence hardware development contributes to that hardware's qualityi ande > > compatibility. >sH > On the other hand, all the "other o.s.-es" really try to do is put theE > data into the drive's buffer (we ARE talking about SCSI disk drive,t	 > right?)a  B Actually, no:  you brought up monitors and SCSI drives in a mannerD suggesting that you were talking about devices in general, and so myL comments related to supporting anything that could be plugged into a PCI (orJ IDE or SCSI) bus and could be considered at least vaguely 'standard':  theI vast range in features and quality of such devices (and the drivers third K parties write for them) on PCs contributes in no small part to the relativerI instability of the Windows OSs, and would do the same to VMS if they weree commonly used there.  H Dave Froble has suggested in another post that SCSI drives (possibly IDEG drives as well) are sufficiently standard that virtually any will 'justaJ work' with VMS (though I suspect that most of his direct experience may beL with non-clustered configurations), which if generally true sounds like whatH you are asking for.  My impression is that the reason VMS qualifies SCSII drives is primarily to ensure that their multi-initiator support actuallypE works as specified, which applies only to clustering use - but if youmK believe the statistic someone floated recently that 90% of VMS systems livehF in a cluster, then it's not clear that it's worth bothering to qualifyL drives for non-clustered use (especially if virtually any drive will work in that setting).  ;  and issue a write command and see that the write operationi= > returns a success status. That's all ANYone really expects.p >tG > > Whether there's any significant value (under current conditions) to  makingI > > VMS systems cost-competitive with Windows systems - especially on the2 > > desktop - is debatable:o > 8 > ...however unecessary that debate may be (read on),... >D8 > >  due to lack of familiar applications, familiar userJ > > interface, and availability of support personnel, VMS is not currently inK > > any position to compete effectively on the desktop, and arguably not int a J > > good position to compete as a 'commodity' (low-end) back-end server to? > > Windows desktops (Pathworks improvements could help there),d >sG > ...let's not forget Samba, and the NFS functions available in most ofoJ > the third party TCP/IP stacks currently available (current only MultinetI > and TCPware, both from Process Software, which has itself fallen victimf' > to the corporate take-over frenzy)...T  > If VMS Samba and NFS support exists that makes it feature- andG performance-competitive with NT and the better Unix servers for Windows L clients, then that addresses my most serious reservations about file serviceJ (maybe print service as well, if Samba does that):  I'd love to see CompaqJ able to present VMS as a better alternative, though it would still have an: up-hill fight in the area of user and support familiarity.   >e > > but itsD > > strengths (and >i > ...debatably...t >W# > > *reasonable*, even if not equalr >c# > ...correction: greatly unequal...e  D No.  Costing 2 or 3 times as much in the very low end is negligible:L support costs dwarf the purchase cost in any business situation for productsI in this price range.  You may have to educate a naive customer about thishG before making the sale, but given that you're competing with 'standard'rH alternatives education is going to be required for that kind of customer anyway.a   >  > > , cost) make it a viableG > > option in any situation where those weaknesses are less applicable.e > >pL > > Cost-reduction is always desirable.  But when it requires heroic effortsL > > (and an IA port certainly meets that description), those efforts must beJ > > justified by the anticipated gains.  That's (IMO) really hard to do at this > > point in time. >sD > I've said it before, and I'll say it again (and again and again...G > however many times it takes to get someone to listen and understand):fH > there are some 450,000 VMS machines in the world vs. 200+ million IA16H > and IA32 (IA64 is, as yet, still vaporware in the marketplace), not toI > mention the Alphas that face the possibility of being scrapped with theiC > demise of Alpha/NT. How much more justification does anyone need?   I Compaq needs to make a profit on the endeavor to justify it.  So far, youdD have produced no convincing evidence that it can.  In answer to yourK question, that's the justification that's lacking:  until you can make whatnK you believe is obvious obvious to unbiased observers, you'll remain a voiced2 in the wilderness and simply make yourself hoarse.   >e > > >  > > > > I believe that throwing 0 > > > > that away is to lessen the value of VMS, > > >tJ > > > Obviously, I disagree. In the first place, no one is "throwing away"I > > > anything. What this would actually do is to put OpenVMS on a "levelnL > > > playing field" with other o.s.-es which are more tolerant of "diverse"H > > > hardware. Strange that diversity among the work-force is viewed as good, > > > > while diversity in the technical world is viewed as bad. > >lJ > > The main reason people have for viewing technical diversity as bad (to thevK > > extent that this is true) is that systems don't generally play all that  well > C > True. However, for our purposes, I think we're talking more abouteH > peripherals than entire systems. The business world has, IMO, seen theJ > error of its "buy the app. you need regardless of what it runs on" ways:E > down-time and increased costs due to incompatible and non"standard"MH > systems and communication protocols. Nowadays, everyone's enamoured ofI > "point and click" and "web based" systems (thanx - for nothing, Bill!).  >h: > > [snip]  If people want an alternative, they've alreadyK > > got Linux and other free (and not free) Unixes, which enjoy far greateriL > > application availability and user and support familiarity than VMS does: >o? > A situation which VMS and can view as either a handicap or ana5 > opportunity. I choose to view it as an opportunity.e > I > > VMS would have difficulty being noticed by anyone except those peoplev whotI > > are already sufficiently motivated to use it that they likely alreadyu have > > it.o >tF > ...which is why we gotta push app. development which is why we gottaG > push "affordable". Get it? Folks won't develop for system that no one E > can afford to buy. __T_H_A_T__ is what "affordable" is all about!!!   I 1)  VMS is eminently affordable.  It just isn't as inexpensive as Windowsa (or Linux).a  H 2)  Making VMS as inexpensive as Windows (or Linux) - and even followingG suit by allowing it to run on equally inexpensive hardware, or even therB *same* hardware - won't necessarily make it any more attractive toL developers, or end-users:  in the absence of compelling feature differences,J developers prefer system platforms in already-widespread use, so that theyC have the largest immediately-available market, and end-users preferiH platforms already familiar to them or their friends/business associates.  J In other words, price is not the problem.  Acceptance is the problem.  VMSI will *never* be widely accepted - by developers or end-users - as long as K it's perceived as a 'legacy' system on the way out, even if it's free.  YoutB convince the industry that VMS is not on the way out by committingI significant and long-term marketing and development resources to it - but,I that's a major, expensive gamble, so Compaq is likely to want to start inlF the areas most likely to be successful (market segments that *already*H depend upon the kinds of strengths VMS offers and are willing to pay forK them) and only after demonstrating promise there move on to more ambitious,h less certain expansion plans.i  I The time between the two phases may not have to be long, if VMS shows theyL promise it should be able to where it's already strongest.  But expecting toE *start* with a long-shot (like a port to IA hardware) is unrealistic.r   >a > >  Being able toH > > > sucessfully use more third-party hardware with OpenVMS systems can only* > > > help expand the user/installed base, > >aH > > Expanding the user/installed base does not in and of itself increaseL > > Compaq's profits if it's barely breaking even because the market segment inG > > which that base is expanding is as cut-throat price-wise as the onen you'reL > > talking about.  Add in the significant cash outlay required for the port >@G > ...to what? Doesn't OpenVMS already run on Alpha? Alpha systems _ARE_0H > __E_X_T_R_E_M_E_L_Y__ difficult to sell due to their pricing, but it'sC > not as impossible as trying to push OpenVMS vs. the alternatives.9  K As I said, I just don't perceive that the main obstacles to pushing VMS are L its price or the price of the hardware it runs on, and simply repeating yourG own beliefs is not likely to change mine or anyone else's.  But I wouldtL suggest that the popularity of Alphas in the Linux community should offer atI least some indication of whether Alpha pricing is completely unreasonabletI compared to IA pricing:  that's an apples-to-apples comparison situation.a  K I'll let more informed people comment on the difficulty of a VMS port to IA G hardware.  At a minimum, it would require a MARS compiler (for the sameoD reasons Alpha did, but producing IA output) and a supported IA BlissF compiler (didn't Oracle just drop support for Rdb on NT because CompaqK wasn't willing to support the IA Bliss compiler?).  I suspect it would also;J require a great deal of other work, and possibly many more such tools, but# that's for someone else to fill in.    >eG > ...and Alpha systems these days have PCI just like Intel mobo's don't(E > they? ...even the "high end" servers? Is not KZPSA a PCI SCSI card?n >LH > OpenVMS/x86 is simply a favor that Digital should have done for itselfF > many years ago. Agreed - now such a task is roughly akin to adding aH > lane to a road that built too narrow in the first place: it would haveH > been GREATLY cheaper to build three lanes each way then as compared to/ > the cost of adding another lane each way now.-  J Unfortunately, it's not clear that this road goes anywhere many people areJ interested in going any more:  in the meantime, other roads were built and" other destinations became popular.    Same applies here: hadiE > Emerald been completed through to salable product back before laborbJ > costs spiralled upward at a phenomenal rate, they'd have been infinitelyG > better off. But, that's a debate for another thread. Let's not pursue G > that here. For now, we're just trying save a market and a few hundredsJ > thousand jobs, and trying to make a few hundred million dollars (or moreJ > - don't limit the scope of your thinking artificially) that will instead > go to Micro$hit.  J Or pour a bunch of money down a rat hole and still see those dollars go toL MS because no one is particularly interested in the product you're offering.   >c > > and J > > subsequent support of the new (Intel and third-party) hardware, and it- > > becomes a loss item on the balance sheet./ >wF > ...if not managed astutely. Managing volume vs. margin is a delicateI > balancing act, but is not as impossible as most folks think, and can betE > done without locking yourself out of the most lucrative markets, asrF > OpenVMS is currently locked out of the so-called "commodity" market.  L It seems you haven't been paying attention to corporate financial statementsK for a few years:  'commodity' PCs cannot be considered a 'lucrative' marketeL compared to the markets VMS currently occupies, let alone a 'most lucrative'H market.  IBM has lost enough money in PCs to be withdrawing from serious? competition; Compaq has had difficulty just returning to (bare)rG profitability.  HP and Dell are doing OK in PC volume, but with nothingt% anywhere near the margins VMS enjoys.    >oJ > > Putting equivalent effort and money into profitable market segments is notoC > > only more fiscally responsible but more likely to succeed - and 
 successes,L > > rather than highly-speculative ventures, are what VMS needs right now to% > > return it to non-'legacy' status.o >SF > Without some radical changes, how to you propose to accomplish that?  C I said nothing about avoiding radical changes:  just about avoidingd< (certainly, delaying) the specific change you're advocating.   >s& > >  while at the same time preserving4 > > > the level of quality we've all come to expect. > >nE > > No, supporting a great deal more third-party hardware will almost 	 certainly H > > lower that level of perceived quality.  You say as much in your next
 > > sentence.t >  > Perceptions can be managed.i  L I'd suggest, then, that you manage the perception that pricing is a problem,< rather than base a major initiative on that (false) premise.   >aE > > That's not necessarily an unthinkable trade-off, but it shouldn'to > > be papered over. >l& > So who is trying to "paper it over"?  K You were, by claiming that quality would not be affected (in the sentence I-L responded to).  But if all you meant was what you say below, I have far less of a problem with it.:  "  All I'm saying is don't refuse toE > talk to a {disk,tape,cdrom} drive just because it doesn't meet yourgE > expectations. Let the user decide what's acceptable and what isn't.nE > We're not in a position to second-guess the user anyway, much as wev > might like to.  L Now, when you put it in that limited a manner, it gets more reasonable.  ButI (as I mentioned earlier) Dave Froble's experience seems to be that VMS is L happy to talk to commodity SCSI (and perhaps IDE) drives, and they work just3 fine.  So what exactly are you saying is a problem?n   >i > >  That is, expect aI > > > high-quality device, but do not reject something which "plays nice"e mostK > > > of the time, and let the user be responsible for the results of using  > > > lower quality gear.V > > >a > > > > and I am not interestedbF > > > > in approaches that widen the interest in VMS at the expense of > > > > decreasing the quality.P > > >aE > > > In what way would increasing the user/installed base in any wayV threaten > > > quality? > >.8 > > In the ways described above:  weren't you listening? >aF > No, you were writing this post and hadn't posted it yet. How could I > have read it?a  J Sorry - I meant weren't you listening to *Larry's* objections, which all II did was re-state.  Again, there may have been a disconnect if you weren'tsL advocating the kind of "We'll try to work with any hardware that we think weI *might* have a *vague* idea how to talk to" situation that obtains in thet Windows environment.   >dI > > That said, I don't agree with Larry that this is unthinkable:  it's auI > > trade-off, and in some circumstances could be the right one.  But you L > > haven't made the case that such circumstances currently exist, and until thes; > > market perception of VMS changes I don't think you can.t >a0 > I've made the case several hundred times over.  B No, you haven't:  you've just told people that you believe that anJ 'affordable' VMS will magically lead to its revival.  Others disagree withL your belief (I've suggested some possible reasons here), and you've provided! no actual evidence to support it..    However, until theeC > marketing for OpenVMS finally makes its twenty-plus years overdue=
 > appearance,=  J I don't think *anyone* disagrees with you on this point:  that's the firstK step Compaq must take, and there's little indication that they realize thateH it's a lot bigger job than just ceasing to actively stifle VMS marketing8 entirely and improving the Web site to something usable.  <  I'll probably have to make this case several thousand timesG > more before I chuck the whole thing and open a fast-food franchise toh > secure my retirement.a >MG > Someday, perhaps in some steam room or on some golf course somewhere, H > someone from Compaq is going to say to another, "y'know, that DachteraC > asshole is not a COMPLETE idiot - he's got SOMEthing on the ball, I > shithead though he may be. Maybe our biggest f__-up was in not offeringo8 > him an executive position in our marketing department.  K You could do a lot of good there (it sure as hell needs a good shaking up),uI and it might help keep you away from strategic product design (where I at.* least find your insights less persuasive).  H You asked what specific objections other people had to your proposal andK what they thought ought to be done instead.  I've tried to answer, but it'si not clear you want to listen.d   - bill    He's just enoughoF > of a stubborn, bone-headed jerk that he probably could make us a fewF > tens of billions of dollars that we let slip through our hands! But,I > with all this break-up stuff going on, I guess Bill needs the money, so 5 > what the f___? Can't afford to piss HIM off, huh?".o >a > -- > David J. Dachteran > dba DJE Systemsn$ > http://home.earthlink.net/~djesys/ > < > Unofficial Affordable OpenVMS Home Page and Message Board:- > http://home.earthlink.net/~djesys/vms/soho/    ------------------------------  % Date: Sun, 18 Jun 2000 01:50:00 -0400o' From: "Bill Todd" <billtodd@foo.mv.com>o Subject: Re: VAX on Intel?( Message-ID: <8ihnn3$7ef$1@pyrite.mv.net>  G Hear, hear!  VMS is better-suited than any other platform to efficient,iJ reliable, available, scalable server environments.  Give it a decent LinuxG environment for developers who aren't (at least initially) motivated tonL learn a new platform, fix the file system issues we've been talking about (IK think VMS should take the plunge and provide updated RMS-like facilities as'F well that would lead the industry in non-database data management, butF that's not an initial requirement), and get out there and demolish the competition.  J Tru64 is only a political threat (though such can be the most dangerous inI some situations, and history suggests that this may well be one of them):tK it just doesn't have the architecture to do the same quality job, and showsmH no evidence of ever becoming particularly competitive in the Unix marketJ (why anyone would expect its acceptance to *increase* as that market moves? toward standardization around Linux and Monterey is a mystery).p   - bill  / Jeff Killeen <Jeff@Killeen.cc> wrote in message  news:394c517d@news.toast.net...pF > > I've said it before, and I'll say it again (and again and again...I > > however many times it takes to get someone to listen and understand):sJ > > there are some 450,000 VMS machines in the world vs. 200+ million IA16J > > and IA32 (IA64 is, as yet, still vaporware in the marketplace), not toK > > mention the Alphas that face the possibility of being scrapped with theiE > > demise of Alpha/NT. How much more justification does anyone need?S >mL > Actually it is the number of "eyeballs" looking at OVMS driven applicationI > windows and not the number of licenses.  If you want to "save" OVMS thesG > issue shouldn't be deploying it on IA32 - that is yesterday's battle.aG > Tomorrow's battle will be who builds the best ASP box.  OVMS actually  couldtK > capture a lot of "eyeballs" if Compaq wanted to produce a set of tools touL > make OVMS a robust ASP box.  Building successful ASP applications is goingL > to require a change in application design which means OVMS has a window ofG > opportunity.  You can't take existing PC application designs and just  scrapeL > the interface off into a browser.  It may be technically possible to do itK > but in reality the application won't perform well if it was built using ao" > full fat client PC design model. >iH > Even Gates knows that for shared data enterprise business applications (notK > decision support applications) the fat client PC application is a sittingiL > duck.  If you don't think they are in a panic over this study their VisualJ > Studio V7 and NGWS strategies.  MS knows the ASP model will be the model ther	 > future.d > K > OVMS's greatest opportunity is NOT to try to out PC Microsoft but insteade toC > catch the next wave which will be the ASP model.  OVMS would be a 	 fantasticmI > platform for this if Compaq deploys the right tools yesterday.  Chasing. theoL > IA32 platform is the wrong way for them to spend their money.  The biggestL > treat to OVMS becoming a world class ASP box is Compaq deciding that Tru64E > is the platform for that.  In fact one could make the case that the  greatest@ > threat to OVMS's future isn't the Borg in Redmond but Tru64... >l >/ > -- >u >m > Jeff Killeen - www.Killeen.ccdG > =====================================================================r >o >  >e   ------------------------------  % Date: Sun, 18 Jun 2000 03:55:52 +0930 / From: Mark Daniel <mark.daniel@wasd.vsm.com.au>o5 Subject: VMSeti CGI script update - for VMS SETI@homei/ Message-ID: <394BC2B0.311AF64C@wasd.vsm.com.au>l  D VMSeti provides a Web-based interface for monitoring the progress ofD VMS SETI@home processing.  It supports the WASD and OSU servers, andB should (though untested) work for VMS Apache, Purveyor, FastTrack, etc.  4 If your are not sure what SET@home is all about then  %   http://setiathome.ssl.berkeley.edu/   @ This is a version 3.0 update.  It now supports SETI@home v2.4 byC default and has had a couple of other minor enhancements since v2.0  (Feb 2000).   7 Demonstration ... http://wasd.vsm.com.au/cgi-bin/vmseti < Source & Doc .... http://wasd.vsm.com.au/ht_root/src/vmseti/. Download ........ http://wasd.vsm.com.au/wasd/  B (Note: the demo is running on a *VAX* showing demo data only - VMSE SETI@home is not supported on VAX, only Alpha - this is a demo of theh
 script only!)r  3 Support SETI@home, and if you can SETI@home on VMS!o  E +-------------------------------------------------------------------+oD  Mark Daniel            Opinions my own ... and on loan from others.E  mailto:Mark.Daniel@wasd.vsm.com.au (Mark.Daniel@dsto.defence.gov.au) E +-------------------------------------------------------------------+)   ------------------------------   End of INFO-VAX 2000.338 ************************