1 INFO-VAX	Mon, 16 Jul 2001	Volume 2001 : Issue 392       Contents:1 RE: 3 Reasons why VMS is alive and probably well+ C Re: Alpha ES40 Quad 667 CPU 4GB $48,000 + Free Worldwide shipping !   Re: Alpha is "Others" for Compaq$ Re: booting diskless satellite fails2 Re: Compaq's Road to IPF: A Twenty-Question Survey2 Re: Compaq's Road to IPF: A Twenty-Question Survey Crypto
 Re: Crypto? Re: CSWS / Apache 1.1 - how to specify userdirs with wildcards? ? Re: CSWS / Apache 1.1 - how to specify userdirs with wildcards? " Re: DHCP on different Cluster Node Disk cluster size  Re: Disk cluster size , Re: DIVA errors caused by ES1888 sound card?	 ftp error  Re: Future of Alpha/VMS support ) Re: Help ? Get OpenVMS screen data by ASP  Re: IA64 Rocks My World  Re: IA64 Rocks My World  Re: IA64 Rocks My World  Re: IA64 Rocks My World  RE: IA64 Rocks My World  RE: IA64 Rocks My World  Re: IA64 Rocks My World  RE: IA64 Rocks My World  Re: Idle process Re: Idle process Re: Is there a WASD forum? Re: Motif Upgrade? Re: Motif Upgrade? Re: Motif Upgrade?' Multinet NFS client and Linux Problems. ; OpenVMS IPF Console (was: Re: Full port of VMS to Itanium.) B Re: OpenVMS on IPF (was re: IPF already needs a face-lift for VMS)B Re: OpenVMS on IPF (was re: IPF already needs a face-lift for VMS)B Re: OpenVMS on IPF (was re: IPF already needs a face-lift for VMS) Re: PAWZ and ECP - Re: RA7x series disks , Re: Shadowing drives with different geometry! Re: SHOW USER/FULL changed output  Re: Small Mozilla request $ Re: Terry Shannon Tech Talk on IA-64$ Re: Terry Shannon Tech Talk on IA-64$ Re: Terry Shannon Tech Talk on IA-64$ RE: Terry Shannon Tech Talk on IA-64$ Re: Terry Shannon Tech Talk on IA-64$ Re: Terry Shannon Tech Talk on IA-641 Re: The death of VMS has been greatly exaggerated 1 Re: The death of VMS has been greatly exaggerated 1 RE: The death of VMS has been greatly exaggerated  Re: VMS Docset Wanted  RE: VMS Docset Wanted  RE: VMS Docset Wanted  Re: VMS on IA64  Re: Volume Shadowing Question  Re: Volume Shadowing Question 6 Wanted: Program to set process name to UAF owner value: Re: Wanted: Program to set process name to UAF owner value  F ----------------------------------------------------------------------    Date: 16 Jul 2001 09:44:06 -00004 From: Doc.Cypher <Use-Author-Address-Header@[127.1]>: Subject: RE: 3 Reasons why VMS is alive and probably well+5 Message-ID: <20010716094406.6004.qmail@nym.alias.net>   " -----BEGIN PGP SIGNED MESSAGE-----  A On Sun, 15 Jul 2001, "Main, Kerry" <Kerry.Main@compaq.com> wrote: L >>>> "could" - but don't. And you wonder why your credibility is damaged.<<< > J >If I discussed Customer names without their permission in a public forum,( >what would that do to my credibility ?  > L >Geez .. that it is one of the first rules of consulting - surely you do not >disagree with this ?  > H >I rather suspect you would not want anyone to discuss what your company@ >strategies and futures were in a public forum like this either.  K Agreed. I wouldn't publicise customer discussions. Right now people in this @ newsgroup need a little more than approval from unnamed sources.  K >Customer and ISV names like Cerner who have agreed to go public are in the  >presentation at: E >http://www.compaq.com/hps/ipf-enterprise/overview.html (see Customer  >presentation half way down) > K >>>> Well, get someone to explain "the whole picture" here then, instead of # >offering meaningless platitudes.<<  > ) >Have you reviewed the presentation yet??   E Yes, I've reviewed the Punypoint presentation. The same snippets from K high-ups are repeated without any real substance. To me it seems like a lot G of pointy-haired boss-speak. As you might have seen in another thread I J don't think the port is a bad idea. However, killing Alpha strikes me (and many others) as most stupid.     Doc. - --  6 The bigger the humbug, the better people will like it. ~ Phineas Taylor Barnum.   -----BEGIN PGP SIGNATURE-----  Version: 2.6.2  @ iQEVAwUBO1IgcsriC3SGiziTAQFL2AgArbn/M6FnastVaL9QWvlgMw3ZT9E1w99b@ kAQ6OskT9feNLQwkV0NrZXf+N5S5fjTfORJzjcYPWw08J08JUao6vdoBXd7/5s/6@ cKUMxI2NZsHW+9QyBGTzSI/NgJ32smoNtCzYcqaPTUqK9m9q9dsbjjriyMBO54qY@ GZN2WSLDGktQwrEjhHli1AFPtR6V8u55kRzI7q4sK/c44tmTjFhh3nluT2X6UK51@ Is/x92rPTIQ65voi2rFS/NYnP018+zL0s0+lUGOT7vC+cLN4VidVlfzjN/GGJ4QK8 41ys73wfIRQOaIRuTqAYhfAL2tVCZEE68P+bSUdSZ2uhGPGJogY3JQ== =HhOz  -----END PGP SIGNATURE-----    ------------------------------    Date: 16 Jul 2001 19:11:41 +0200* From: eplan@kapsch.net (Peter LANGSTOEGER)L Subject: Re: Alpha ES40 Quad 667 CPU 4GB $48,000 + Free Worldwide shipping !( Message-ID: <3b53204d@news.kapsch.co.at>  k In article <tksgk34obsn72d@news.supernews.com>, "D.B. Turner, islandco.com" <dbturner@islandco.com> writes: # >www.islandco.com/specials/es40.htm   3 With the next big win in the lottery, I'll bite ;-)   L In the meantime, I still have to figure out how I can afford a DS10 (easier)G and (the more complicated part) which local reseller is willing to sell  me (hobbyist) one ?   G It's a shame that all local COMPAQ reseller does only want to sell PCs. G Only a distributor is willing to sell Alphas here, but only to partners A of course, not to end-customers. Q simply doesn't want my money !    --  < Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888 < <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------    Date: 16 Jul 2001 15:30:30 +0200* From: eplan@kapsch.net (Peter LANGSTOEGER)) Subject: Re: Alpha is "Others" for Compaq * Message-ID: <3b52ec76$1@news.kapsch.co.at>  ` In article <gbcrkt8qgi16p6aq32didbvojvd020ukvh@4ax.com>, Alan Greig <a.greig@virgin.net> writes:$ >On Thu, 12 Jul 2001 08:21:42 -0300,+ >fabio_compaq@ep-bc.petrobras.com.br wrote: 1 >>Today I opened a case at Compaq/Brazil by phone  >> >>Dial  "2"  for Tandem  >> >>Dial  "4" for Proliant >> >>Dial "6" for Software  >> >>Dial "8" for "Others"  > G >I complained about something similar in the UK and they actually added : >VMS as a menu selection item. Might be worth complaining.  	 Might be.  But why must we complain ?I Isn't VMS important enough for Q to do it right just from the beginning ?    --  < Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888 < <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------  % Date: Mon, 16 Jul 2001 10:56:08 +0100 * From: "Richard Brodie" <R.Brodie@rl.ac.uk>- Subject: Re: booting diskless satellite fails , Message-ID: <9iudnq$17bg@newton.cc.rl.ac.uk>  4 "Brian Hechinger" <wonko@arkham.ws> wrote in message0 news:20010714201942.L462@wintermute.arkham.ws...  J > %VAXcluster-I-SYSLOAD, system loaded from node EARTH (AA-00-04-00-01-04)  D OK. What you've got is the  loader downloaded to the satellite node.I It needs to connect a boot driver up to the system disk so it can get the  system loaded.  4 > %VAXcluster-W-NOCONN, No connection to disk server  - It can't find the system disk to load the OS.   M > %VAXcluster-F-CTRLERR, boot driver virtual circuit to SCSSYSTEM 0000 Failed   Q Worse, it can't  find the boot node at all. And why does it think SCSSYSTEM is 0?   P > is there something i'm missing that would be easy if i had the cluster manual?  ; Probably. Some system parameters to check on the boot node: 3 VAXCLUSTER, MSCP_LOAD, MSCP_SERVE_ALL, SCSSYSTEMID.    ------------------------------   Date: 16 Jul 2001 15:46:57 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) ; Subject: Re: Compaq's Road to IPF: A Twenty-Question Survey + Message-ID: <9iv29h$s2p$1@info.cs.uofs.edu>   ? At least one of the questions needed more options for answers.    C "Do you believe ISVs will port their apps to Compaq IPF platforms?" C isn't really a yes or no question.  Undoubtedly, some will and just  as undoubtedly some won't.    " A better question might have been:  > "What percentage of ISV's do you think will port their apps to Compaq IPF platforms?"     100%      80%      60%      40%      20%       0%   Or:   = "What percentage of ISV's apps do you think will be ported to  Compaq IPF platforms?"     100%      80%      60%      40%      20%       0%     bill   --  J Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  # Date: Mon, 16 Jul 2001 16:47:28 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>; Subject: Re: Compaq's Road to IPF: A Twenty-Question Survey ; Message-ID: <AUE47.3452$qA6.771358@typhoon.ne.mediaone.net>   > "Bill Gunshannon" <bill@triangle.cs.uofs.edu> wrote in message% news:9iv29h$s2p$1@info.cs.uofs.edu... @ > At least one of the questions needed more options for answers. > E > "Do you believe ISVs will port their apps to Compaq IPF platforms?" E > isn't really a yes or no question.  Undoubtedly, some will and just  > as undoubtedly some won't. > $ > A better question might have been: > @ > "What percentage of ISV's do you think will port their apps to > Compaq IPF platforms?"
 >     100%
 >      80%
 >      60%
 >      40%
 >      20%
 >       0% >  > Or:  > ? > "What percentage of ISV's apps do you think will be ported to  > Compaq IPF platforms?"
 >     100%
 >      80%
 >      60%
 >      40%
 >      20%
 >       0% >   @ Agreed and thanks very much. We'll do this the next time around!   ------------------------------  % Date: Mon, 16 Jul 2001 05:11:12 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca>  Subject: Crypto 9 Message-ID: <1dy47.4651$oh4.572931@news20.bellglobal.com>   L About a month ago people in the news group were chatting about a book calledJ the "Puzzle Palace" (BTW, I didn't buy the book because of the bad reviews given here).  K Last week I purchased a neat book called "Crypto: When the Code Rebels Beat J the Government - Saving Privacy in the Digital Age" by Steven Levy. It's aJ neat non-technical book that describes with the socio-political history ofL computer cryptology, dealing more with people and places than technology. IfK you enjoyed his booked titled "Hackers: Heroes of the Computer Revolution", # then you'll probably like "Crypto".   
 Neil Rieck Kitchener/Waterloo/Cambridge,  Ontario, Canada.! http://www3.sympatico.ca/n.rieck/    ------------------------------    Date: 16 Jul 2001 06:02:05 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)  Subject: Re: Crypto 3 Message-ID: <ALr1KAS0a9hd@eisner.encompasserve.org>   e In article <1dy47.4651$oh4.572931@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes: N > About a month ago people in the news group were chatting about a book calledL > the "Puzzle Palace" (BTW, I didn't buy the book because of the bad reviews > given here). > M > Last week I purchased a neat book called "Crypto: When the Code Rebels Beat L > the Government - Saving Privacy in the Digital Age" by Steven Levy. It's aL > neat non-technical book that describes with the socio-political history ofN > computer cryptology, dealing more with people and places than technology. IfM > you enjoyed his booked titled "Hackers: Heroes of the Computer Revolution", % > then you'll probably like "Crypto".   F Steven Levy gave a keynote talk at the RSA conference this past April.E He discussed the book (and autographed copies later) but in that talk C there was no discussion of the part of the book which described the J loosening of Jim Bidzos' connection to RSA (Data) Security (Incorporated). I certainly recommend the book.    ------------------------------  % Date: Mon, 16 Jul 2001 08:25:59 -0400 ) From: Rick Barry <barry@star.zko.dec.com> H Subject: Re: CSWS / Apache 1.1 - how to specify userdirs with wildcards?0 Message-ID: <3B52DD56.4DCBE652@star.zko.dec.com>   Martin Vorlaender wrote:  0 > "Alan Winston - SSRL Admin Cmptg Mgr" wrote...A > >"Martin Vorlaender" <martin.vorlaender@pdv-systeme.de> writes: 2 > >>"Alan Winston - SSRL Admin Cmptg Mgr" wrote... > >>>It turns out that doing > >>> & > >>><Directory /$disk4/winston/www/ > > >>> I > >>>will match the directory and all is well.  Server-side includes work  > fine.  > >>> 
 > >>>However,  > >>>   > >>><Directory /$disk4/*/www/ > > >>> M > >>>doesn't match that same directory, which seems counterintuitive at best.  > >>H > >>Why? <Directory> is for *one* directory. If you want to wildcard the1 > >>dir spec, use the <DirectoryMatch> directive.  > > B > >Both _Professional Apache_ and _The Apache Desk Reference_ showG > ><Directory> as having wild-card - but not full regexp - support, and 4 > >the example in the httpd.conf distributed file is > > $ > ><Directory /home/*/public_html/ > > > , > >so I do think this is _supposed- to work. > I > You're right: http://httpd.apache.org/docs/mod/core.html#directory also 
 > says so. > K > Beware, however, that "as of Apache 1.3 none of the wildcards match a `/' 
 > character".  > I > Full reexp support is available (in Apache 1.2 and up) using the syntax = > <Directory ~ /path/with/regexp> . See the docs for caveats.  > N > Just an idea: Thinking "unix shell", could it be that the $ confuses Apache? >  > cu, 
 >   Martin > --L > One OS to rule them all       | Martin Vorlaender  |  VMS & WNT programmer9 > One OS to find them           | work: mv@pdv-systeme.de L > One OS to bring them all      |   http://www.pdv-systeme.de/users/martinv/@ > And in the Darkness bind them.| home: martin@radiogaga.harz.de  O We're looking into this problem. As soon as we have a better handle on it, I'll  post an update.    --
 Rick Barry  3 Compaq Secure Web Server (CSWS) - Development Group  Compaq Computer Corporation 
 Nashua, NH   ------------------------------  % Date: Mon, 16 Jul 2001 13:53:34 -0400 ! From: "Kevin" <NoSpam@compaq.com> H Subject: Re: CSWS / Apache 1.1 - how to specify userdirs with wildcards?2 Message-ID: <xSF47.760$rc5.60479@news.cpqcorp.net>  H ""Alan Winston - SSRL Admin Cmptg Mgr"" <winston@SSRL.SLAC.STANFORD.EDU>C wrote in message news:009FEEC5.4E0E7E67@SSRL04.SLAC.STANFORD.EDU...  > Comp.os.vmsers --  >  > It turns out that doing  > # > <Directory /$disk4/winston/www/ >  > L > will match the directory and all is well.  Server-side includes work fine. > 
 > However, >  > <Directory /$disk4/*/www/ >  > J > doesn't match that same directory, which seems counterintuitive at best. > E We were able to get it to work.  Assuming that a user called "JSMITH" " contains a default device "DEVICE"F and a default directory "[DIR]" in the AUTHORIZE file.  The HTTPD.CONF	 contains: B     1.  A "UserDir public_html" directive (default configuration).#     2.  The Directory directive is:   +         <Directory /DEVICE/*/public_html/ >              . . .          </Directory>  ? Note that the device name is in upper case.  A request for URL:   1     http://host.site.name.com/~jsmith/sample.html    Becomes:  (      /DEVICE/DIR/public_html/sample.html  H (By the way,we debugged it by setting the access rules to deny access so that we could see the access  failure in the ERROR_LOG. file.)  I We will look into changing the code to return a lowercase device name and  directory name for "/home". L As a temporary workaround, please try specifying an uppercase device name in you wildcard specification.   " We appologize for the inconvience.   Kevin D. O'Kelley $ COMPAQ Secure Web Server for OpenVMS OpenVMS Engineering    ------------------------------  % Date: Mon, 16 Jul 2001 17:37:14 +0200 2 From: "Dr. Otto Titze" <titze@ikp.tu-darmstadt.de>+ Subject: Re: DHCP on different Cluster Node 3 Message-ID: <3B530A2A.4FE2DBE1@ikp.tu-darmstadt.de>    Hi,   A because I was not able to run two DHCP Server(both members of the ; same LAVC) in the two segments because of the lock problem, > I tried to use only one but serving more then one segment. The? university computer center people bridged a broadcast for me on 
 their router.   A At the first glance everything looked fine, the server recognised > the client on the other segment and provided IP addresses. ButD looking closer the information about the standerd gateway was wrong.  A After a lot of tries and modifications I finally found that ordere5 in which the entries appear in DHCPCAP. is important.Q   node1:\v 	:gw=sub1:\		#gateway segment 1w 	:ha=MAC-addr:\v 	:ip=addr1:e node1-sub2:\ 	:gw=sub2:\		#Gateway segment 2y) 	:ha=MAC-addr:\		#the same for both nodesh 	:ip=addr2:o  6 In this case if I use the computer on sub1 it gets the+ gateways as sub2. If I reverse the order tou node1-sub2:\ node1:\r@ then the Gatway is correct in segment 1. But if I then place the6 computer on subnet 2 the it gets as gateway sub1 too. > Obviously the gateway is taken from the last entry in DHCPCAP.9 I tried a lot of different options like :rs=: or :rd=0/1:  but without success.  : Has anyone running DHCP on VMS and can give me a hint - at least what to try next?d   Regards    Otto,  -------------------------------------------, | Dr. Otto Titze, Kernphysik TUD           |, | Schlossgartenstr. 9, D-64289 Darmstadt   |, | titze@ikp.tu-darmstadt.de                |, | Tel: +49(6151)16-2916,FAX:16-4321        |,  -------------------------------------------   ------------------------------  % Date: Mon, 16 Jul 2001 14:59:17 +0100 4 From: "Chris Sharman" <chris.sharman@ccagroup.co.uk> Subject: Disk cluster sizeA Message-ID: <995291905.22338.0.nnrp-14.9e989e7e@news.demon.co.uk>g  I Now that I'm finally getting to VMS 7.2+ (still no sign of 7.3 CDs), what # cluster size should I be choosing ? H I know that smaller clusters are more space efficient for smaller files.L We keep our disks defragmented, and have a fairly large default extent (1000 blocks).A Is there a cost to smaller clusters in terms of I/O performance ?b2 Should I reduce cluster size to 1, or 4, or what ?   Thanks,  Chrisa   ------------------------------  % Date: Mon, 16 Jul 2001 10:50:50 -0400 5 From: David Beatty <David.Beatty@qwertysasasdfgh.com>  Subject: Re: Disk cluster size2 Message-ID: <rv5SO1Y5SYFe3b7Z2CzJygVUzUmQ@4ax.com>  F It depends.  If your files are a whole bunch of little files, you will@ conserve disk space by using a smaller cluster factor.  However,@ if you have a few large files, you will get better throughput by using a larger cluster factor.  B If you are using a database product (Oracle, for example.), it's aB good idea to set the cluster size to be a multiple of the database block size.5   David R. Beattye  3 On Mon, 16 Jul 2001 14:59:17 +0100, "Chris Sharman"t% <chris.sharman@ccagroup.co.uk> wrote:l  J >Now that I'm finally getting to VMS 7.2+ (still no sign of 7.3 CDs), what$ >cluster size should I be choosing ?I >I know that smaller clusters are more space efficient for smaller files. M >We keep our disks defragmented, and have a fairly large default extent (1000o	 >blocks). B >Is there a cost to smaller clusters in terms of I/O performance ?3 >Should I reduce cluster size to 1, or 4, or what ?o >n >Thanks, >Chris >  >c >i   ------------------------------    Date: 16 Jul 2001 10:14:30 +0100O From: pmoreau@dev.ath.cena.fr (Patrick MOREAU, CENA Athis, Tel: 01.69.57.64.40) 5 Subject: Re: DIVA errors caused by ES1888 sound card?w  Message-ID: <72bow09JBWW$@sable>  ^ In article <3B524A6F.31E37FA8@snet.net>, mike & cheryl marshall <tmarshall04@snet.net> writes:G > i have a 500PWS running VMS and i keep getting a string of DIVA errorsB > when i try to access DECsound. i'm assuming that it's probably a9 > configuration problem and i found info referencing to a ; > SYS$SYSTEM:SYSTEM.INI file...but i think that's VAX only?e  lN DECsound only works with the old Microsoft compatible sound card. With the newL Ensoniq card) you must use sys$system:mmov$decsound  (and you must have MMOV 2.2 installed).a   Patricki   --O =============================================================================== O pmoreau@cena.dgac.fr  (CENA)     ______      ___   _           (Patrick MOREAU)s4 moreau_p@decus.fr (DECUS)       / /   /     / /|  /|J CENA/Athis-Mons FRANCE         / /___/     / / | / |   __   __   __   __  N BP 205                        / /         / /  |/  |  |  | |__| |__  |__| |  |N 94542 ORLY AEROGARE CEDEX    / /   ::    / /       |  |__| | \  |__  |  | |__|N http://www.ath.cena.fr/~pmoreau/            http://www.multimania.com/pmoreau/O ===============================================================================e   ------------------------------  % Date: Mon, 16 Jul 2001 20:54:22 +0800u% From: "VMS Novice" <best@hotmail.com>$ Subject: ftp error0 Message-ID: <9iuo6h$qdf3@imsp212.netvigator.com>  K I am running VMS 7.2-1 with TCPIP 5.0A ECO-2 on Alpha 8400. Sometimes, whenoH there are about 20 - 30 ftp clients connected, the other new ftp clientsH connection will be rejected. I already set the max connection to 200 but this just doesn't help.r   Any advise?    ------------------------------    Date: 16 Jul 2001 10:53:52 +0200* From: eplan@kapsch.net (Peter LANGSTOEGER)( Subject: Re: Future of Alpha/VMS support* Message-ID: <3b52aba0$1@news.kapsch.co.at>  s In article <D0E37.7474$bj6.2367653@typhoon.ne.mediaone.net>, "Terry C. Shannon" <terryshannon@mediaone.net> writes: 1 >"Tom Adams" <tadamsmar@aol.com> wrote in message 8 >news:793af3df.0107130545.7c367a23@posting.google.com...8 >> How long will Compaq continue to make Alphas?  I know3 >> they will stop development in 2 years.   I don'tE5 >> see that they can continue hardware support unlesse! >> they keep building the boards.- >-I >DEC and then Compaq kept building VAXes for several years after the lastEL >enhancement to the VAX CPU. They produced a warehouse full o' VAX chips forL >this purpose. Compaq claims that it'll support Alpha through at least 2013;J >I suspect it'll be longer than that. Just as there were VAX customers whoK >kept buying VAXen in the Alpha era, there will be customers who'll want toa( >buy Alphas for quite some time to come.  D With the only exception, that there where technical/economic reasonsG to migrate from VAX to Alpha and there are now legal reasons. (from Q'seF point of view of course - the made a contract with INTEL where the endL of Alpha is part of the deal) Technical reasons can change => time can slip,D legal reasons cannot change because INTEL most likely won't agree...  @ Time will tell (how well the INTEL - Q contract is for Q and us)   -- M< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888S< <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------    Date: 16 Jul 2001 09:53:11 -0700+ From: yoav_lerner@hotmail.com (Yoav Lerner)w2 Subject: Re: Help ? Get OpenVMS screen data by ASP= Message-ID: <e85964ad.0107160853.166d46c6@posting.google.com>m   Hi,  Thanks for you help.E I will check it. Do you work with their software or know someone elsev that does ? it can help me.e Yoav.e  h dooleys@snowy.net.au (dooley) wrote in message news:<1ca82fc6.0107150648.430ee549@posting.google.com>..._ > "yoav lerner" <yoav_lerner@hotmail.com> wrote in message news:<3b516625@news.bezeqint.net>... 
 > > Hello,N > > I have a customer that has a COBOL application running on AlphaServer withG > > OpenVMS operating system, which works well. The customer is  reallySL > > satisfied from this system, but he wants to publish some screens of this > > application by the web.  > > O > > Does anyone know easy way to display OpenVMS screen data by the web?  Is itLE > > possible to access from ASP page (by the Vbscript) to the OpenVMS 9 > > application get the data and show it by the ASP page?n > >  Thanks,	 > > Yoav.' > K > www.wrq.com have a product called "web integrator" (or something similar)e > that should be worth a looks > phil   ------------------------------  # Date: Mon, 16 Jul 2001 06:46:24 GMTa. From: "mulp" <michaelpettengill@earthlink.net>  Subject: Re: IA64 Rocks My WorldC Message-ID: <45w47.6558$23.755392@newsread2.prod.itd.earthlink.net>   6 "Main, Kerry" <Kerry.Main@compaq.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF4AD7F06@kaoexc01.americas.cpqcorp.net...G > Imho, Compaq has chosen to take the post EV7 $'s that would have beendI > required to keep up with what was perceived to be a declining margin of K > difference in performance (and you can argue with the Eng folks that were K > involved if you want on that point) and instead focus on the upper layers  ofF > the solution ie. Building Servers, Operating Systems and Application > Integration.  I We would love to simply HEAR the engineering folk involved openly explain-K why Alpha can't stay ahead of IA64.  If they were involved in the decision,rK then three weeks should be sufficient to publish a statement explaining theS
 reasoning.  K > So, you can argue strategy all you want, but at the Compaq Exec level, itbG > appears it was determined that, in the future, there is likely bettersF > profits to be made in the upper levels of a solution ie. servers andL > application / operating systems integration than in the CPU chip business.  G As a Compaq stock holder I am very concerned about Compaq's profits.  I J haven't yet seen any explanation of how this will improve Compaq's profit.K Unless Intel is paying Compaq a royalty for each IA64 chip, which is highlypH doubtful, Dell is going to be better positioned to make a profit on IA64L than Compaq, while the same wouldn't be the case with Alpha.  Nothing CompaqJ announced has caused Wall Street to look more favorably on Compaq's future
 prospects.   ------------------------------  % Date: Mon, 16 Jul 2001 05:41:21 -0400e) From: "Neil Rieck" <n.rieck@sympatico.ca>-  Subject: Re: IA64 Rocks My World9 Message-ID: <hFy47.4653$oh4.578417@news20.bellglobal.com>   9 "mulp" <michaelpettengill@earthlink.net> wrote in message.= news:45w47.6558$23.755392@newsread2.prod.itd.earthlink.net...w   [snip]  K > We would love to simply HEAR the engineering folk involved openly explain C > why Alpha can't stay ahead of IA64.  If they were involved in the 	 decision,pI > then three weeks should be sufficient to publish a statement explainingt thee > reasoning.  K Yes and this document proves the engineering folk really believed Alpha wast better:o8 http://www.alphapowered.com/presentations/alpha_ia64.pdf  I > As a Compaq stock holder I am very concerned about Compaq's profits.  ItL > haven't yet seen any explanation of how this will improve Compaq's profit.F > Unless Intel is paying Compaq a royalty for each IA64 chip, which is highlyJ > doubtful, Dell is going to be better positioned to make a profit on IA64G > than Compaq, while the same wouldn't be the case with Alpha.  Nothing  CompaqL > announced has caused Wall Street to look more favorably on Compaq's future > prospects.  ; I believe that Capellas will be flamed by the shareholders.b  L p.s. In fact, I'm waiting for a general shareholder revolt in North America.I In Europe many countries have laws that make the corporate landscape look 7 quite different from the view on this side of the pond:l  C 1) 50% of the board of directors of any company must be composed ofcH rank-and-file employees (which prevents any exec from stacking the boardG with his buddies). This also means that CEOs can't implement half-bakeddJ ideas that may jeopardize a company's future. (look at Nortel; they decideL to focus only on optical networking because that's where the biggest profits> were, then that market hits the wall and so does Nortel stock)  L 2) the top dog can't make anymore than 20 times the wages of the lowest paidH employee. This makes execs very interested in employee happiness (ratherE than their own golden handshakes). Those board members also stay moreeJ interested in the health of their own company rather than trying to spreadL themselves across the boards of many. Note that some countries (like Japan I; think) have a 12-to-1 ratio which is even more restrictive.t  
 Neil Rieck Kitchener/Waterloo/Cambridge,D Ontario, Canada.! http://www3.sympatico.ca/n.rieck/a   ------------------------------  % Date: Mon, 16 Jul 2001 05:54:09 -0400n) From: "Neil Rieck" <n.rieck@sympatico.ca>.  Subject: Re: IA64 Rocks My World9 Message-ID: <iRy47.4654$oh4.581453@news20.bellglobal.com>g   $ say :== write sys$output $ arch = f$getsyi("ARCH_NAME") $ test = "Unknown"* $ if arch .eqs. "VAX"   then test = "good", $ if arch .eqs. "Alpha" then test = "better"+ $ if arch .eqs. "IA-64" then test = "yikes" + $ say "Architecture: ", arch, " (",test,")"   
 Neil Rieck Kitchener/Waterloo/Cambridge,h Ontario, Canada.! http://www3.sympatico.ca/n.rieck/    ------------------------------  # Date: Mon, 16 Jul 2001 12:56:30 GMT B From: Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP>  Subject: Re: IA64 Rocks My World7 Message-ID: <2wB47.20879$Kf3.261573@www.newsranger.com>h  . On Mon, 16 Jul 2001 05:41:21 -0400, in article@ <hFy47.4653$oh4.578417@news20.bellglobal.com>, Neil Rieck wrote: > : >"mulp" <michaelpettengill@earthlink.net> wrote in message> >news:45w47.6558$23.755392@newsread2.prod.itd.earthlink.net... >aL >> We would love to simply HEAR the engineering folk involved openly explainD >> why Alpha can't stay ahead of IA64.  If they were involved in the
 >decision,J >> then three weeks should be sufficient to publish a statement explaining >the
 >> reasoning., >uL >Yes and this document proves the engineering folk really believed Alpha was >better:9 >http://www.alphapowered.com/presentations/alpha_ia64.pdf  >   J What is the legal situation with people copying these pro-Alpha documents,H like the one above, and hosting them on their own websites provided thatK you identify the original source of the document ? If you are allowed to doeK this, then those people here with websites may wish to copy these documentsiH before some PHB in CPQ realises that they exist and orders them removed.  K When VMS went from VAX to Alpha, it was clear that it was a major technical,L improvement. These pro-Alpha documents, like the one above, that people keepL referencing, must be an unwelcome reminder to CPQ that the way the IA64 portJ was announced, at the expense of Alpha, is looking more and more politicalI and less technical. [It's a decade ago, but I don't recall hearing at the@K Alpha announcement that VAX was dead and no more work would be done. I seemoG to recall that there was a strong push to get Alpha established first.]c   Simon.   -- e; Simon Clubley, simon_clubley@remove_me.excite.com-Earth.UFPDK In the task of removing Microsoft from the marketplace, I have discovered aeE truly remarkable plan, but this signature is too small to contain it.m   ------------------------------  % Date: Mon, 16 Jul 2001 06:09:52 -0700 ! From: Tom Linden <tom@kednos.com>T  Subject: RE: IA64 Rocks My World9 Message-ID: <CIEJLCMNHNNDLLOOGNJIAEMDCPAA.tom@kednos.com>c  F It is on the compaq site, it is not copyrighted so it is in the public domain.*     > -----Original Message----- > From: Simon Clubley>7 > [mailto:simon_clubley@remove_me.excite.com-Earth.UFP]t% > Sent: Monday, July 16, 2001 5:57 AM. > To: Info-VAX@Mvb.Saic.Come" > Subject: Re: IA64 Rocks My World >s >l0 > On Mon, 16 Jul 2001 05:41:21 -0400, in articleB > <hFy47.4653$oh4.578417@news20.bellglobal.com>, Neil Rieck wrote: > >n< > >"mulp" <michaelpettengill@earthlink.net> wrote in message@ > >news:45w47.6558$23.755392@newsread2.prod.itd.earthlink.net... > >s? > >> We would love to simply HEAR the engineering folk involvede > openly explainF > >> why Alpha can't stay ahead of IA64.  If they were involved in the > >decision,L > >> then three weeks should be sufficient to publish a statement explaining > >the > >> reasoning.1 > > ; > >Yes and this document proves the engineering folk reallyr > believed Alpha was
 > >better:; > >http://www.alphapowered.com/presentations/alpha_ia64.pdf- > >t >.L > What is the legal situation with people copying these pro-Alpha documents,J > like the one above, and hosting them on their own websites provided that? > you identify the original source of the document ? If you arey > allowed to dopC > this, then those people here with websites may wish to copy theseg > documentsiJ > before some PHB in CPQ realises that they exist and orders them removed. >vC > When VMS went from VAX to Alpha, it was clear that it was a majord > technicalaB > improvement. These pro-Alpha documents, like the one above, that
 > people keepw@ > referencing, must be an unwelcome reminder to CPQ that the way > the IA64 portaL > was announced, at the expense of Alpha, is looking more and more politicalK > and less technical. [It's a decade ago, but I don't recall hearing at then@ > Alpha announcement that VAX was dead and no more work would be > done. I seemI > to recall that there was a strong push to get Alpha established first.]m >  > Simon. >h > --= > Simon Clubley, simon_clubley@remove_me.excite.com-Earth.UFP @ > In the task of removing Microsoft from the marketplace, I have > discovered aG > truly remarkable plan, but this signature is too small to contain it.o >r   ------------------------------    Date: 16 Jul 2001 10:10:01 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)-  Subject: RE: IA64 Rocks My World3 Message-ID: <SRi4GoDw+FfK@eisner.encompasserve.org>D  < Current US law (made compatible with international treaties)B holds that by default something is copyrighted unless specifically stated otherwise.   ] In article <CIEJLCMNHNNDLLOOGNJIAEMDCPAA.tom@kednos.com>, Tom Linden <tom@kednos.com> writes: H > It is on the compaq site, it is not copyrighted so it is in the public	 > domain.3 >  >  >> -----Original Message-----g >> From: Simon Clubley8 >> [mailto:simon_clubley@remove_me.excite.com-Earth.UFP]& >> Sent: Monday, July 16, 2001 5:57 AM >> To: Info-VAX@Mvb.Saic.Com# >> Subject: Re: IA64 Rocks My World. >> >>1 >> On Mon, 16 Jul 2001 05:41:21 -0400, in articleeC >> <hFy47.4653$oh4.578417@news20.bellglobal.com>, Neil Rieck wrote:t >> >= >> >"mulp" <michaelpettengill@earthlink.net> wrote in messageoA >> >news:45w47.6558$23.755392@newsread2.prod.itd.earthlink.net...a >> >@ >> >> We would love to simply HEAR the engineering folk involved >> openly explain G >> >> why Alpha can't stay ahead of IA64.  If they were involved in them
 >> >decision,tM >> >> then three weeks should be sufficient to publish a statement explainingd >> >the  >> >> reasoning. >> >< >> >Yes and this document proves the engineering folk really >> believed Alpha wasy >> >better:g< >> >http://www.alphapowered.com/presentations/alpha_ia64.pdf >> > >>M >> What is the legal situation with people copying these pro-Alpha documents,aK >> like the one above, and hosting them on their own websites provided that @ >> you identify the original source of the document ? If you are >> allowed to doD >> this, then those people here with websites may wish to copy these >> documentsK >> before some PHB in CPQ realises that they exist and orders them removed.s >>D >> When VMS went from VAX to Alpha, it was clear that it was a major >> technicalC >> improvement. These pro-Alpha documents, like the one above, thatn >> people keepA >> referencing, must be an unwelcome reminder to CPQ that the way  >> the IA64 portM >> was announced, at the expense of Alpha, is looking more and more political.L >> and less technical. [It's a decade ago, but I don't recall hearing at theA >> Alpha announcement that VAX was dead and no more work would be@ >> done. I seemcJ >> to recall that there was a strong push to get Alpha established first.] >>	 >> Simon.  >> >> --W> >> Simon Clubley, simon_clubley@remove_me.excite.com-Earth.UFPA >> In the task of removing Microsoft from the marketplace, I havef >> discovered a H >> truly remarkable plan, but this signature is too small to contain it. >> >  -- AN ==============================================================================N Great Inventors of our time: Al Gore -> Internet; Sun Microsystems -> ClustersN ==============================================================================   ------------------------------  % Date: Mon, 16 Jul 2001 17:05:16 +0100N0 From: andrew harrison <andrew.nospam@uk.sun.com>  Subject: Re: IA64 Rocks My World) Message-ID: <3B5310BC.3F418BD@uk.sun.com>R   "Main, Kerry" wrote: > 	 > Andrew,  > 0 > Hey, you are back to the old fud stuff again.. > @ > >>> You clearly don't understand the concept of relative size.M > Tru64/OpenVMS/NSK do generate billions of dollars of revenue for Compaq butm > Wintel generates more. >>> > K > And you clearly have no idea of how a business person thinks. Most of the=L > ones that I know think BILLIONS of dolars is a big thing no matter how you
 > look at it.0  ; Define a business person. Most business people that I know r7 would consider billions of dollars of revenue as being m5 significant but there is no external indication that  5 the business people we are talking about (Your board)o4 do. Does that mean that by your definition your own 2 management are not business people ?? you are on a slippery slope here.  = As I said earlier, all external indications show that Compaq  < has focussed its resources on Wintel and because of that it 9 is clear that your management despite your bluster don't - argee with you.e   regardso Andrew Harrisone Enterprise IT Architectt   ------------------------------  % Date: Mon, 16 Jul 2001 12:27:51 -0400t+ From: "Main, Kerry" <Kerry.Main@compaq.com>i  Subject: RE: IA64 Rocks My WorldR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4AD7F0C@kaoexc01.americas.cpqcorp.net>   Andrew,>  L >> As I said earlier, all external indications show that Compaq has focussedL its resources on Wintel and because of that it is clear that your management. despite your bluster don't argee with you. >>>  I Well, you are certainly free to state the standard Sun lines, but I would  disagree with them.i  J Btw, I love the way you twist stuff like "it is clear that your managementG despite your bluster don't argee with you." when you have absolutely nok supporting information.l   :-),  
 Kerry Main Senior Consultanta Compaq Canada Inc. Professional Servicesc Voice: 613-592-4660  Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----7 From: andrew harrison [mailto:andrew.nospam@uk.sun.com]e Sent: July 16, 2001 12:05 PM To: Info-VAX@Mvb.Saic.Comd  Subject: Re: IA64 Rocks My World       "Main, Kerry" wrote: > 	 > Andrew,, > 0 > Hey, you are back to the old fud stuff again.. > @ > >>> You clearly don't understand the concept of relative size.I > Tru64/OpenVMS/NSK do generate billions of dollars of revenue for Compaq1 but6 > Wintel generates more. >>> > K > And you clearly have no idea of how a business person thinks. Most of thepL > ones that I know think BILLIONS of dolars is a big thing no matter how you
 > look at it.-  ; Define a business person. Most business people that I know 07 would consider billions of dollars of revenue as being R5 significant but there is no external indication that e5 the business people we are talking about (Your board) 4 do. Does that mean that by your definition your own 2 management are not business people ?? you are on a slippery slope here.  = As I said earlier, all external indications show that Compaq 2< has focussed its resources on Wintel and because of that it 9 is clear that your management despite your bluster don't @ argee with you.>   regardse Andrew Harrisona Enterprise IT ArchitectL   ------------------------------  % Date: Mon, 16 Jul 2001 20:48:55 +0800c% From: "VMS Novice" <best@hotmail.com>  Subject: Re: Idle processt0 Message-ID: <9iuo6g$qdf2@imsp212.netvigator.com>  I Thanks for the info, but my problems is not just for the interactive job.OJ Sometime, we do some database backup, the batch run for serval hours, thenJ it just sit there without any increase in IO or CPU time, and there has noH increase in the tape drive error (which I assume it's not the tape driveJ that make it sit there). And I just don't know what this kind of resources$ are these processes are waiting for?  D Sometime, this may due to some log file are being allocated by otherJ process, and sometimes may be due to different reason. But how can I know?  9 "Robert Deininger" <rdeininger@mindspring.com> glMF news:rdeininger-1507011036130001@user-2ive78q.dialup.mindspring.com...? > In article <9irl0d$1en2@imsp212.netvigator.com>, "VMS Novice"o > <best@hotmail.com> wrote:h >oG > > If I have a process running for a long time without any IO with thec stateoC > > LEF, how can I trace what resource is this process waiting for?a >e9 > A little background.  Sorry if you already know this...h >pJ > LEF means "local event flag" wait.  That's the normal state of a processI > waiting for most any kind of I/O to complete.  When the event flag getsv > set, the process wakes up. >fI > So, for example, an interactive process waiting for the user to enter aw > command will be in state LEF.h >tI > It is possible for a process to be waiting for more than 1 I/O at once.sI > There is a "wait until any of these event flags is set" system service,  > for example. >rL > You can probably find what you need using ANALYZE/SYSTEM, but I don't knowG > enough to track down an arbitrary bizzare I/O off the top of my head.  >pJ > In a simple case, I have an interactive process waiting at the $ prompt.K > It's in state LEF.  If I do a SHOW PROCESS, I see that terminal VTA242 isa/ > allocated to this process.  In SDA, I can sayp >i > $ ANALYZE/SYSTEM > SDA> show dev vta242I > VTA242 ==> TNA261                              VT100               UCB:p 813BCEC0 >m0 > Device status:   00010110 online,bsy,deleteucb3 > Characteristics: 0C040007 rec,ccl,trm,avl,idv,odvo >                  00000200 nnmo >mF > Owner UIC [000100,000026]   Operation count        740   ORB address 81190C00F >       PID        001F001B   Error count              0   DDB address 81158FC0F > Class/Type          42/60   Reference count          2   DDT address 82D86AB8F > Def. buf. size         80   BOFF              00000180   CRB address 81159800F > DEVDEPEND        320013B0   Byte count        00000100   IRP address 81037E80I > DEVDEPND2        2902300C   SVAPTE            812D8D80   I/O wait queueh 813BCF2C8 > DEVDEPND3        00000000   DEVSTS            00000000 > FLCK index             3A  > DLCK address     82D3AA80a3 >                                 I/O request queues3 >                                 -----------------  >hC > STATE    IRP      PID   MODE CHAN  FUNC    WCB     EFN        AST4 > IOSB        STATUS >cJ >  C   81037E80  001F001B  E   0040  C000  00000000  29  FFFFFFFF.82DAE600 000000 > 00.7B12C0E0  8203w >         nop bufio,func,termion >s >t >iL > ... and I see that there is indeed 1 I/O in the queue for that device, and4 > it will set event flag (EFN) 29 when it completes. >AH > You can likely find some interesting info using SHOW PROCESS in SDA asI > well.  But unless you make your question more specific, I'll just referm > you to the SDA manual... >  > -- > Robert Deininger > rdeininger@mindspring.coms   ------------------------------  # Date: Mon, 16 Jul 2001 15:49:16 GMT 2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: Idle processl2 Message-ID: <02E47.748$rc5.59958@news.cpqcorp.net>  X In article <9iuo6g$qdf2@imsp212.netvigator.com>, "VMS Novice" <best@hotmail.com> writes:J :Thanks for the info, but my problems is not just for the interactive job.K :Sometime, we do some database backup, the batch run for serval hours, thenyK :it just sit there without any increase in IO or CPU time, and there has nonI :increase in the tape drive error (which I assume it's not the tape driveaK :that make it sit there). And I just don't know what this kind of resources % :are these processes are waiting for?l  E   Please check directly with the database vendor or database support.e  L   If I were GUESSING, I'd guess this application was waiting for a database    lock.   L   When posting questions, SPECIFIC DETAILS are critical.  Product names and J   versions, commands, OpenVMS platform and version, etc.  (Please see the K   introductory section of the OpenVMS FAQ for some of the sorts of details /G   that can be required.  Without these details, we get to play "twenty aI   questions" on the problem and -- as I have done here -- take some wild n4   guesses.  No offense is intended here, of course.)  E :Sometime, this may due to some log file are being allocated by otherlK :process, and sometimes may be due to different reason. But how can I know?e  H   You can take some partial steps toward this goal -- such as the use ofH   the Availability Manager (or AMDS) and SDA tools, the latter requiringG   knowledge of OpenVMS internals from the internals and data structuresaG   book and potentially access to the OpenVMS source listings -- toward  H   figuring out which of the zillions of potential causes for the currentI   process state.  In the absolute sense, you can't know this without also:M   reverse-engineering the application.  You really need to contact the folks m:   that have the source code and that know the application.  J   Tools such as Availability Manager (and AMDS) are quite good at looking E   for process quota problems and looking at current locking activity.2  J   If YOU have the application source code, then you will want to use toolsH   such as the OpenVMS debugger, application-integrated debugging, sourceK   code inspection, and similar.  (Availability Manager, AMDS, SDA callouts,b3   and other similar tools can be useful here, too.)   N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Mon, 16 Jul 2001 09:58:48 -0400o# From: Jim Agnew <Agnew@hsc.vcu.edu>t# Subject: Re: Is there a WASD forum?u+ Message-ID: <3B52F317.93186004@hsc.vcu.edu>t  4 won't work on 5.5-2..???? tell my webserver that....   Doug Mallory wrote:l   > "D.Webb" wrote:o >ei > > In article <3B4F2086.6BEDC582@Pachacamac.com>, Didier Morandi <Didier.Morandi@Pachacamac.com> writes:e > > >D.c > > >iI > > >PS: In case you do not know WASD, it *is* the ultimate VMS based WEBpJ > > >server, made in seven years :^) by a VMS expert for VMS, allowing CGI > > >scripting with... guess...  > > >l > > >o > > >DCL > > >  > > >d
 > > >(yes) > > >o" > > >Here: http://wasd.vsm.com.au/ > >e8 > > I thought that was the OSU Decthreads server      :) > > ; > > ( http://kcgl1.eng.ohio-state.edu/doc/serverinfo.html )t > >D > > David Webb > > VMS and unix team leader > > CCSS > > Middlesex University > k > WASD is the best I have seen! OSU will not work on VMS 5.5-2 on a vax, but WASD will! It will work on anyo& > VAX/AXP VMS level that I have tryed.a > I correctly run it on a microvax 3100 10e under 6.2 no problem! And yes.. DCL cgi scripting...!C   ------------------------------  # Date: Mon, 16 Jul 2001 14:49:18 GMTo2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: Motif Upgrade?l2 Message-ID: <O9D47.744$rc5.59804@news.cpqcorp.net>  m In article <mvO37.43341$B5.9812771@news1.rdc1.tn.home.com>, "Brian Shafer" <brian.shafer123@home.com> writes:W  K :I am new to motif. We use 1.2 in a xwindows enviorment, progamming is donehL :on a Alpha Workstation running OpenVMS. I would like to upgrade the version4 :of Motif, but don't know where I would buy it from.  F   From Compaq directly, or from an authorized Compaq reseller.  (As itI   appears you are located in North America, call 1-800-OK-Compaq or your wH   Compaq reseller -- country-specific information and lists of resellersG   are available at the Compaq website, and there is a "buy" link at thex,   OpenVMS (www.openvms.compaq.com) website.)  C   As of this writing, DECwindows Motif (CDE) V1.2-6 is the current p6   release, and included on the OpenVMS Alpha V7.3 kit.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------    Date: 16 Jul 2001 11:16:32 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)w Subject: Re: Motif Upgrade? 3 Message-ID: <3GE+GIJnNEbL@eisner.encompasserve.org>n  g In article <O9D47.744$rc5.59804@news.cpqcorp.net>, hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes: o > In article <mvO37.43341$B5.9812771@news1.rdc1.tn.home.com>, "Brian Shafer" <brian.shafer123@home.com> writes:e > M > :I am new to motif. We use 1.2 in a xwindows enviorment, progamming is done N > :on a Alpha Workstation running OpenVMS. I would like to upgrade the version6 > :of Motif, but don't know where I would buy it from. > H >   From Compaq directly, or from an authorized Compaq reseller.  (As itK >   appears you are located in North America, call 1-800-OK-Compaq or your mJ >   Compaq reseller -- country-specific information and lists of resellersI >   are available at the Compaq website, and there is a "buy" link at the-. >   OpenVMS (www.openvms.compaq.com) website.) > E >   As of this writing, DECwindows Motif (CDE) V1.2-6 is the current y8 >   release, and included on the OpenVMS Alpha V7.3 kit.  H I think when people talk in general about upgrading the version of MotifF from 1.2, they mean to 2.0 or 2.1 where widgets are portable.  Only inD the limited VMS arena is 1.2 the "latest".  According to the SolarisB newsgroup, Sun currently defaults to 2.1 and provides for backward( compatibility a copy of the 1.2 library.   ------------------------------   Date: 16 Jul 2001 16:43:49 GMT! From: Mark Hatch <mhatch@ics.com>m Subject: Re: Motif Upgrade? ' Message-ID: <3B5319C1.C136F721@ics.com>>   Hoff Hoffman wrote:C   > <snip> > D >   As of this writing, DECwindows Motif (CDE) V1.2-6 is the current8 >   release, and included on the OpenVMS Alpha V7.3 kit. >o	 >  <snip>e  j We're in the process of beta testing the next release of our GUI Builder for Motif so we're getting *very*. familiar with Motif 1.2 vs Motif 2.1 issues...  p On every other platform we support (AIX, IRIX, Solaris, HP-UX, Linux), the default version of Motif is 2.1. Onlye on OpenVMS and Tru64 are we forced to use Motif 1.2. As a result, we'll be forced to ifdef a bunch ofoo functionality out to support the Compaq platforms. For example, we can't port ViewKit 2.1 (ViewKit is a GUI C++ih library used by many SGI customers such as Disney, Dreamworks, Boeing, etc.) to Motif 1.2 based systems.  ^ That's enough of a pain, to push Compaq to the end of the list for the rollout of the release.  o Although few people are as Motif dependent as a Motif GUI builder, there is enough differences that other ISV's ? may be making similar decisions in terms of porting priorities.s   Mark   ------------------------------  % Date: Mon, 16 Jul 2001 12:34:43 -0400B# From: Mark Vance <mvance@iglou.com>o0 Subject: Multinet NFS client and Linux Problems.( Message-ID: <3B5317A3.7010804@iglou.com>  H Help!  Im trying to make my little 3100 with vms 7.1 and Multinet write H files to my Linux box.  I keep getting Write errors and incompatability I errors...  I can read files off that linux box with the 3100, but i cant  F write to them.  I have set the privs up in linux exports, and set the E uic tranlastion in Multinet.   Is there some qualifiers i should use  . when I Nfsmount the linux drive with multinet?    H Thanks!  If possible  please REPLY ALL, so a copy of your astute answer - can show up in my box too, in case i miss it.m  I This is a fine newsgroup, BTW.  Very informed poeple here.  Thanks again!e   ------------------------------  # Date: Mon, 16 Jul 2001 15:39:40 GMTy2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)D Subject: OpenVMS IPF Console (was: Re: Full port of VMS to Itanium.)2 Message-ID: <0VD47.746$rc5.60008@news.cpqcorp.net>  u In article <Nht47.7448$JS2.851399@newsread1.prod.itd.earthlink.net>, "mulp" <michaelpettengill@earthlink.net> writes:=  J :Experience with existing Intel systems is about the only information thatL :anyone has about commodity Intel system and existing Intel consoles are notK :exactly compatible with VMS.  Management over a serial line or perhaps viaiL :TELNET is certainly an expectation and lack of such an interface is hard toK :imagine being viable.  Even with a custom console, Windows on MIPS, Alpha,.L :and PowerPC was a GUI with far less capable than the existing Alpha console" :that it replaced or supplemented.  K   I and others here in OpenVMS have been working with the Compaq folks that *   are directly working on the IPF console.  D :If we can be assured that the standard IA64 console will support...  I   Members of the Compaq IPF console team are very well aware of what the oE   SRM can and does do, and of (at least the core of) the console, um,h!   "expectations" made by OpenVMS.l   :for example< :    >>>sho dev    ! enumerate all the devices on the system4 :    >>>sho config    ! sho the device configurationD :    >>>boot -fl 1,2,3 dka100   ! boot from any device on the systemJ :    >>>boot -proto mop -fi isl_ia64 eia0  ! boot from the network using a ..    H   This is a trade-off, of course: any hard requirement for a custom or aL   partially customized console in the IPF hardware would cause some concern K   for some of the regular participants here in the comp.os.vms newsgroup.  rH   Though having access to customized features or console extensions (andK   as transparently as possible) would obviously be very beneficial to folks "   and beneficial for many reasons.    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Mon, 16 Jul 2001 15:27:55 GMTn2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)K Subject: Re: OpenVMS on IPF (was re: IPF already needs a face-lift for VMS)r2 Message-ID: <%JD47.745$rc5.59664@news.cpqcorp.net>  | In article <yb047.19431$Kf3.251042@www.newsranger.com>, Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP> writes:O :The question now becomes: Are we going to see a decrease in VMS cross platformdI :compatibility when VMS is implemented on IPF, because limitations in theeK :IPF architecture forces design tradeoffs that VMS has not had to deal with  :until now ?  J   This is a very early (premature?) time in the project to answer such an -   open-ended question, but I'll try anyway...o  K   I am not aware of anyone here in OpenVMS Engineering that has encounteredaI   any IPF features or behaviours that will force changes the visible (andaJ   documented and supported) user-mode APIs of OpenVMS in any incompatible J   or unexpected fashion -- we are presently and very specificially looking   for these, too.c  J   If you have user-mode application source code using documented features K   and interfaces -- and code that is free of latent bugs -- it should port pK   across quite nicely and quite easily.  (The target for the IPF effort is nJ   full application user-mode source-code compatibility.  Recomile and go.)  J   Those few hunks of application source code that are using undocumented, J   unsupported, or hardware- or architecture-specific features are at some I   level of risk and may require some changes, of course -- these are the mJ   same issues that have been known for many years, and that have been wellG   publicized for many years, and these same risks already arise within eJ   existing OpenVMS environments such an OpenVMS upgrade.  But in general, G   we (OpenVMS) want to see user-mode application code recompile and go.n  K   That said, OpenVMS Engineering will likely also take this opportunity to hI   "break" certain very specific things within the existing *kernel* APIs oK   in new (and hopefully beneficial) ways and will have to make kernel-mode  G   changes specifically for IPF platforms.  Similar to the VAX-to-Alpha cH   platform work, customers and OpenVMS Engineers do have a selection of H   changes that are desirable in the kernel APIs, but (for compatibility F   reasons) are infeasible within a particular platform.  Further (and H   stating the obvious), like the hardware and architectural differences D   between VAX and Alpha, the IPF architecture work will require someF   number of kernel-mode differences within OpenVMS and within at least%   some user-written kernel-mode code.c  L   I'd expect to see the platform-compatibility documentation made available K   as part of the earliest documentation work -- information for this manualII   is being collected right now.  There will be a focus on both user-mode fK   coding differences -- we will have new IPF-related itemcodes and new IPF  L   system names for calls such as $getsyi, for example -- and on any changes J   made to any documented kernel-mode APIs -- I'd like to see a centralized@   kernel-mode call to get the system time and TDF, for instance.  C :I wonder what other IPF "features" are waiting to be discovered...n  !   We are looking for these now...r    N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Mon, 16 Jul 2001 17:01:43 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-),K Subject: Re: OpenVMS on IPF (was re: IPF already needs a face-lift for VMS)00 Message-ID: <009FF17F.ED173243@SendSpamHere.ORG>  g In article <%JD47.745$rc5.59664@news.cpqcorp.net>, hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes:e} >In article <yb047.19431$Kf3.251042@www.newsranger.com>, Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP> writes: P >:The question now becomes: Are we going to see a decrease in VMS cross platformJ >:compatibility when VMS is implemented on IPF, because limitations in theL >:IPF architecture forces design tradeoffs that VMS has not had to deal with
 >:until now ?  >KK >  This is a very early (premature?) time in the project to answer such an  . >  open-ended question, but I'll try anyway... {...snip...}  K There are fundamental bits of VMS that require hardware support.  Alpha wasEK not able to accomodate these bit without the clever use of PALcode.  Hurray 
 for Alpha.  J What is to happen, for example, with something as fundamental as queue in-K sertion or removal?  I'm sure something *this* basic has been tossed about u in discussions of this effort.  > Just what things trouble you so that you wish to *break* them?   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMe            nJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbes-   ------------------------------  % Date: Mon, 16 Jul 2001 13:44:35 -0400s5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>-K Subject: Re: OpenVMS on IPF (was re: IPF already needs a face-lift for VMS).2 Message-ID: <3KF47.759$rc5.60466@news.cpqcorp.net>  0 Brian Schenkenberger, VAXman- wrote in message \ >    Snip    K >What is to happen, for example, with something as fundamental as queue in- K >sertion or removal?  I'm sure something *this* basic has been tossed aboutt >in discussions of this effort.p >r    H Sure.  They range from making them system calls (not highly favored), toD using an instruction that will trap (pehaps a reserved opcode, maybeF something like "break").  Some things might be possible as inline codeJ sequences, depending on if the failure semantics can be correctly handled.   ------------------------------  % Date: Mon, 16 Jul 2001 10:28:54 -0500D: From: "Pedro A. Crespo" <pedro.crespo@integris-health.com> Subject: Re: PAWZ and ECP -i/ Message-ID: <9iv0d2$5s$1@news-central.tiac.net>n  ? "Robert Deininger" <rdeininger@mindspring.com> wrote in messagebF news:rdeininger-1307011212130001@user-2iveal6.dialup.mindspring.com...5 > In article <7eT6V5OdCRZ9@eisner.encompasserve.org>,m< > Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) wrote: >  >mI > > > But you should REALLY ask that question of your account rep's BOSS.s > > J > > Only if you had a valid case.  That requires waiting at least 24 hoursJ > > after you hear it from Sue.  Please don't complain about small gaps inB > > timing -- they will just take it as a cue to make Sue shut up. >gJ > Very good point.  I really doubt all the alpha --> intel problems peopleJ > are howling about here are actually critical to anyone in the near term.I > PAWZ is probably similar.  Folks can afford to wait a day (week, month). > before going wild. >y  J Oh? Maybe on the Alpha-->Intel issue, yes (I'll give you that one) but NOTI on the PAWS stunt (Polycenter all over again) --- especially when WE JUSTo PURCHASED IT!!!.  F We've been trying to purchase it for months now but for some reason or anotheroJ buying the product itself was painful (so we took our time with the demo). OnceH we agreed that it was what we wanted (we had seen it at CETS2000) and weI asked for a quote... well, let's just say that it was the most convolutede quote we'vemL ever seen - our reseller (Pioneer) had to put together a spreadsheet to make senseuE of it --- that's a different story, but it should have tipped us off.-  . Any bets on how long before CPQ sells off VMS?  I [note - I don't normally post here (used to many years ago) but I am very- much a VMS fan]   Pedro A. Crespo- Integris Health- Oklahoma City, OK USA    ------------------------------   Date: 16 Jul 2001 13:10:56 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)0 Subject: Re: RA7x series disks+ Message-ID: <9iup50$olf$1@info.cs.uofs.edu>   L In article <rdeininger-1507011229490001@user-2ivea94.dialup.mindspring.com>,5  rdeininger@mindspring.com (Robert Deininger) writes:e
 |> In article"I |> <Pine.LNX.4.10.10107140939500.15523-100000@triangle.cs.uofs.edu>, Billa' |> Gunshannon <bill@cs.uofs.edu> wrote:s |>  I |> > Does anyone have any RA7x (RA70, RA71, RA72 or even RA73) disks they J |> > are wanting to get rid of??  I have recently received a VAX-3500 withH |> > a KDA50 and one dead RA70 in it.  I would like to revive it without |> > hangin it on an RA80. |>  M |> I have a dead (head-crashed) RA7x drive you could have.  You might be ablecK |> to get some useful parts off of it.  If your drive has good innards, butrH |> bad electronics, you might be able to make one work by combining two.  E Any chance you could pull the electronics off and just send me that??n  I Maybe you could answer a question or two to help me diagnose the problem. F Are the error codes displayed by the front panel leds the same as the ? lights on an RA80/81??  If so, what is a "master/Slave error"??-  G The disk seems to spin up OK,  When it reaches full speed it faults andfG shuts back down.  based on t his, I assume it is likely electronics andeG not mechanics.  There isn't by any chance a physical lock that may have4H been set by the previous owner that is not obviously visible, is there??   |> r  |> > Any offers gladly accepted. |> 2J |> Heavy beasties.  You'd have to pay the postage.  I expect you'll find a+ |> working drive for less money and hassle.i  L Money??  What money??  I can deal with hassle, but not the money issue.  :-(   Thanks.    bill   -- oJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------  # Date: Mon, 16 Jul 2001 14:53:09 GMTg7 From: moroney@world.std.spaamtrap.com (Michael Moroney)s5 Subject: Re: Shadowing drives with different geometry-& Message-ID: <GGKMoL.J2M@world.std.com>  & Lee Y T Mah <lytmah@cha.ab.ca> writes:  B >Does anyone know when the ability to shadow drives with differentI >physical geometry will  be available?  I checked with Compaq Support and-( >the reply is that it is not in VMS 7.3.  H Shadowing drives with different geometries has been in VMS since V7.1 orD V7.2.  Shadowing drives with different _sizes_ is not yet available.   -Miker   ------------------------------    Date: 16 Jul 2001 19:19:19 +0200* From: eplan@kapsch.net (Peter LANGSTOEGER)* Subject: Re: SHOW USER/FULL changed output* Message-ID: <3b532217$1@news.kapsch.co.at>  k In article <pNs37.6664$JN6.1121521@news1.rdc1.mi.home.com>, "Dave Pampreen" <davepampreen@home.com> writes:rI >Greetings,  did something change in the SHOW USER/FULL command.  Here isa >what it used to look like: 7 >     OpenVMS User Processes at 12-JUL-2001 22:09:10.60v8 >    Total number of users = 1,  number of processes = 1 >.+ > Username Process Name    PID     TerminaltL > ISLEY_L  ISLEY_L       0011A532  TNA4207:   (Host: alp141.gknai.com  Port: >1141) >0" >Here is what is looks like today.7 >     OpenVMS User Processes at 12-JUL-2001 22:09:10.60e8 >    Total number of users = 1,  number of processes = 1 >b+ > Username Process Name    PID     Terminalm+ > ISLEY_L  ISLEY_L       0011A532  TNA4207:gK >               (Host: alp141.gknai.com                               Port:n >1141) >S+ >(note the spaces and 2 lines instead of 1)i >eE >My system is:  VMS 7.2-1, TCPIP V5.0A - ECO3 on an AlphaServer ES40.oL >I don't have the exact day it changed, but it could be near the time when IJ >put the patch:  DEC AXPVMS TCPIP_ECO V5.0-113   on the system but I'm not >sure. >e >Has anyone seen this?  G Yes. I then did a "reset terminal" (at my DECterm) to fix the tabulator 4 positions (at every 8 columns) and all was ok again.  C Some garbage (containing escape sequences) sent to the screen coulds influence your DECterm setup...    -- >< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888V< <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------  # Date: Mon, 16 Jul 2001 13:56:18 GMT ' From: Colin Blake <colin@theblakes.com>n" Subject: Re: Small Mozilla request- Message-ID: <3B52F235.2A3787F2@theblakes.com>t  E The file name mangling that goes on inside Mozilla is the same as theiD Java file name mangling (only the logical name used to control it isH different). You should be able to get the behaviour you want by definingG the logical VMS_FILENAME_OPTIONS.  You want to turn OFF both the "multihE dot in file" options. See [SYSHLP.JAVA]JAVA$FILENAME_CONTROLS.COM forl details.  4 Note that if you change some of the options, such asH HIDDEN_WITH_UNDERSCORE, then you'll have to rename some of your existingD profile directory/file names (or just create a new profile directory tree).   ------------------------------  # Date: Mon, 16 Jul 2001 06:23:05 GMTm. From: "mulp" <michaelpettengill@earthlink.net>- Subject: Re: Terry Shannon Tech Talk on IA-64 C Message-ID: <dLv47.6542$23.756687@newsread2.prod.itd.earthlink.net>0  @ "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message, news:J2G37.693$rc5.47437@news.cpqcorp.net...K > I know in other forums/threads you have argued that IA64 will not replace I > the IA32.  I tend to disagree.  I think that Intel and MS will push thea IA64K > down into the IA32 market.  Face it - nobody needed or wanted Windows 98,i orF > even W2K, or worse WXP, I'm still running W95 (grudgingly from W3.1) becauseu  H People did want Win2k and they wanted Win98 because those releases fixedJ bugs in WinNT and Win95, especially in regard to plug and play, USB, powerJ management.  There were at least 4 versions of Win95 plus numerous specialK updates from both Microsoft and system vendors.  WinNT was worse than Win95RG when it came to plug and play devices, etc.  Win2K brought NT almost top parity with Win98.  K ME seems to be a big step backward, mostly because some Win9x features havee@ been removed and lots of unreliable baggage have been heaped on.  I And of course, Win2K was supposed to eliminate the need for Win98 and ME.e  H Acceptance of XP remains to be seen.  Will it really deliver where Win2K failed?n  E Resistance to P4 has been high, and that is with Intel cutting prices K substantially and providing free or highly discounted RDRAM.  P4 acceptance G has been much slower than any preceding generation of Intel IA32 chips.   F My sense is that Intel was desperate to kill off at least one of IA64s competitors.  K As expensive as Alpha systems are relative to IA32 systems, they would have L been cheaper than IA64 systems for some time to come.  Even with API/SamsungK increasing the price on Alpha systems (the forward price of Alpha just wenteI up), Alpha systems will still be cheaper for some time.  And Alpha is the E only alternative to IA32 for commodity systems; PowerPC and Sparc areeK limited to Apple, IBM, and Sun.  The Beowolf market today seems to be Alpha>K and Athlon based clusters.  By effectively killing Alpha, this eliminates a H significant number of players who can build non-Intel 64 bit processors.K This also attacks Cray, which was using Alpha for some of its supercomputerr
 solutions.  G Perhaps Compaq supporting IA64 is a benefit to Intel, but I suspect theaI value to Intel isn't as high as it might seem.  If Compaq abandons Tru64,rJ Intel doesn't lose much since there will be multiple versions of Linux and> Compaq has already donated a lot of the cluster tech to Linux.  L What does Intel lose if Compaq drops plans to port VMS to IA64?  It probably saves money.   ------------------------------  % Date: Mon, 16 Jul 2001 06:19:57 -0400 ) From: "Neil Rieck" <n.rieck@sympatico.ca>F- Subject: Re: Terry Shannon Tech Talk on IA-64-9 Message-ID: <udz47.4660$oh4.585865@news20.bellglobal.com>-  9 "mulp" <michaelpettengill@earthlink.net> wrote in messagea= news:dLv47.6542$23.756687@newsread2.prod.itd.earthlink.net...  >,J > People did want Win2k and they wanted Win98 because those releases fixedL > bugs in WinNT and Win95, especially in regard to plug and play, USB, powerL > management.  There were at least 4 versions of Win95 plus numerous specialG > updates from both Microsoft and system vendors.  WinNT was worse thane Win95.I > when it came to plug and play devices, etc.  Win2K brought NT almost toc > parity with Win98. >rH > ME seems to be a big step backward, mostly because some Win9x features haveB > been removed and lots of unreliable baggage have been heaped on. >wK > And of course, Win2K was supposed to eliminate the need for Win98 and ME.  >aJ > Acceptance of XP remains to be seen.  Will it really deliver where Win2K	 > failed?n >eG > Resistance to P4 has been high, and that is with Intel cutting prices B > substantially and providing free or highly discounted RDRAM.  P4
 acceptanceI > has been much slower than any preceding generation of Intel IA32 chips.- > H > My sense is that Intel was desperate to kill off at least one of IA64s > competitors. >pH > As expensive as Alpha systems are relative to IA32 systems, they would haveB > been cheaper than IA64 systems for some time to come.  Even with API/SamsungaH > increasing the price on Alpha systems (the forward price of Alpha just wentK > up), Alpha systems will still be cheaper for some time.  And Alpha is theuG > only alternative to IA32 for commodity systems; PowerPC and Sparc arecG > limited to Apple, IBM, and Sun.  The Beowolf market today seems to be  AlphaaK > and Athlon based clusters.  By effectively killing Alpha, this eliminatesn aeJ > significant number of players who can build non-Intel 64 bit processors.? > This also attacks Cray, which was using Alpha for some of itsa
 supercomputerd > solutions. >l  I I agree with most of this but believe that IA-32 will be with us for some K time to come. First off, I'm hearing from most people that their 500 to 800hL MHz Pentium systems are fast enough. Unless a new wave of bloatware hits theL market, no one will be upgrading to faster systems. Also, big businesses areH notoriously cheap (that's how they became successful). My employer stillF requires that many employees use vanilla Pentiums running Windows-95a.  K Second of all, IA-64 chips cost between US$2400 and US$4200 in lots of 1000eH (so this is a wholesale price). Almost every (non-server) Pentium systemG retails for under US$2000 so no one is going to fork out more money forwF IA-64 which is essentially an unproven technology at this point. (manyH technical documents state that Intel's EPIC technology will only improveH instruction execution after a recompile while EV7's SMT technology couldK discover parallelism in existing Alpha code. Of course for Alpha to replaceoL IA-64 in this special case "transition market" the legacy code would have to% be native Alpha and not native x86.).i  
 Neil Rieck Kitchener/Waterloo/Cambridge,d Ontario, Canada.! http://www3.sympatico.ca/n.rieck/c   ------------------------------    Date: 16 Jul 2001 08:50:46 -0500+ From: young_r@encompasserve.org (Rob Young)n- Subject: Re: Terry Shannon Tech Talk on IA-64t3 Message-ID: <epmTYhdktxbV@eisner.encompasserve.org>F  R In article <9iogve$310$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> writes: > : > "Rob Young" <young_r@encompasserve.org> wrote in message/ > news:RmB3aoAe3vkl@eisner.encompasserve.org...eM >> In article <9inp09$6c8$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com>r	 > writes:o >> >E >> > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in messagee1 >> > news:J2G37.693$rc5.47437@news.cpqcorp.net...- >> >> >) >> >   I think you underestimate how muchM% >> >> they can push the speed of IPF.n >> >H >> > And exactly what information do you base that on?  Does it take the
 > existing- >> > clocking problems IA64 has into account?n >>" >>         Re: "Clocking Problems"@ >> You must mean Itanium, aka Merced.  A senior circuit designer< >> put it to me that he was totally shocked in February whenI >> Intel pointed out that McKinley was/is at 1.4 GHz.  Don't be surprisedrE >> if McKinley comes in higher.  And yes, I have been sitting on thatM0 >> tidbit for a while (the shock of it all!) ;-) > M > Perhaps he had good reason to be shocked:  in the abstract for a subsequentfN > paper, the speed had been reduced to 1.2 GHz.  And then the paper itself was3 > withdrawn, making even that number a bit suspect.  >   2 	Yep... keeping 1.4 GHz for themselves it appears.   >>E >> http://www.intel.com/pressroom/archive/speeches/pso20010227idf.htmh >>& >> > Does it allow for the differencesJ >> > between the architectures Intel has successfully speeded up and EPIC? >>4 >> Which architecture hasn't Intel speeded up?  This1 >> much we know... Merced was Dead to begin with.h > 4 > Gee.  For the longest time, Merced was 'da man'.    ? 	Never.  For anyone following this story for more than a couple-B 	years it was "obvious" to more than a few -- 3+ years ago -- that= 	Merced would suck, that Merced was Dead..... so much so thato: 	Henrik offered a bottle of champagne to any taker-uppers:  2 From: Henrik Klagges (henrik@strategypartners.com)1  Subject: Bottle of Champagne IA64 bet taken :-) 1  Newsgroups: comp.arch  Date: 1998/10/22   A Bet taken! One small bottle of decent champagne that the fastest wG available Intel IA32-processor beats the first IA-64 Merced on SPECint 5E when the first Merced ships. Bet includes normal freight to were you a (or I) are.n   Cheers,a
     Henrik   --   Henrik Klagges - IT Analystn henrik@strategypartners.comi PGPKey available on requestt   ---h  > 	But to speculate that Intel can't speed up EPIC is inaccurate< 	at best.  If they *only* hit the publically stated 1.2 GHz,A 	that is a 50% increase over Itanium One.  Also, latency clean-up ? 	and other improvements have them going from 370 SpecInt2000 toh@ 	1000+ SpecInt2000 making McKinley fairly competitive and a much3 	better gauge of the speed-up, nevermind frequency.-     > It was only well afterJ > software had been running on it for quite a while that it became obviousJ   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^N > that it was never going to get near the targets set for it.  So now McKinley<   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^4 > is 'da man', at least until we find out otherwise. >   ? 	Nope, not at all.  Again , more than a few "knew" Merced wouldn@ 	suck at integer, not just Henrik and not just "after the fact."   				Robn   ------------------------------  % Date: Mon, 16 Jul 2001 11:48:13 -0400i+ From: "Main, Kerry" <Kerry.Main@Compaq.com>r- Subject: RE: Terry Shannon Tech Talk on IA-64 R Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4AD7F0B@kaoexc01.americas.cpqcorp.net>  
 Ahhh Bill,  : The emotional side always brings out the nice side of you.   :-)b  G >>> As I said three weeks ago when you immediately started spinning viabL email on Compaq's behalf on the day of the announcement, reversing virtuallyH every position you had up until that time held on Alpha superiority over
 IA64 ..<<,  G Since when did I state that Alpha was not a superior technology today?    L This is a great example of you twisting other peoples words to suit your own	 purposes.   I >>> But instead of even causing you to reexamine what you're saying (even J after being given specific reasons why it's asinine), you just keep saying it.>>>  F Or rather ignoring it (and a good deal of your other "teachings") as IJ personally do not agree with your conspiracy theories. But you are free to express whatever you feel like.i  H >>> Gee, you seem happy to point out Compaq statements about this:  whatK part of my asking for something equivalent from Intel - the party with 100%e8 control over this decision - do *you* not understand?<<<  I Perhaps the part that says "Its an official web site presentation. If you-I want more from Intel, why are you not asking Intel for this information?"s   Regards,  
 Kerry Main Senior Consultant7 Compaq Canada Inc. Professional Servicesn Voice: 613-592-4660n Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----, From: Bill Todd [mailto:billtodd@foo.mv.com] Sent: July 15, 2001 6:29 PMX To: Info-VAX@Mvb.Saic.Com1- Subject: Re: Terry Shannon Tech Talk on IA-64o      6 "Main, Kerry" <Kerry.Main@compaq.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF4AD7F09@kaoexc01.americas.cpqcorp.net... >?L > >>> You did, indeed - multiple times, and well after I'd told you you were > wrong.>>>l > F > Excuse me Lord Bill, I did not know you were were the referee of all thingsA > right and wrong. I will be sure to remember that in the future.o  L Since you've never yet been right when we disagreed, you should have learnedL it already.  But instead of even causing you to reexamine what you're sayingI (even after being given specific reasons why it's asinine), you just keepn
 saying it.  L As I said three weeks ago when you immediately started spinning via email onI Compaq's behalf on the day of the announcement, reversing virtually everysL position you had up until that time held on Alpha superiority over IA64, youJ have all the earmarks of a completely-bought-and-paid-for corporate whore.> That may be your job, but don't expect to be respected for it.  K That VMS presentation you've pointed customers to is a real piece of work -vH right up to your own spin standards.  Let's see how customers feel aboutB Compaq's provision of "unparalleled investment protection" via itsL IA64-replaces-Alpha strategy compared with IBM's Power-*plus*-IA64 strategy.G And people should note the fine but significant distinction between theiG slide that says "The Essence of Alpha *Systems* Continues!" (in systems K using Itanium cores) and your contention that anything significant from then* Alpha core will be incorporated into IA64.   The next slide is even better:  L "SECURES a stable, long-lasting commitment with a clear path to the future."G Just like Compaq assured people Alpha had, until last month.  Have theysK posted some kind of performance bond this time, since their word is clearly.
 worthless?  K "PRESERVES all the enterprise characteristics of OpenVMS solutions that youaI depend on today."  Except for the processor architecture, its leadership,lD and the resulting product differentiation that - with any reasonableL marketing effort, which there's still no reason whatsoever to expect - couldB have made VMS unassailable in at least those market segments where6 'industry-standardness' was not a major selling point.  F "PROVIDES complete investment protection."  If you don't consider yourJ existing Alpha infrastructure to be an investment, I guess.  And if you'reI willing to take Compaq's word for VMS's future - especially after the hito it's taking right now.  K "ACCELERATES OpenVMS Renaissance by focusing Compaq's future investments onRK delivering a more robust set of OpenVMS solutions."  Leaving aside the factoI that Compaq just turned out the lights on whatever 'renaissance' may have F been timidly taking its first steps, exactly what is going to be 'moreI robust' about the future environment?  Unless VMS provides facilities for1L running other systems' binaries, the effort to port applications to VMS willE be precisely what it has always been (or could have been with the COEoK enhancements on the Alpha platform) - and even if it *does* support runningYJ other systems' binaries (yeah, I'm holding my breath) that could have beenL true for at least Alpha Linux and Tru64 binaries without changing platforms.  H Sorry for the digression, but letting things like that out helps keep meG from puking all over my keyboard after I've just finished reading them.t   ..  I > >>> show us an *Intel* document that specifies some plan to 'merge' anyIL > aspects of Alpha into IA64 - Compaq can say anything (and often does), butC > Intel owns the architecture whose future you're talking about.<<<n >aH > And how many times have folks stated here that the technical plans are stillrG > cooking and will be released when done ? What part of this do you notT > understand ????.  L Gee, you seem happy to point out Compaq statements about this:  what part ofK my asking for something equivalent from Intel - the party with 100% controlN- over this decision - do *you* not understand?'   - bill   > 
 > Regards, >- > Kerry Main > Senior Consultant  > Compaq Canada Inc. > Professional Servicese > Voice: 613-592-4660R > Fax  :  819-772-7036 > Email: Kerry.Main@Compaq.com   ------------------------------  # Date: Mon, 16 Jul 2001 17:17:48 GMT . From: "Duane Sand" <duane.sand@mindspring.com>- Subject: Re: Terry Shannon Tech Talk on IA-64nA Message-ID: <0lF47.215506$%i7.123347732@news1.rdc1.sfba.home.com>h   "Rob Young" wroteE > A senior circuit designerF; > put it to me that he was totally shocked in February whenVH > Intel pointed out that McKinley was/is at 1.4 GHz.  Don't be surprisedD > if McKinley comes in higher.  And yes, I have been sitting on that/ > tidbit for a while (the shock of it all!) ;-)n >sD > http://www.intel.com/pressroom/archive/speeches/pso20010227idf.htm  C The above link to an IDF talk by Otellini is describing 1.4 Gz on ah! P4-based Xeon, not on a McKinley.c   ------------------------------  % Date: Mon, 16 Jul 2001 13:31:06 -0400@5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> - Subject: Re: Terry Shannon Tech Talk on IA-64 2 Message-ID: <rxF47.757$rc5.60092@news.cpqcorp.net>  : Bill Todd wrote in message <9ir3k5$snt$1@pyrite.mv.net>... >l7 >"Main, Kerry" <Kerry.Main@compaq.com> wrote in messagelL >news:BE56C50EA024184DAF48F0B9A47F5CF4AD7F05@kaoexc01.americas.cpqcorp.net.. .e >> Bill, >>: >> re: what Fred stated vs what you think I have stated .. >>J >> Hey, you are picking up some of Andrews tricks - like trying to drive aJ >> stake between what one person says and another in an attempt to somehow >> discredit both people.p >rJ >Not at all:  I respect Fred's technical credentials and integrity (thoughI >he's not exactly impartial in his support for what I suspect he views as9 theh: >inevitable).  I don't feel at all the same way about you. >o    # I "think" this was a complement ;-)   H One thing that is different here at Compaq from when we were Digital, isL that once a decision has been reached, they don't go back and revisit/remakeK it endlessly.  IPF is the future, Alpha - fine as it is - will quietly fademL away.  In between then and now - we will continue to have cutting edge Alpha	 hardware.e  K I don't speak for Compaq here, and my only insight into the decision is theeH after-the-fact talks that were given by people who make a lot more moneyJ than I do (and at least a few who are much smarter than I am).  At each ofL these talks,  it was independently stated (at least once by someone directlyJ involved) that this decision started when someone (a VP) asked a question,L and eventually got the *unexpected* answer much later -- that we should moveE to IPF.  It wasn't a pointy-haired-boss decision made without a clue.a  H Will the IA64 ISA be modified?  I highly doubt it, but then again - cowsK *might* fly - so I can't be certain.  I will say that what has been told toeL me (and I'm doing some of the VMS investigation work) is that we are portingI to the IA64 architecture *as it stands today*.  I believe it is much moreuJ likely that the Alpha "infusion" will be the knowlegde transfer that makesL the chips faster.  Maybe it's OOO, maybe it's SMT, speculative execution, orL maybe it's just clever circuit design.  I doubt that it is any wholesale ISA changes.  F BTW - architectural elegance or not, I am looking forward to debuggingK something where I might actually be able to figure out what the PC was whenaK something fails.  EV6 can be a nightmare when trying to debug it because ofpI all the OoO and speculative execution - especially as it effected locking-5 and its use of cache state.  Clever, fast, and scary.   H Do I have any doubts about VMS being able to be ported?  Not really.  WeL just need to figure out how hard it will be and how long it will take.  Do IK have any doubts about Compaq continuing to do the port?  Not really...  but7D I don't have any more insight into this than anyone else.  We have aL commitment, we are in the planning stages, and we don't see any showstoppersD yet.  All things that tell me that the decision isn't a sham, we are porting.  I Will we lose some customers.  Sadly, we may.  I'm suprised to some degreebE about how some people have taken this so personally.  Heck, they toldnI customers about it before they told me, that should annoy me no end.  I'miK hoping that after the initial shock, and perhaps anger, that people will be K re-evaluate and conclude that as long as VMS-is-VMS, that the fact it's IPF J and not VAX and not Alpha still provides them with what they really wantedL all along - VMS.  And VMS on a viable, long-term industry standard platform.  * _Fred (NOT speaking for Compaq or OpenVMS)   ------------------------------  % Date: Mon, 16 Jul 2001 17:19:43 +0100a0 From: andrew harrison <andrew.nospam@uk.sun.com>: Subject: Re: The death of VMS has been greatly exaggerated* Message-ID: <3B53141F.69E95353@uk.sun.com>   Bill Todd wrote: > A > "Robert Deininger" <rdeininger@mindspring.com> wrote in messagesH > news:rdeininger-0607011032030001@user-2ivebcn.dialup.mindspring.com...N > > In article <9i35rv$i9s$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com>
 > > wrote: > >tE > > > "Robert Deininger" <rdeininger@mindspring.com> wrote in message,L > > > news:rdeininger-0507012144140001@user-2ivea3q.dialup.mindspring.com...= > > > > In article <3B451283.9682264D@videotron.ca>, JF Mezeir- > > > > <jfmezei.spamnot@videotron.ca> wrote:o > > > >  > > > >mN > > > > > Consider the fud that customers have generated on their own. Imagine
 > > > what8 > > > > > Compaq's competitors will be able to generate. > > > >bN > > > > Actually, I doubt the highly-paid professionals can do better than you3 > > > > have.  They'll be happy to tie your record.s > > >iM > > > Au contraire:  the professionals won't be at all fettered by the truth,mH > > > whereas we've been careful to stick to it (or as close to it as is
 > possibleH > > > to guess, given that Compaq has never been all that forthcoming in	 > detailss8 > > > save for the ones that later turn out to be lies). > > N > > Your posts usually have some facts in them to bolster your opinions.  JF's > > rarely do. > K > Thanks (I think...).  I agree that JF can get rather carried away (beyond I > any clearly-demonstrable foundation) in some of his pronouncements, but M > suggest that there's still likely to be a difference between what I believeoH > are honestly-held fears on his part and the work of paid manipulators. > L > Whether Andrew qualifies as a paid manipulator or just does it for the funN > of it isn't clear, but I suspect he's in a somewhat difficult position rightK > now (though it's not obvious how much he realizes it).  Making Alpha look N > bad makes Compaq's decision look good, and vice versa - and which is more inN > Sun's short-term interest (i.e., which will do more harm to short-term AlphaM > sales) isn't at all clear, but my guess is that he'll try to stress Alpha's-M > 'inadequacy' out of one side of his mouth and Compaq's duplicity out of theYL > other.  On the third hand, *any* attempt on his part to capitalize on thisI > event could backfire:  people on both sides of the argument are already"M > pretty pissed, and if I were Sun or IBM I'd be inclined to tread a bit morerN > lightly and have competent sales and technical people visit Compaq customersL > stressing the virtues of their own products rather than explicitly runningJ > down Compaq's, leaving the more overt FUD to plants in the media and the > analyst community. >   ; I have to disagree partly with your post. I don't consider y: Alpha to be inadequate. In the right box (ES40) its a very7 competitive processor and nothing in the IA-64 roadmap s9 tends to suggest that IA-64 will be overtaking Alpha any b8 time soon. If you factor in the 32 bit emulation issues 7 then IA-64 isn't even remotely competitive with Intels o own 32 bit CPU's.   8 The systems platforms that Alpha run in are clearly not 5 up to scratch (except the ES40) and this can be laid  7 clearly at Compaqs door. Ditto for marketing, sales andd business development.n  : The decision to dump Alpha so soon after strong statements8 of undying loyalty in Alpha can also be laid at Compaqs  doors.  = Whether this counts as duplicity depends on your perspective  9 on how Compaq reached the decision to dump Alpha and how a6 long it took them. Looking at it from the outside the ? decision looks like a rushed job to me, brought on by external o: factors and I would guess that at the time of the undying 8 loyalty statements the Alpha -> IA-64 plan had not been 
 conceived.     Regardse Andrew Harrison> Enterprise IT Architecta   ------------------------------  % Date: Mon, 16 Jul 2001 17:33:15 +0100i0 From: andrew harrison <andrew.nospam@uk.sun.com>: Subject: Re: The death of VMS has been greatly exaggerated* Message-ID: <3B53174B.2530A3AB@uk.sun.com>   "Main, Kerry" wrote: >  > Andrew, Andrew ... > M > >>> So at the moment you have no idea what the transition costs will be fore) > a customer to move to IA-64 from Alpha.  > M > Since this is the case isn't a bit early for Compaq to be talking about thetL > benefits of moving to IA-64. Without being able to judge the costs you areJ > not providing your customers with enough information to make an informed > choice.<<< > N > As stated a number of times in this ng, the appropriate folks are working onL > the plans, and these will be made available as soon as possible. Does this5 > need to be repeated a number of times more for you?y > N > The fact that over time, AIX, HPUX, Linux64 (IBM and Compaq and other vendorN > 64bit Linux's), Win64, OpenVMS, Tru64 UNIX, and Tandem NSK all have plans toG > support the IA64 platform, has got to say something about goodness inr, > protecting future Customer HW investments. > I > In addition, with the exception of MS, each OS provider has a backup ortK > alternate 64bit HW plan (Power4, Alpha EV7, PA, MIPS) that will allow therM > Customer to migrate when they feel the timing is right - whether it is in 3  > years or 5+ years. >   A Bullshit. Power4 isn't IBM's backup plan if IA-64 doesn't delivero> the goods and if you want to test this post this on comp.arch.  @ IBM is sufficiently big to be able to have an IA-64 stategy and ; a Power4 stategy. The fact that AIX will be able to run on  & both platforms should not confuse you.      N > However, as stated before, more detailed information on all of this is still$ > cooking and will be released asap. >   & So if its still cooking how can you be% trying to sell the benefits ?????????r  . Why not wait for the cooks to finish and then - get back with credible responses rather than 72 responses that would annoy me if I was one of your customers.     regards  Andrew Harrisonc Enterprise IT Architect    ------------------------------  % Date: Mon, 16 Jul 2001 13:46:57 -0400m+ From: "Main, Kerry" <Kerry.Main@compaq.com>u: Subject: RE: The death of VMS has been greatly exaggeratedR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4AD7F0D@kaoexc01.americas.cpqcorp.net>   Andrew,   ) Just love the way you ready, fire, aim ..    :-)   H >>>Bullshit. Power4 isn't IBM's backup plan if IA-64 doesn't deliver the= goods and if you want to test this post this on comp.arch.<<<y  ! Now, if you re-read my statement:cI > In addition, with the exception of MS, each OS provider has a backup ori alternate 64bit HW plan ..>>  > What part of "or alternate 64bit plan" did you not understand?  I By the way, I do agree with you that IBM will be presenting two platformse= for AIX5L, however, here is an extract from the IBM web site:h  & http://www-1.ibm.com/servers/monterey/G "Project Monterey has been a development initiative, that includes IBM,yI Intel and SCO (Server Software Division - acquisition by Caldera Systems,iG Inc. pending), whose primary goals have been to enhance AIX with proventI technologies and to deliver the industry's best enterprise-class UNIX foroK Intel's new 64-bit microprocessor based systems (Itanium). The introduction7C of AIX 5L (October, 2000) signifies the success of this development  initiative."   Regards,  
 Kerry Main Senior Consultant, Compaq Canada Inc. Professional Services  Voice: 613-592-4660a Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----7 From: andrew harrison [mailto:andrew.nospam@uk.sun.com]a Sent: July 16, 2001 12:33 PM To: Info-VAX@Mvb.Saic.Comp: Subject: Re: The death of VMS has been greatly exaggerated       "Main, Kerry" wrote: >  > Andrew, Andrew ... > I > >>> So at the moment you have no idea what the transition costs will beh for ) > a customer to move to IA-64 from Alpha.  > I > Since this is the case isn't a bit early for Compaq to be talking aboutv theuL > benefits of moving to IA-64. Without being able to judge the costs you areJ > not providing your customers with enough information to make an informed > choice.<<< > K > As stated a number of times in this ng, the appropriate folks are workingn onL > the plans, and these will be made available as soon as possible. Does this5 > need to be repeated a number of times more for you?f > G > The fact that over time, AIX, HPUX, Linux64 (IBM and Compaq and other  vendorK > 64bit Linux's), Win64, OpenVMS, Tru64 UNIX, and Tandem NSK all have planss toG > support the IA64 platform, has got to say something about goodness ine, > protecting future Customer HW investments. > I > In addition, with the exception of MS, each OS provider has a backup orcK > alternate 64bit HW plan (Power4, Alpha EV7, PA, MIPS) that will allow thenK > Customer to migrate when they feel the timing is right - whether it is inl 3  > years or 5+ years. >   A Bullshit. Power4 isn't IBM's backup plan if IA-64 doesn't deliveri> the goods and if you want to test this post this on comp.arch.  @ IBM is sufficiently big to be able to have an IA-64 stategy and ; a Power4 stategy. The fact that AIX will be able to run on a& both platforms should not confuse you.      H > However, as stated before, more detailed information on all of this is stilla$ > cooking and will be released asap. >   & So if its still cooking how can you be% trying to sell the benefits ?????????   . Why not wait for the cooks to finish and then - get back with credible responses rather than -2 responses that would annoy me if I was one of your customers. a   regardsv Andrew Harrisonu Enterprise IT Architectl   ------------------------------  # Date: Mon, 16 Jul 2001 12:39:51 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)t Subject: Re: VMS Docset Wanted0 Message-ID: <009FF15B.57A40D25@SendSpamHere.ORG>  T In article <9isa3a$c8l$2@uranium.btinternet.com>, news@knm.yi.org (M.London) writes: >Hi,G >  I'm looking for a DocSet for VMS 5.3/5.4, yes I do know that the VMSbD >7.x docs are on the net, but I just like having something on paper,D >and I now have two VAXen running 5.3/5.4, and it'd be kinda nice to >have the docs for that :&)v >'D >  I'm Manchester, UK and would be happy to collect from someone, soC >long as it's not going to take a day to drive there and back, or Is4 >could arrange shipping from somewhere in the UK :&) >nE >  I'm not too fussed about the version, VMS 5 would be nice, but I'dtG >just like something on paper - it's so much easier when you don't havel! >a fast permenant net connection.s >u >--Mattn  I There's a set im my garage here in the US you are welcome to but the coste. of shipping them to you would be rather hefty. --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM             sJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbest   ------------------------------  % Date: Mon, 16 Jul 2001 14:29:16 +0100 * From: Andrew Robinson <arobinson@hspg.com> Subject: RE: VMS Docset WantedM Message-ID: <CDA4BAD1E10ED41181AC00508B6051D3C3E2CD@grumpy.internal.hspg.com>p  I I have a spare genuine OpenVMS V7.2 Documentation CD if that's any good -s I'm based in Northampton UK?   Andrew Robinson    -----Original Message-----> From: system@SendSpamHere.ORG [mailto:system@SendSpamHere.ORG] Sent: 16 July 2001 13:40 To: Info-VAX@Mvb.Saic.Comt Subject: Re: VMS Docset Wanted    L In article <9isa3a$c8l$2@uranium.btinternet.com>, news@knm.yi.org (M.London) writes:d >Hi,G >  I'm looking for a DocSet for VMS 5.3/5.4, yes I do know that the VMS6D >7.x docs are on the net, but I just like having something on paper,D >and I now have two VAXen running 5.3/5.4, and it'd be kinda nice to >have the docs for that :&)T >yD >  I'm Manchester, UK and would be happy to collect from someone, soC >long as it's not going to take a day to drive there and back, or Id4 >could arrange shipping from somewhere in the UK :&) >eE >  I'm not too fussed about the version, VMS 5 would be nice, but I'd'G >just like something on paper - it's so much easier when you don't havei! >a fast permenant net connection.h >h >--Matt   I There's a set im my garage here in the US you are welcome to but the costi. of shipping them to you would be rather hefty. --2 VAXman- OpenVMS APE certification number: AAA-0001 VAXman(at)TMESIS(dot)COM            -J   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbes    ------------------------------  % Date: Mon, 16 Jul 2001 14:54:23 +0100s8 From: John Macallister <J.Macallister1@physics.ox.ac.uk> Subject: RE: VMS Docset WantedN Message-ID: <35666012DF4CD411BE940090279FA240010BEFFF@ppnt41.physics.ox.ac.uk>  & The VMS docs available on-line at URL:  - http://www.openvms.compaq.com:8000/index.html>  K often (and most for later manuals?) have PDF versions which can be printed.a1 I've printed a few full manuals from this source.t  J Unlike printing from Bookreader and other previous documentation utilities4 the PDF manuals are identical to the paper versions.   John  B Name: John B. Macallister  E-mail: j.macallister1@physics.ox.ac.ukH Post: Nuclear and Astrophysics Laboratory, Keble Road, Oxford OX1 3RH,UKA Phone: +44-1865-273388 (direct)  273333 (reception)  273418 (Fax)    ------------------------------  # Date: Mon, 16 Jul 2001 16:32:30 GMTe. From: "Duane Sand" <duane.sand@mindspring.com> Subject: Re: VMS on IA64A Message-ID: <yGE47.215451$%i7.123310861@news1.rdc1.sfba.home.com>n   Stanley F. Quayle wrote:	 > >>> ...tH > >>> Will DECmigrate be resurrected to support VAX code on IA64?  Or is7 > >>> the tradition of supporting VAX forever now gone?aJ > >>> And how about migrating Alpha code to IA64?  Will there be something9 > >>> like DECmigrate, or must we recompile from sources?k   Fred Kleinsorge wrote:J > > Don't be too certain.  This specific subject is being looked at.  If I hadeL > > to guess the final  outcome (and this is just my guess, I'm not speaking for J > > Compaq or OpenVMS), I would look for something more akin to FX-32 like > > approach than VEST et al.l   Larry Kilgallen wrote:A > It is actually possible to run VEST to get an FX32-like effect,tA > but the performance hit is such that it was not documented.  Ato> > the time the idea was to prove that Alpha was faster, and if@ > major applications were run in that mode, Alpha might come out > slower than VAX.  < From my experience on NSK, there's lots of customer value in; also having a maximally-easy maximally-compatible migrationi? route at lower performance levels, for all those secondary apps ; whose performance makes no difference to the overall system 
 economics.     >aC > The ugly thing about VEST/TIE, however, is the need to preprocessbF > the executables.  Since VEST was released both Apple and Tandem haveH > done emulation on-the-fly, with no advance preparation of executables.G > That is one step that would make the transition to IA64 _better_ thane > the transition to Alpha was.  < Tandem/Nsk has only done static pre-translation; there is noF translation during execution.  We plan to again use static translationC for IPF.  I'm unaware of any translation-during-execution for Applet@ Powermac's M68K emulation, but haven't followed that closely forC awhile.   (A minor nit; Tandem's and Apple's translators were built,; and shipped in parallel with VEST's development, not after.lA VEST and the rest were all modelled after HP's static translatorse* shipped and publically described in 1987.)  @ Translation on-the-fly is now common in various Java implementa-E tions, and HP uses only dynamic translation (no static preprocessing)o, on its emulation of PA-RISC binaries on IPF.  @ What's more important than the static vs. dynamic implementation= choice, is whether translations can (usually) be done without ? detailed programmer-supplied hints.  Dynamic translation is oney@ way to avoid needing such hints.    If translation can be safelyC applied to all programs without any hints, then translation (staticMC or dynamic) can become the default or only way to run old binaries.4  ? Pre-translation is now fast enough (and infrequent enough) that:> the system could do it automatically as needed without impact.  > In the best scenario, no one needs to do anything new or extra= for running on the new machines at all -- not the applications> developers, nor the program users, nor the program installers.   ------------------------------  # Date: Mon, 16 Jul 2001 10:26:57 GMTo. From: Burnie M <burniem.NOSPAM@ozemail.com.au>& Subject: Re: Volume Shadowing Question8 Message-ID: <jag5lt09u8grssh0cojuhephmsnv5p7e5d@4ax.com>  A On 15 Jul 2001 12:53:41 -0700, kparris@my-deja.com (Keith Parris)@ wrote:   >Freddy Meerwaldt <frederik@freddym.org> wrote in message news:<Pine.LNX.4.21.0107151545250.4386-100000@firewall.freddym.org>...K >> I've created a Shadowset of a 2GB Disc mirrored onto another 2GB Disc ofw >> the same type.rM >> But the Alpha just won't shadow the discs. A "$ sho dev d" always says: 0%b
 >> completed.  >> That _is_ crazy, isn't it? K >> Now something even more crazy: As soon as I boot a VAX in the cluster it 9 >> starts shadowing the disc immediately (over ethernet).r >lG >Sounds like the SYSGEN parameter SHADOW_MAX_COPY is set to zero on theeA >Alpha.  It's a dynamic parameter, so you can change it without a  >reboot.D >------------------------------------------------------------------- >Keith Parris |c    F If you change it then you need to drop the copy out and add it back inD as the shadow set looks at SHADOW_MAX_COPY at the time you mount the second disk.   Cheers,u	 	Burnie M    ------------------------------  # Date: Mon, 16 Jul 2001 10:29:12 GMTb. From: Burnie M <burniem.NOSPAM@ozemail.com.au>& Subject: Re: Volume Shadowing Question8 Message-ID: <sdg5lt8s0jtg7se8v5n43cmvq9p84k9im2@4ax.com>  * On Mon, 16 Jul 2001 10:26:57 GMT, Burnie M& <burniem.NOSPAM@ozemail.com.au> wrote:  B >On 15 Jul 2001 12:53:41 -0700, kparris@my-deja.com (Keith Parris) >wrote:m >  >>Freddy Meerwaldt <frederik@freddym.org> wrote in message news:<Pine.LNX.4.21.0107151545250.4386-100000@firewall.freddym.org>...-L >>> I've created a Shadowset of a 2GB Disc mirrored onto another 2GB Disc of >>> the same type.N >>> But the Alpha just won't shadow the discs. A "$ sho dev d" always says: 0% >>> completed. >>> That _is_ crazy, isn't it?L >>> Now something even more crazy: As soon as I boot a VAX in the cluster it: >>> starts shadowing the disc immediately (over ethernet). >>H >>Sounds like the SYSGEN parameter SHADOW_MAX_COPY is set to zero on theB >>Alpha.  It's a dynamic parameter, so you can change it without a	 >>reboot. E >>-------------------------------------------------------------------t >>Keith Parris | >g > G >If you change it then you need to drop the copy out and add it back in E >as the shadow set looks at SHADOW_MAX_COPY at the time you mount the 
 >second disk.y >l >Cheers,
 >	Burnie M    B PS If you run a shadow set with members on two (or more) nodes itsF always faster to force the shadow server to run on the system with the output disk.  9 Makes a difference if you are shadowing across a Wan link-   ------------------------------    Date: 16 Jul 2001 10:24:23 -05002 From: cochrane@encompasserve.org (Arthur Cochrane)? Subject: Wanted: Program to set process name to UAF owner valuel3 Message-ID: <hb3GqNet9XLx@eisner.encompasserve.org>d  8     Sorry if this is a FAQ or already answered here but:     F     I am looking for a program (MACRO better since all VMS systems can8     compile and link) that will be run from SYLOGIN and:     =     1. read the owner field from the UAF record for the user,pA     2. set the process name to this value (after truncating to 15         characters), L     3. if this process name is already in use then change the 15th character7        to a '1' and set the process name to this value,-E     4. if this process name is already in use then increment the 15th *        character and set the process name,:     5. loop at step four until the process name can be set     0     Example: UAF Owner field is: Arthur CochraneH     so the first time I login my process name is set to: Arthur CochraneK     and the second time I login the process name is set to: Arthur Cochran1 J     and the third time I login the process name is set to: Arthur Cochran2#     etc. for each successive login.A     I     This should be a simple program but no since reinventing the wheel ifbK     someone has already written this. This code may already exist and if sos/     thank you in advance for pointing me at it.u   ------------------------------  # Date: Mon, 16 Jul 2001 16:03:47 GMTr2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)C Subject: Re: Wanted: Program to set process name to UAF owner valuei2 Message-ID: <DfE47.750$rc5.60078@news.cpqcorp.net>  h In article <hb3GqNet9XLx@eisner.encompasserve.org>, cochrane@encompasserve.org (Arthur Cochrane) writes:9 :    Sorry if this is a FAQ or already answered here but:l  L   Please don't apologize, please look -- the FAQ is there for a reason, and I   that's to cut down on the numbers of common questions.  (No offense is wL   intended here.)  And that requested, this question is NOT answered in the    OpenVMS FAQ.    G :    I am looking for a program (MACRO better since all VMS systems cane9 :    compile and link) that will be run from SYLOGIN and:  :r> :    1. read the owner field from the UAF record for the user,B :    2. set the process name to this value (after truncating to 15 :       characters),M :    3. if this process name is already in use then change the 15th charactera8 :       to a '1' and set the process name to this value,F :    4. if this process name is already in use then increment the 15th+ :       character and set the process name,n; :    5. loop at step four until the process name can be seta   ..  J :    This should be a simple program but no since reinventing the wheel ifL :    someone has already written this. This code may already exist and if so0 :    thank you in advance for pointing me at it.  E   Please post a problem statement in addition to any proposed problem-F   solution -- with the problem statement, we can provide alternatives.  F   I will assume this request does not really need to modify the SYSUAFF   file and particularly does not need to locate nor modify the SYSUAF K   file ownername field, and that the request here is really around setting rG   a unique process name for a user.  I will assume that the owner field47   is merely a proposed solution, and not a requirement.p  E   Accordingly, here is one solution to setting a unique process name:d  ( $       JPIUSR  = F$GetJPI(0,"USERNAME")  $       PRCIDX  = F$Fao("!4XW",-E                 F$GetSYI("MAXPROCESSCNT")-F$GetJPI("0","PROC_INDEX"))tA $       PRCNAM  = F$Edit("''JPIUSR'_''PRCIDX'","COLLAPSE,UPCASE")e $t? $       If F$GetJPI("0","MASTER_PID") .eqs. F$GetJPI("0","PID")h $       Then% $           Set Process/Name='PRCNAM'e
 $       EndIfM  H   You could certainly track this value -- things do get interesting withG   cleaning the file out and maintaining the list, or with always havingiJ   to scan for the lowest or next-available numeric suffix for a particularI   username with the proposed/requested SYSUAF-based solution.  The above  J   avoids all this, as the numeric suffix chosen for the process is always    known to be unique.e  G   nb: the SYSUAF owner field is not necessarily unique -- the username  I   field within the SYSUAF is necessarily unique.  The above adds a unique5J   numeric suffix, and a suffix that is unique across all processes running   within the OpenVMS system.  L   If you are really keeping track of the number of logins and are using the K   process owner field for this -- and that storage is not something that I rJ   would recommend -- I would move to a small indexed file maintained from L   DCL, and I would search for and update a count in this small indexed file J   via DCL or a small and simple-minded program.  If no record is found forL   the username, create it.  (This task would be a dozen or so lines of DCL.)1   I would NOT store this login value in SYSUAF.     J   You could also track the number of logins using the existing accounting H   mechanisms, via the ACCOUNTING tool and/or via the ANALYZE/AUDIT tool.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------   End of INFO-VAX 2001.392 ************************ure Customer HW investments. > I > In addition, with the exception of MS, each OS provider has a backup orcK > alternate 64bit HW plan (Power4, Alpha EV7, PA, MIPS) that will allow thenK > Customer to migrate when they feel the timing is right - whether it is inl 3  > years or 5+ years. >   A Bullshit. Power4 isn't IBM's backup plan if IA-64 doesn't deliveri> the goods and if you want to test this post this on comp.arch.  @ IBM is sufficiently big to be able to have an IA-64 stategy and ; a hH{ZD|y~A]X"
ZP4Gĝk벱{@
48>4[wOs
͝-m^M{#@YCӚl}ovVŌ#
q(V	!|ŢKH6}>1}L8SU(k+v/K,1}A}j3i
כQ1PiC܁H.K	p!-i-
?aNh߉74ja@u!;]ʸI5n^̴жGڏCB7_ȩb[[Ӡ$ءJ򇆶I^?eh
i.
K97,2E]Bh18275]P6*TdJ\Ӿ;Oy}2zN}ihh0/PHhN"`=4н!P՗m뒉J
:"iڔvoFfo}fq
i{0"
j54k