1 INFO-VAX	Tue, 20 Nov 2001	Volume 2001 : Issue 646       Contents: Advice on CD-R & DVD-R Re: Advice on CD-R & DVD-RD analyze/disk crashes with message %system-f-accvio, access violation Re: APC UPS Software by TMESIS C-Kermit 8.0 Beta.04 for VMS Re: Couple of new articles Re: Couple of new articles  DCPS slow by printing LN06-Files$ Re: DCPS slow by printing LN06-FilesP Re: Disaster Tolerance day organized by Compaq User Group Netherlands (NLCUG) (N Re: F$GETQUI wildcard bug??  F$GETQUI wildcard bug??  Re: F$GETQUI wildcard bug?? . Re: From the deja vu all over again department
 Re: Ghoti :-) 6 Re: IPF Calling Standard (was: ISV's and VMS on Intel)6 Re: IPF Calling Standard (was: ISV's and VMS on Intel)6 Re: IPF Calling Standard (was: ISV's and VMS on Intel)6 Re: IPF Calling Standard (was: ISV's and VMS on Intel)6 Re: IPF Calling Standard (was: ISV's and VMS on Intel)6 Re: IPF Calling Standard (was: ISV's and VMS on Intel)6 Re: IPF Calling Standard (was: ISV's and VMS on Intel)' Re: Is it a DEC C problem, or is it me? ' Re: Is it a DEC C problem, or is it me? ' Re: Is it a DEC C problem, or is it me? ' Re: Is it a DEC C problem, or is it me? ' Re: Is it a DEC C problem, or is it me? ' Re: Is it a DEC C problem, or is it me? ' Re: Is it a DEC C problem, or is it me? ' Re: Is it a DEC C problem, or is it me? ' Re: Is it a DEC C problem, or is it me? ' Re: Is it a DEC C problem, or is it me? ' Re: Is it a DEC C problem, or is it me? ' Re: Is it a DEC C problem, or is it me? ' Re: Is it a DEC C problem, or is it me? ' Re: Is it a DEC C problem, or is it me? ' Re: Is it a DEC C problem, or is it me? ' Re: Is it a DEC C problem, or is it me? ' Re: Is it a DEC C problem, or is it me? ' Re: Is it a DEC C problem, or is it me?  Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha Re: Life After Alpha% Re: No advertisment for VMS stability 1 Re: OpenVMS o/s cd-rom insufficient quotas/limits  OpenVMS Times  Special edition$ Pathworks and SMBClient (Linux/Irix) RWAST/LAT port problem Scripting / batch files? Re: Scripting / batch files?* Server vs. Workstation:  You Make The Call. Re: Server vs. Workstation:  You Make The Call5 Re: Software to emulate someone sitting at a terminal 5 Re: Software to emulate someone sitting at a terminal 5 Re: Software to emulate someone sitting at a terminal 9 Re: Solaris: ready for prime time?  Keep your VMS system. 9 Re: Solaris: ready for prime time?  Keep your VMS system. 9 Re: Solaris: ready for prime time?  Keep your VMS system. E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org E Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org  TZ887 installation questions  Re: TZ887 installation questions; Re: VMS on IBM power chip would make IBM No. 1 in high end! ; RE: VMS on IBM power chip would make IBM No. 1 in high end! ; Re: VMS on IBM power chip would make IBM No. 1 in high end! ; Re: VMS on IBM power chip would make IBM No. 1 in high end! ; Re: VMS on IBM power chip would make IBM No. 1 in high end! ; Re: VMS on IBM power chip would make IBM No. 1 in high end! ; Re: VMS on IBM power chip would make IBM No. 1 in high end! ; Re: VMS on IBM power chip would make IBM No. 1 in high end!  Xetra, on which OS?  Re: Xetra, on which OS? ? Re: [VMS Motif] How to avoid starting the DECW$SERVER process ?   F ----------------------------------------------------------------------  % Date: Tue, 20 Nov 2001 14:47:13 -0000 - From: Martin Walker <Martin.Walker@csf.co.uk>  Subject: Advice on CD-R & DVD-R L Message-ID: <0262A6086BFBD411959500508B69C5EA134965@ThisAddressDoesNotExist>  J Looking at CD-R writing from VMS, it seems that some drives work well with1 VMS and others don't.  I know how to set them up.   F I'd welcome advice as to which ones people are using which work well -K manufacturer, model etc - (using CDWRITE on VMS 7.3).  What I'm looking for H is reasonable write speed, can mount and read CDs on VMS and, of course, still available to buy.   L Also, are there DVD drives which work with VMS?  What manufacturer / model / software are people using?   Thanks    A This e-mail including any attachments is confidential and may be  F legally privileged. If you have received it in error please advise the@ sender immediately by return email and then delete it from your  system. B The unauthorised use, distribution, copying or alteration of this F email is strictly forbidden. If you need assistance please contact the  help desk on (+44)(0)870 8704820   ------------------------------  # Date: Tue, 20 Nov 2001 15:59:55 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) # Subject: Re: Advice on CD-R & DVD-R 0 Message-ID: <00A0553A.F32D9B0C@SendSpamHere.ORG>  | In article <0262A6086BFBD411959500508B69C5EA134965@ThisAddressDoesNotExist>, Martin Walker <Martin.Walker@csf.co.uk> writes:K >Looking at CD-R writing from VMS, it seems that some drives work well with 2 >VMS and others don't.  I know how to set them up. > G >I'd welcome advice as to which ones people are using which work well - L >manufacturer, model etc - (using CDWRITE on VMS 7.3).  What I'm looking forI >is reasonable write speed, can mount and read CDs on VMS and, of course,  >still available to buy.    I Yamaha CRW2200SX is a 10xRW/20xW/40xR drive.  My original Yamaha CRW4416S J quit on my an I recently purchased the CRW2200SX.  It does not exhibit theJ SubLUN strangness of the CRW4416S and works quite well.  You cannot use itI as a CDrom in the VMS environment, however.  DKDRIVER still does not like ; something about the characteristics it (the drive) reports.     ! Oh, and use CDrecord not CDwrite.  --O 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: 20 Nov 2001 08:59:11 -0800@ From: Dirk.Van.Bouchaute@kender-thijssen.be (Dirk Van Bouchaute)M Subject: analyze/disk crashes with message %system-f-accvio, access violation = Message-ID: <67059dac.0111200859.490ec6d1@posting.google.com>    Hello !   > Has anybody seen those kind of problems when analyzing disks ?P We get this command to crash every time we start it. On the other hand, the disk  seems to work without problems..  A The version OpenVms 5.5_2H4 and the disk is a RZ40 type, 9 Gbyte    8 Defragmenter DFO 2.5 is installed and might be involved.   The entire listing is:   $ ana /dis dka200: /list Listing of index file on   20-NOV-2001 12:23:54.71   . %ANALDISK-I-OPENQUOTA, error opening QUOTA.SYS" -SYSTEM-W-NOSUCHFILE, no such file" (00000001,00001,001)  INDEXF.SYS;1 [1,4] " (00000002,00002,001)  BITMAP.SYS;1 [1,4] " (00000003,00003,001)  BADBLK.SYS;1 [1,4] " (00000004,00004,001)  000000.DIR;1 [1,4] " (00000005,00005,001)  CORIMG.SYS;1 [1,4] " (00000006,00006,001)  VOLSET.SYS;1 [1,4] " (00000007,00007,001)  CONTIN.SYS;1 [1,4] " (00000008,00008,001)  BACKUP.SYS;1 [1,4] " (00000009,00009,001)  BADLOG.SYS;1 [1,4] " (00000010,00001,001)  DZ_ARC.DIR;1 [1,4] # (00000011,00002,001)  ALM_BCK.DIR;1  [130,77]# (00000012,00002,001)  DCF_BCK.DIR;1  [130,77]# (00000013,00002,001)  HIS_BCK.DIR;1  [130,77]# (00000014,00002,001)  TLX_BCK.DIR;1  [130,77]8 (00000015,00001,001)  ALM_LGF_00_10_11_TO_00_10_12.DAT;1 [130,77]8 (00000016,00001,001)  ALM_LGF_00_10_13_TO_00_10_15.DAT;1 ...............  ...............  [130,77]8 (00000256,00001,001)  ALM_LGF_01_10_28_TO_01_10_28.DAT;1 [130,77]8 (00000257,00001,001)  ALM_LGF_01_10_28_TO_01_10_28.DAT;2 [130,77]8 (00000258,00001,001)  ALM_LGF_01_10_30_TO_01_10_30.DAT;1 [130,77]; %SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual + address=57900358, PC=80000010, PSL=03C00004   2   Improperly handled condition, image exit forced.  4         Signal arguments              Stack contents  1         Number = 00000005                803CB440 1         Name   = 0000000C                00000002 1                  00000001                7FEA8F64 1                  57900358                7FEA8F4C 1                  80000010                00000004 1                  03C00004                7FEA91A0 1                                          00000003 1                                          00000007 1                                          0000000E 1                                          09000001            Register dump   B         R0 = 03C00000  R1 = 57900358  R2 = 00002000  R3 = 00000180B         R4 = 00000000  R5 = 00000000  R6 = 0073C540  R7 = 0073C5AAB         R8 = 00000180  R9 = 0073C740  R10= 00741E4C  R11= 00000000B         AP = 7FEA8F00  FP = 7FEA8EC0  SP = 7FEA8F3C  PC = 80000010         PSL= 03C00004      All advice is welcome !    Many thanks in advance   Dirk Van Bouchaute Software Support Engineer  Kender Thijssen   % Dirk.Van.Bouchaute@Kender-Thijssen.be    phone : +32-52-33.01.60    int ref: disbru.53488    ------------------------------  # Date: Tue, 20 Nov 2001 10:52:31 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) ' Subject: Re: APC UPS Software by TMESIS 0 Message-ID: <00A05510.01EFE40B@SendSpamHere.ORG>  i In article <55f85d77.0111192010.1d28d3fc@posting.google.com>, P.Young@unsw.EDU.AU (Patrick Young) writes: u >robin.brady@ssb.state.tx.us (Robin Brady) wrote in message news:<17e7dda1.0111160950.64b71844@posting.google.com>... 7 >> Does anyone have any experience with software called K >> UPShot by TMESIS Software (http://www.tmesis.com/apc/registration.htmlx)  > G >After reading this posting and noting I just recently connected an APC F >Smart-UPS 1250 to one of our Alphas, I downloaded it to give it a try! >as it looks like a cool product.  > - >I'm not having much luck though, I just get:  > * >>>> parsing UPShot parameter file... DONE% >>>> checking the UPS capabilities...  > G >At which point nothing further happens. I looked at the serial traffic F >to find the software saying "Ay" and the UPS saying "SM" in response.@ >This happens every 1 to 2 seconds, but nothing further happens. > 
 >My cable is:  >  >9 Pin M     9 Pin F >  >1           3 >2           2 >9           5 > E >I'm not sure if this is right or if the APC model I have is too old.   ? Please contact me at the address listed in the signature below.   D I did not that you serial number was S95...  That's a farily old APCE model and it may be the (not so) Smart protocol that is used for com- ; munication between CPU and UPS is lacking certain commands.   D Please forward the UPSHOT.INIT and UPSHOT.LOG files when/if you send me an email.   --O 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: 20 Nov 2001 17:49:04 GMT0 From: fdc@watsun.cc.columbia.edu (Frank da Cruz)% Subject: C-Kermit 8.0 Beta.04 for VMS 5 Message-ID: <9te52g$j8f$1@newsmaster.cc.columbia.edu> & Keywords: kermit vms vax alpha openvms  C C-Kermit 8.0 is almost ready for release.  The final Beta, Beta.04, B was announced on the Kermit newsgroup (comp.protocols.kermit.misc)
 yesterday:  D   http://www.columbia.edu/kermit/ck80b04.html  <-- Beta announcementD   http://www.columbia.edu/kermit/ck80b.html    <-- C-Kermit 8.0 pageE   http://www.columbia.edu/kermit/ckermit.html  <-- C-Kermit main page   C Of course, it continues to be kept current for VMS, even if (sadly) A some of the new features -- such as security and the FTP and HTTP @ clients -- don't make it into VMS (this requires VMS skills thatF I don't have).  So far, Beta.04 has been built and tested successfully= on the following hardware / OS / TCP/IP product combinations:   * Hardware   VMS    TCP/IP          FilenameA   VAX      5.5-2  (None)          ckv200b04-vax-vms55-nonet.exe   A   VAX      5.5-2  UCX 2.0         ckv200b04-vax-vms55-ucx20.exe   A   VAX      7.1    (None)          ckv200b04-vax-vms71-nonet.exe   A   VAX      7.1    MultiNet 4.2A   ckv200b04-vax-vms71-tgv42.exe   A   VAX      7.2    (None)          ckv200b04-vax-vms72-nonet.exe   A   VAX      7.2    MultiNet 4.3    ckv200b04-vax-vms72-tgv43.exe   A   VAX      7.3    (None)          ckv200b04-vax-vms73-nonet.exe   A   VAX      7.3    MultiNet 4.3    ckv200b04-vax-vms73-tgv43.exe   A   Alpha    6.2    (None)          ckv200b04-axp-vms62-nonet.exe   A   Alpha    6.2    UCX 4.0         ckv200b04-axp-vms62-ucx40.exe   A   Alpha    7.1    (None)          ckv200b04-axp-vms71-nonet.exe   A   Alpha    7.1    UCX 4.1         ckv200b04-axp-vms71-ucx41.exe   A   Alpha    7.1    TCPware 5.4     ckv200b04-axp-vms71-pst54.exe   A   Alpha    7.2    (None)          ckv200b04-axp-vms72-nonet.exe   A   Alpha    7.2    MultiNet 4.3A   ckv200b04-axp-vms72-tgv43.exe   A   Alpha    7.3    (None)          ckv200b04-axp-vms73-nonet.exe   A   Alpha    7.3    MultiNet 4.3A   ckv200b04-axp-vms73-tgv43.exe     G If you have a C compiler and can supply builds for any combination not   listed, please upload to:   ,   ftp://kermit.columbia.edu/kermit/incoming/  I using the naming conventions show above.  The ones most badly needed are:   #  . VMS 4-point-anything on the VAX. #  . VMS 6-point-anything on the VAX. %  . VMS 1-point-anything on the Alpha.   I I hope the final release will come within a few weeks.  Meanwhile, report  any problems with Beta.04 to:      kermit-support@columbia.edu   H Meanwhile, in case anybody is up for a nontechnical project to help out,# see the new Unix C-Kermit tutorial:   .   http://www.columbia.edu/kermit/ckututor.html  I This is not just a web page, it's also the basis for the new C-Kermit 8.0  Unix manual page:   6   ftp://kermit.columbia.edu/kermit/test/text/ckuker.nr  G (converted by hand -- I don't know of any automated tool for converting F from HTML to nroff...)  It would be nice to have a version of this forJ VMS, both as a web page and a VMS HELP file.  The VMS HELP text for KermitJ is rather aged, but I can't do everything myself; there just aren't enoughF hours in the day.  If you're interested, let me know (so I can prevent duplication of effort).    Thanks!    - Frank    ------------------------------  # Date: Tue, 20 Nov 2001 09:32:06 GMT % From: Milton <mbhewitt@optonline.net> # Subject: Re: Couple of new articles 8 Message-ID: <le8kvtsak02sp4le1alsu8upvkbv9de5s7@4ax.com>  F On Mon, 19 Nov 2001 23:44:27 GMT, "Bill Todd" <billtodd@metrocast.net> wrote:  K >One is a reference to a Micropro report critical of Itanic's chances (glad 0 >to see I'm not the only one with such notions): > ( >http://www.theinquirer.net/19110104.htm  F An article that refers to Intel's last enterprise-level processor, theF mighty iAPX432 and compares it to it's newest enterprise-level chip.     http://www.vanshardware.com/articles/2001/september/010928_Guest_Opinion_Deconstruction_Falling_Star/010928_Guest_Opinion_Deconstruction_Falling_Sta.htm [word wrap alert]   E It's amazing that companies are EOL profit-producing product in their  rush to deploy it.  A >The other indicates that HP has been picking up some of Compaq's K >not-so-better ideas in how to renege upon commitments to customers, in the B >way it turned around and axed MPE after having presented a 5-year" >development road map last August: > C >http://www.computerworld.com/storyba/0,4125,NAV47_STO65869,00.html   F Here's an article with Compaq's roadmap for the Alpha published just 7 months ago:    Alpha chip good until 2025  ' http://www.theinquirer.net/15040102.htm   ( Seems like they were off by a few years.   Cheers,  Milton   ------------------------------  % Date: Tue, 20 Nov 2001 12:11:09 +0000 % From: Alan Greig <a.greig@virgin.net> # Subject: Re: Couple of new articlesi8 Message-ID: <cuhkvtkob6egj9vqc42alqmsuh3mvu966j@4ax.com>  F On Mon, 19 Nov 2001 23:44:27 GMT, "Bill Todd" <billtodd@metrocast.net> wrote:  K >One is a reference to a Micropro report critical of Itanic's chances (gladS0 >to see I'm not the only one with such notions): >d( >http://www.theinquirer.net/19110104.htm > A >The other indicates that HP has been picking up some of Compaq's K >not-so-better ideas in how to renege upon commitments to customers, in the B >way it turned around and axed MPE after having presented a 5-year" >development road map last August: >sC >http://www.computerworld.com/storyba/0,4125,NAV47_STO65869,00.htmln  0 I particularly note the following partial quote:  C Hewlett-Packard Co. last week dropped the hammer on users of its HPP? e3000 systems, disclosing plans to stop selling the decades-old C computer line in two years and to cease support at the end of 2006.   D The future of the HP e3000 has long been a source of concern for itsE large installed base. But HP's move still stunned and angered many ITsE managers, who said they have built their corporate back-end computing A environments, and staked their careers, on the venerable midranger system.   D John Burke, systems and operations manager at Pacific Coast Building> Products Inc. in Sacramento, Calif., said the phaseout plan isF especially hard to swallow because HP laid out a five-year developmentF road map for the HP e3000 at a conference sponsored by the independent Interex user group in August.s  ? "I feel betrayed, because I left the HP World conference with asA renewed feeling of confidence that the platform would be around,"A" Burke said. "How can we trust HP?"  D "I'm appalled and disappointed, and there are lots of unhappy people@ who see their livelihood threatened by this decision," said JohnE Penney, a systems programmer for the Pierce County, Wash., governmentaC . "The HP that we all grew to know and love in the '70s cared abouteB employees and customers and would go out of the way to make things; right. That has gone by the wayside in the past few years."   E Penney said 30% of Pierce County's business activities, including thenF processing of tax bills, land appraisals and license applications, are> handled by the HP e3000. County officials haven't decided on a5 migration path to another hardware platform, he said.   B The 3000 series was launched in 1972 and is one of the last of the@ old-line minicomputers left standing, along with Compaq ComputerC Corp.'s OpenVMS-based systems and IBM's AS/400, which is now calledo the iSeries .    >FWIW, >  >- billi >r >y   -- Alan   ------------------------------  # Date: Tue, 20 Nov 2001 11:46:28 GMTu- From: Stefan.Bill@soudronic.com (Stefan Bill)m) Subject: DCPS slow by printing LN06-Files-/ Message-ID: <3bfa4287.16944294@news.cis.dfn.de>.   Hi  D A programm creates several Printfiles with LN06 Escape Sequences in,> and print them out  to a Lexmark Optra T614 over a DCPS-Queue.E This is very slow. Beetween to Printout's there are 10 to 20 seconds.6  F When i copy all the Files to one File and print it out. Then it's very7 fast. But it's not possibly to do that in the Programm.n  C So is there a solution to speed up the printing of many LN06-Files?   6 OpenVMS 7.2-1H1 / TCPIP Services 5.0A ECO 2 / DPCS 2.0   Thanks,M Stefan   ------------------------------  % Date: Tue, 20 Nov 2001 11:54:57 -0500o0 From: Paul Anderson <paul.r.anderson@compaq.com>- Subject: Re: DCPS slow by printing LN06-Filese; Message-ID: <201120011154577013%paul.r.anderson@compaq.com>e  ; In article <3bfa4287.16944294@news.cis.dfn.de>, Stefan Bill " <Stefan.Bill@soudronic.com> wrote:  F > A programm creates several Printfiles with LN06 Escape Sequences in,@ > and print them out  to a Lexmark Optra T614 over a DCPS-Queue.G > This is very slow. Beetween to Printout's there are 10 to 20 seconds.a > H > When i copy all the Files to one File and print it out. Then it's very9 > fast. But it's not possibly to do that in the Programm.A > E > So is there a solution to speed up the printing of many LN06-Files?-  E So the delay is _inbetween_ jobs?  Do you print job or file separatore8 pages?  Turning off the trailer page, if any, will help.   Paul   -- o  Paul Anderson   OpenVMS Engineering    Compaq Computer Corporationg   ------------------------------  % Date: Tue, 20 Nov 2001 08:24:10 +0100n- From: Jouk Jansen <joukj@hrem.stm.tudelft.nl>lY Subject: Re: Disaster Tolerance day organized by Compaq User Group Netherlands (NLCUG) (N/3 Message-ID: <3BFA1329.48F0A129@hrem.stm.tudelft.nl>h   Fabio Cardoso wrote: > 
 > Hmmmm... >  > / > Do Shell still having VMS systems in Europe ? 0 > Here in Brazil I know they changed to Sun, but0 > I Europe I think they are using IBM, right ??? > @ Nope, Shell got rid of VMS some 8 years ago. They droped all the6 hardware at the university I was working at that time.                   Jouk   ------------------------------    Date: 20 Nov 2001 08:49:15 -0600 From: briggs@encompasserve.org$ Subject: Re: F$GETQUI wildcard bug??3 Message-ID: <oQaknjI9qB50@eisner.encompasserve.org>v  k In article <WZEoWmSE4Ci9@eisner.encompasserve.org>, macarthur@encompasserve.org (Malcolm MacArthur) writes:BL > I decided it might be a nice idea to differentiate between remote printersM > at remote sites. Setting up separate queue managers was not on - the systemlL > only allows you to have five, and that's not enough. So instead, I decidedN > to use the little-used /CHARACTERISTICS qualifier on the queue; I could thenE > write a generic COM file using f$getqui to find queues with a giveneN > characteristic and execute a given command against them. But, issuing a SHOWI > QUEUE command whilst in an F$GETQUI wildcard operation resets the queuea< > context, putting me back to the first queue on the system. > L > Is this a bug in f$GETQUI? I've already figured out a way around it, but I > shouldn't have to.    It's not a bug.  It's a feature.  C The queue manager is a separate process.  The F$GETQUI lexical is acC jacket around the SYS$GETQUI system service which, in turn, manages-D a communications channel between your process and the queue manager.  B That communications channel is single threaded.  There is only oneB set of context information maintained for your process.  Any queueC related activity from your process uses that single thread/context.-  @ SHOW QUEUE uses SYS$GETQUI.  And destroys the context created by your F$GETQUI.   	John Briggs   ------------------------------    Date: 20 Nov 2001 08:14:03 -06005 From: macarthur@encompasserve.org (Malcolm MacArthur)c  Subject: F$GETQUI wildcard bug??3 Message-ID: <WZEoWmSE4Ci9@eisner.encompasserve.org>a  F All right. Either I've found a bug in F$GETQUI, or I'm doing something fundamentally wrong here.m  J I decided it might be a nice idea to differentiate between remote printersK at remote sites. Setting up separate queue managers was not on - the systemeJ only allows you to have five, and that's not enough. So instead, I decidedL to use the little-used /CHARACTERISTICS qualifier on the queue; I could thenC write a generic COM file using f$getqui to find queues with a givenEL characteristic and execute a given command against them. But, issuing a SHOWG QUEUE command whilst in an F$GETQUI wildcard operation resets the queue0: context, putting me back to the first queue on the system.  J Is this a bug in f$GETQUI? I've already figured out a way around it, but I shouldn't have to.  # I have seen this problem on V7.2-1.A  L Below is a sample COM file which replicates the problem. Run it as '@QUITST'O and it will just print the queue names. Use '@QUITST BUG' instead, and you will0- see the F$GETQUI bug (Unless it's just me ;-)0   -Malcolm MacArthur  % $ if p1 .eqs. "BUG" then comment = ""0& $ if p1 .nes. "BUG" then comment = "!"& $ dummy = f$getqui("CANCEL_OPERATION") $ loop:T? $ qname = f$getqui("DISPLAY_QUEUE","QUEUE_NAME","*","WILDCARD")0 $ if qname .eqs. "" then exit1 $ write sys$output qname $ 'comment show queue 'qname $ goto loop_   ------------------------------    Date: 20 Nov 2001 09:13:58 -06005 From: macarthur@encompasserve.org (Malcolm MacArthur)v$ Subject: Re: F$GETQUI wildcard bug??3 Message-ID: <rnx4lOflI+TI@eisner.encompasserve.org>p  T In article <oQaknjI9qB50@eisner.encompasserve.org>, briggs@encompasserve.org writes:m > In article <WZEoWmSE4Ci9@eisner.encompasserve.org>, macarthur@encompasserve.org (Malcolm MacArthur) writes:0M >> I decided it might be a nice idea to differentiate between remote printers0N >> at remote sites. Setting up separate queue managers was not on - the systemM >> only allows you to have five, and that's not enough. So instead, I decided O >> to use the little-used /CHARACTERISTICS qualifier on the queue; I could then F >> write a generic COM file using f$getqui to find queues with a givenO >> characteristic and execute a given command against them. But, issuing a SHOW J >> QUEUE command whilst in an F$GETQUI wildcard operation resets the queue= >> context, putting me back to the first queue on the system.0 >> 0M >> Is this a bug in f$GETQUI? I've already figured out a way around it, but I8 >> shouldn't have to.  > " > It's not a bug.  It's a feature. > E > The queue manager is a separate process.  The F$GETQUI lexical is aEE > jacket around the SYS$GETQUI system service which, in turn, manages F > a communications channel between your process and the queue manager. > D > That communications channel is single threaded.  There is only oneD > set of context information maintained for your process.  Any queueE > related activity from your process uses that single thread/context.a > B > SHOW QUEUE uses SYS$GETQUI.  And destroys the context created by > your F$GETQUI.K Hmm. I thought that was what it might be... Explains why START /QUEUE workss3 [no wildcard $GETQUI calls] but SHOW QUEUE doesn't.   L What annoys me is that this isn't mentioned, or if it is mentioned, it isn'tK very obvious! Hello OpenVMS documentation - a small note in the help (maybetL in a new section called 'Restrictions') outlining this fact more clearly? ItO does say somewhere IIRC that you can only have one queue context, but I assumedu& this would mean *DCL* queue context...  G So, why isn't there a SAVE_CONTEXT and RESTORE_CONTEXT (or PUSH_CONTEXTkH and POP_CONTEXT) ability built into (F/SYS)$GETQUI? Of course, the queueN manager would have to save the context for you, so it would have to be limitedI to one or two contexts to avoid a denial-of-service, but even the abilityu7 to save and restore one context would be of some use...n  K BTW, the work-around is to stuff all the queue names into a comma-separatedi4 string, then work on them outwith the F$GETQUI call.          Thanks,t	 -Malcolm.s+                                              >  > 	John Briggs   ------------------------------  % Date: Tue, 20 Nov 2001 11:34:28 +0000a( From: Nic Clews <sendspamhere@127.0.0.1>7 Subject: Re: From the deja vu all over again department ) Message-ID: <3BFA3FC4.80DB871F@127.0.0.1>O   Bob Koehler wrote: > ^ > In article <3BF7A9A8.BE148581@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > > H > > (Look at Microsoft who is now dumping X-BOXes on the market at belowQ > > production costs, yet the USA government isn't doing anything to prevent thisH > > very overt dumping.) > H >    And still coming up 50% more than Nintendo.  Must be they think the >    real competition is Sony.  E Imagine it, Xmas morning, and your kids plugging the Xbox into the TVu> and Internet, only to get taken out by the latest billy-virus.  G No thanks I'll stick with the PS. I've got some 'educational' stuff fornG PC and the PS for my 2.5 year old, and guess what, the PS is stable and/F I can let her play for ages, the PC I have to keep restarting when the, application does the eqivilent of an ACCVIO.  6 My PS has been officially renamed the Tubbystation :-) -- -( Regards, Nic Clews CSC Computer Sciences nclews at csc dot comt   ------------------------------  % Date: Tue, 20 Nov 2001 12:14:32 +0000d( From: Nic Clews <sendspamhere@127.0.0.1> Subject: Re: Ghoti :-)) Message-ID: <3BFA4928.8F0C2EEC@127.0.0.1>    Paul Sture wrote:t > < > In article <3BF64307.D1C310A1@Omond.net>, Roy Omond wrote: > > Paul Sture wrote:  > >d* > > > > And then there is always "ghoti"!! > > > >5F > > > What is "ghoti" please? I got a gazillion hits on various searchD > > > engines, but not a single one I looked at told me what it was. > > @ > > And there I was thinking you're a native English speaker :-) > >2/ > Yorkshire. Some would not call it English :-)7 > 9 > For a sample try www.stockdill.freeserve.co.uk/moor :-)   D Ahh, the White Rose people (where of course I'm a native Red Rose of Lancashire).  C We don't need walls, we have the Pennines :-))))))))))))) Then some33 southener drove the M62 through them.... :-))))))))   A (my gaffer is from the county of the white rose and will probably F reprimand me later... I don't intend starting another War of the Roses  on c.o.v., all in jest, honest!) -- x( Regards, Nic Clews CSC Computer Sciences nclews at csc dot com.   ------------------------------    Date: 20 Nov 2001 07:53:40 -0600- From: koehler@encompasserve.org (Bob Koehler)0? Subject: Re: IPF Calling Standard (was: ISV's and VMS on Intel)03 Message-ID: <8Ke4VpcQ9LYZ@eisner.encompasserve.org>   \ In article <3BF98E7A.7CF74AC3@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > Bob Koehler wrote:J >>    DEC C on a VAX passes all arguments on the stack, each argument getsE >>    one or more longwords, the argument list includes the number ofsJ >>    arguments.  On Alpha the first 6 arguments are passed via registers,I >>    each takes up one or more quadwords, and another register describes  >>    all the arguments. > P > Thanks for the description. Out of curiosity, how does VEST handle all of thisO > ? Does it provide an environment where the VAX calling standard can operate ?l- > How did it interface with system services ?j  E    VEST relies heavily on the TIE environment, which makes all thingsl    look much more VAXy..   ------------------------------  % Date: Tue, 20 Nov 2001 09:39:17 -0500i* From: John Reagan <john.reagan@compaq.com>? Subject: Re: IPF Calling Standard (was: ISV's and VMS on Intel) ) Message-ID: <3BFA6B15.3000100@compaq.com>e   JF Mezei wrote:o   > P > Thanks for the description. Out of curiosity, how does VEST handle all of thisO > ? Does it provide an environment where the VAX calling standard can operate ?e- > How did it interface with system services ?  >   F There is additional infomration in the procedure descriptors (enabled H with /TIE on the native compilers and produced by VEST) that is read by B the TIE code that does all the argument mapping for you.  Compile E something with /TIE and look at the compiler's machine code listing. 2I You'll see more info in procedure descriptors.  It is all in the calling  	 standard.t   -- r John Reaganr' Compaq Pascal/{A|I}MACRO Project Leader    ------------------------------  % Date: Tue, 20 Nov 2001 09:58:55 -0500t* From: John Reagan <john.reagan@compaq.com>? Subject: Re: IPF Calling Standard (was: ISV's and VMS on Intel)r) Message-ID: <3BFA6FAF.5000502@compaq.com>a  $ Brian Schenkenberger, VAXman- wrote:  H > The calling standard says nothing about R2-R15 being preserved on the E > Alpha nor does it say anything about preserving R2-R11 on VAX.  R2-rG > R15 Alpha/R2-R11 VAX are defined as the general registers and, if you G > expect them to retain certain values, you need to preserve them.  I'mhG > quite capable of writing values into any of the aforementioned regis-rH > ters on either platform and have them pass values back to the invoker. >   . I see your point (I'll get to it in a minute).  - As for "the calling standard says nothing"...:  F "OpenVMS Calling Standard", part number: AA-QSBBD-TE, OpenVMS Version < 7.3, section 2.1.1, "Scalar Register Use" (VAX Conventions).  F "Registers R2 through R11 are to be preserved across procedure calls."  G Section 3.1.1, "Integer Registers", Table 3-1 "Alpha Integer Registers"t  B "R2-R15   Conventional saved registers.  If a standard-conforming H procedure modifies one of these registers, it must save and restore it."    G Now, back to your concern.  Routines that you describe are outside the MI calling standard.  I was speaking of standard-conforming routines when I   wrote the previous post.  A Returning values in registers is indeed quite common and will be  
 supported.  I JSB routines are "easy" since there is no assumption on what is saved or oE not (the Calling Standard hints at a standard-conforming JSB routine eG that only touches registers that are in the saved mask if its caller). iD IMACRO will not save/restore anything around JSB calls.  BTW, there E isn't a JSB-type instruction on Itanium which makes it a little more ,J intesting.  Also, we have to support JSB routines that RET instead of RSB.  E CALLed routines that also return values in registers are the strange HD beast.  They certainly exist, but are rare.  As you hint at, IMACRO G needs to know that the routine it is about to CALL will return a value hG in some non-standard registers.  If you were doing this in BLISS or C,  @ the caller would have access to the linkage.  But in MACRO, the $ knowledge is "embedded" in the code.  D With the Alpha calling standard being a superset of the VAX calling E standard with respect to preserved registers, AMACRO doesn't have to t> save/restore anything around CALLs (which lets you write your  non-standard routines as well).a  F To handle this situation on Itanium, IMACRO will have a new directive H (tentatively called .CALL_LINKAGE) that lets you declare the linkage of F a CALLed routine that also returns values in non-standard places (ie, E not in R0 or R1).  If we see a .CALL_ENTRY with a OUTPUT clause that aG lists anything besides R0 and R1, you'll get a warning that you need a lE .CALL_LINKAGE in all MACRO modules that call it.  You can either put iD them in your code or we'll have some way of "preloading" them via a E command line options or some sort...  We haven't go to those details wH yet.  The .CALL_LINKAGE will tell IMACRO which registers that it should ! not save or restore around CALLs.m   -- n John Reagana' Compaq Pascal/{A|I}MACRO Project Leader    ------------------------------  # Date: Tue, 20 Nov 2001 16:27:48 GMTd= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)a? Subject: Re: IPF Calling Standard (was: ISV's and VMS on Intel)'0 Message-ID: <00A0553E.D865CFC9@SendSpamHere.ORG>  V In article <3BFA6FAF.5000502@compaq.com>, John Reagan <john.reagan@compaq.com> writes:% >Brian Schenkenberger, VAXman- wrote:  >nI >> The calling standard says nothing about R2-R15 being preserved on the cF >> Alpha nor does it say anything about preserving R2-R11 on VAX.  R2-H >> R15 Alpha/R2-R11 VAX are defined as the general registers and, if youH >> expect them to retain certain values, you need to preserve them.  I'mH >> quite capable of writing values into any of the aforementioned regis-I >> ters on either platform and have them pass values back to the invoker., >>   >n/ >I see your point (I'll get to it in a minute).u  H The point was that your initial response seems to indicate that the cal-G ling standard requires the preservation of the registers cited without y reservation.     >p. >As for "the calling standard says nothing"... > G >"OpenVMS Calling Standard", part number: AA-QSBBD-TE, OpenVMS Version H= >7.3, section 2.1.1, "Scalar Register Use" (VAX Conventions).  >-G >"Registers R2 through R11 are to be preserved across procedure calls."m >aH >Section 3.1.1, "Integer Registers", Table 3-1 "Alpha Integer Registers" >LC >"R2-R15   Conventional saved registers.  If a standard-conforming mI >procedure modifies one of these registers, it must save and restore it.".H  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  G Also, since a null frame is a standard conforming procedure and it doesvH NOT require the preservation of registers across an invocation, the reg-G ister preservation requirement statement in 3.1.1 does seem to be some-t what overzealous.y      B >Returning values in registers is indeed quite common and will be  >supported.i  E As long as there is no change of access mode, this practice is OK.  ItE have ported a number of applications which expected to call a routinehE in kernel mode and return values in registers.  AFAIK, this practice pE was never sanctioned even on VAX and it goes to hell in a hurry on an- Alpha.   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMf            cJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbesd   ------------------------------    Date: 20 Nov 2001 11:12:02 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)a? Subject: Re: IPF Calling Standard (was: ISV's and VMS on Intel)?3 Message-ID: <sawd$vJoebEl@eisner.encompasserve.org>e  p In article <00A0553E.D865CFC9@SendSpamHere.ORG>, system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) writes:X > In article <3BFA6FAF.5000502@compaq.com>, John Reagan <john.reagan@compaq.com> writes:& >>Brian Schenkenberger, VAXman- wrote: >>J >>> The calling standard says nothing about R2-R15 being preserved on the G >>> Alpha nor does it say anything about preserving R2-R11 on VAX.  R2-sI >>> R15 Alpha/R2-R11 VAX are defined as the general registers and, if younI >>> expect them to retain certain values, you need to preserve them.  I'meI >>> quite capable of writing values into any of the aforementioned regis-,J >>> ters on either platform and have them pass values back to the invoker. >>>  >>0 >>I see your point (I'll get to it in a minute). > J > The point was that your initial response seems to indicate that the cal-I > ling standard requires the preservation of the registers cited without o > reservation.    F I'll vote with John on this semantic question.  The calling _standard_E is that to which you must conform in order for my Ada module and your,E Macro module to interact.  Macro and Bliss provide you the ability to C do other things.  C is also available for cases where you are beingk paid by the hour.E   ------------------------------  % Date: Tue, 20 Nov 2001 11:45:17 -0500e* From: John Reagan <john.reagan@compaq.com>? Subject: Re: IPF Calling Standard (was: ISV's and VMS on Intel) ) Message-ID: <3BFA889D.1000102@compaq.com>o  $ Brian Schenkenberger, VAXman- wrote:   > I > Also, since a null frame is a standard conforming procedure and it doesIJ > NOT require the preservation of registers across an invocation, the reg-I > ister preservation requirement statement in 3.1.1 does seem to be some-a > what overzealous.r >  >   F Not all null frame procedures are standard conforming just like there C are stack frame procedures that aren't standard conforming (ie, my  G previous example of a CALL that returns values in registers other than  H R0/R1).  Actually, the "CALL that returns values in registers" could be $ written with any of the frame types.  F A null frame procedure that modifies registers is outside the calling G standard.  That doesn't mean they don't exist, they just don't conform   to the calling standard.   -- h John Reagane' Compaq Pascal/{A|I}MACRO Project Leaderu   ------------------------------  # Date: Tue, 20 Nov 2001 17:58:48 GMT.= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)a? Subject: Re: IPF Calling Standard (was: ISV's and VMS on Intel)i0 Message-ID: <00A0554B.8F2501A6@SendSpamHere.ORG>  V In article <3BFA889D.1000102@compaq.com>, John Reagan <john.reagan@compaq.com> writes:% >Brian Schenkenberger, VAXman- wrote:m >  >> iJ >> Also, since a null frame is a standard conforming procedure and it doesK >> NOT require the preservation of registers across an invocation, the reg-bJ >> ister preservation requirement statement in 3.1.1 does seem to be some- >> what overzealous. >> n >> B > G >Not all null frame procedures are standard conforming just like there nD >are stack frame procedures that aren't standard conforming (ie, my H >previous example of a CALL that returns values in registers other than I >R0/R1).  Actually, the "CALL that returns values in registers" could be 9% >written with any of the frame types.e >.G >A null frame procedure that modifies registers is outside the calling DH >standard.  That doesn't mean they don't exist, they just don't conform  >to the calling standard.g  J I see no register usage caveats in the calling standard description of the> Null Procedure.  Can you give a chapter and section reference?   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMe            eJ   "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: Tue, 20 Nov 2001 10:00:40 +0000e% From: Alan Greig <a.greig@virgin.net>i0 Subject: Re: Is it a DEC C problem, or is it me?8 Message-ID: <k5akvt0d4k0264rh3o8kbtcn08v6s63uaa@4ax.com>  @ On Mon, 19 Nov 2001 10:44:51 -0500, <ed.vogel@compaq.com> wrote:    = >    As a lowly engineer, I'm not in a position to talk about0: >    future plans for either the products or the engineers" >    (at least not in this forum).  C One of the things from Friday's DECUS in London was that DEC C is a F dead end product. and will not be ported to IA64. Instead Intel C willB become the  standard C on Intel VMS. Unlike DEC C which can handle? VAXC syntax, Intel C on VMS will not. At least not targeted for ( initial release and possibly not at all.  / At least that's how I understood what was said.r   >n >i   -- Alan   ------------------------------  % Date: Tue, 20 Nov 2001 06:01:49 -0500n- From: JF Mezei <jfmezei.spamnot@videotron.ca>$0 Subject: Re: Is it a DEC C problem, or is it me?, Message-ID: <3BFA3815.5D2F3C1B@videotron.ca>   Alan Greig wrote:wE > One of the things from Friday's DECUS in London was that DEC C is anH > dead end product. and will not be ported to IA64. Instead Intel C will& > become the  standard C on Intel VMS.  G But isn't that the same since Compaq donated all its compiler folks andR software to Intel ?n     > Unlike DEC C which can handleyA > VAXC syntax, Intel C on VMS will not. At least not targeted foru* > initial release and possibly not at all.  L So Intel will remove the code in DEC C that was for support of VAX C syntax.  L There goes the promise that customers would just have to recompile user-mode: applications without any changes when/if VMS gets to IA64.  K What about the other languages such as Cobol, ADA etc etc ? (Does APL stillb exist ?)   ------------------------------  % Date: Tue, 20 Nov 2001 11:14:58 +0000u( From: Nic Clews <sendspamhere@127.0.0.1>0 Subject: Re: Is it a DEC C problem, or is it me?) Message-ID: <3BFA3B32.99AA3F8C@127.0.0.1>M   Alan Greig wrote:  > B > On Mon, 19 Nov 2001 10:44:51 -0500, <ed.vogel@compaq.com> wrote: > ? > >    As a lowly engineer, I'm not in a position to talk aboutl< > >    future plans for either the products or the engineers$ > >    (at least not in this forum). > E > One of the things from Friday's DECUS in London was that DEC C is a7H > dead end product. and will not be ported to IA64. Instead Intel C willD > become the  standard C on Intel VMS. Unlike DEC C which can handleA > VAXC syntax, Intel C on VMS will not. At least not targeted fori* > initial release and possibly not at all. > 1 > At least that's how I understood what was said.N   Alan,   A I was under the impression they were going to 'teach' the Intel C H compiler the "DEC dialects" so it would not be an issue. ANSI C code was no problem of course.y  @ I would imagine the reverse is true for FORTRAN, using DEC (Cpq)H FORTRAN, they would have to ensure it copes with the Intel requirements. -- w( Regards, Nic Clews CSC Computer Sciences nclews at csc dot com    ------------------------------  % Date: Tue, 20 Nov 2001 16:05:03 +0100I< From: "Martin Vorlaender" <martin.vorlaender@pdv-systeme.de>0 Subject: Re: Is it a DEC C problem, or is it me?4 Message-ID: <9tdrf7$1v6ed$1@ID-56200.news.dfncis.de>   JF Mezei wrote... I >Remember that if someone is still with VAX-C standard on an alpha, it is: >because there is a reason.4  J And that reason would be (besides not going through the painful process of( replacing all the VAXCisms by ANSIisms)?  F When we first put one of our VAXC-developed projects through the DEC CG compiler it would throw pages and pages of warning and errors at us. WehG looked after all of them, and even found some programming errors in the  process.   cu,    Martin -- yJ One OS to rule them all       | Martin Vorlaender  |  VMS & WNT programmer7 One OS to find them           | work: mv@pdv-systeme.desJ One OS to bring them all      |   http://www.pdv-systeme.de/users/martinv/? And in the Darkness bind them.| home: martin@radiogaga.harz.de e   ------------------------------  % Date: Tue, 20 Nov 2001 16:13:18 +0100.< From: "Martin Vorlaender" <martin.vorlaender@pdv-systeme.de>0 Subject: Re: Is it a DEC C problem, or is it me?4 Message-ID: <9tdrum$20gfg$1@ID-56200.news.dfncis.de>   Nic Clews wrote... >JF Mezei wrote:I >> Step by step, VMS is being dumbed down to NT until the migration to NT- >> will be simple. > # > You can also look at it this way:h >@H > Using a _common_ compiler on multiple platforms (including VMS) allowsF > code from the lesser worlds to be ported much more easily to the VMS > world.  K I'm still amazed why Intel wouldn't want the high-quality, highly-flexible,n3 highly-optimizing VMS C compiler as the common one.V  A But then, I'm still amazed why Compaq would "sell" their compilerr departments with Alpha, too.   cu,c   Martin -- rJ One OS to rule them all       | Martin Vorlaender  |  VMS & WNT programmer7 One OS to find them           | work: mv@pdv-systeme.dehJ 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   ------------------------------    Date: 20 Nov 2001 07:35:31 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)e0 Subject: Re: Is it a DEC C problem, or is it me?3 Message-ID: <Tq4qNUjL7yrv@eisner.encompasserve.org>.  T In article <3BFA3B32.99AA3F8C@127.0.0.1>, Nic Clews <sendspamhere@127.0.0.1> writes: > Alan Greig wrote:c >> .C >> On Mon, 19 Nov 2001 10:44:51 -0500, <ed.vogel@compaq.com> wrote:  >> s@ >> >    As a lowly engineer, I'm not in a position to talk about= >> >    future plans for either the products or the engineersa% >> >    (at least not in this forum).n >> rF >> One of the things from Friday's DECUS in London was that DEC C is aI >> dead end product. and will not be ported to IA64. Instead Intel C willpE >> become the  standard C on Intel VMS. Unlike DEC C which can handlerB >> VAXC syntax, Intel C on VMS will not. At least not targeted for+ >> initial release and possibly not at all.i >> I2 >> At least that's how I understood what was said. >  > Alan,m > C > I was under the impression they were going to 'teach' the Intel CtJ > compiler the "DEC dialects" so it would not be an issue. ANSI C code was > no problem of course.  > B > I would imagine the reverse is true for FORTRAN, using DEC (Cpq)J > FORTRAN, they would have to ensure it copes with the Intel requirements.  C At September's US DECUS/CETS conference they said DEC C and DEC C++AA would be ported to Itanium, but at some point further developmenti@ on those would be stopped and Intel compilers would be the routeA forward for future C language developments.  Certain VMS-specifichB additions would be made to the Intel code, but VAX-C support would$ likely not be among those additions.  J As I recall that position was confirmed in yesterday's ISV teleconference,; but I don't pay very close attention to issues involving C.    ------------------------------  % Date: Tue, 20 Nov 2001 13:53:31 +0000h% From: Alan Greig <a.greig@virgin.net> 0 Subject: Re: Is it a DEC C problem, or is it me?8 Message-ID: <qmnkvtksneludf9lmi9rmebafce9breddd@4ax.com>  F On Tue, 20 Nov 2001 11:14:58 +0000, Nic Clews <sendspamhere@127.0.0.1> wrote:   >uB >I was under the impression they were going to 'teach' the Intel CI >compiler the "DEC dialects" so it would not be an issue. ANSI C code wasd >no problem of course.  @ I specifically asked for clarification on this point Nic and the? answer I recall is that they intended to have Intel add the DECeE dialects but that the timing and plans would be in the hands of InteleC and VAXC compatibility would probably not be there from day one and E 100% compatibility ,might never be provided. Timing was not under thea control of Compaq.   >uA >I would imagine the reverse is true for FORTRAN, using DEC (Cpq)sI >FORTRAN, they would have to ensure it copes with the Intel requirements.h  E That point was addressed as well. The gist of the answer, as I recalluF was that DEC Fortran was considered the industry reference so not much work would be required on it.   F It was also explicitly stated that there are no plans to port DEC Ada.% I know you will remember this Nic :-)  -- Alan   ------------------------------  % Date: Tue, 20 Nov 2001 14:00:07 +0000i% From: Alan Greig <a.greig@virgin.net>r0 Subject: Re: Is it a DEC C problem, or is it me?8 Message-ID: <t2okvto2a7eugc38a08up9u1n9tna9sfpv@4ax.com>  , On Tue, 20 Nov 2001 06:01:49 -0500, JF Mezei% <jfmezei.spamnot@videotron.ca> wrote:e   >Alan Greig wrote: >cH >But isn't that the same since Compaq donated all its compiler folks and >software to Intel ?  E That's what I thought until Friday but it seems that Intel don't wantn DEC C so it will vanish.   >w  >> Unlike DEC C which can handleB >> VAXC syntax, Intel C on VMS will not. At least not targeted for+ >> initial release and possibly not at all.I >GM >So Intel will remove the code in DEC C that was for support of VAX C syntax.l  ( Nope they just won't use the DEC C code.  M >There goes the promise that customers would just have to recompile user-moded; >applications without any changes when/if VMS gets to IA64.I  F Certainly there was no promise that you will be able to compile a VAXCB C program. ANSI C was expected to be ok. It still seemed to be the: intention to have Intel add this support eventually but my/ interpretation was that this was not a promise.h   >sL >What about the other languages such as Cobol, ADA etc etc ? (Does APL still	 >exist ?)s  E DEC Ada is not to be ported. DEC Basic, Fortran, Cobol, Bliss were on 	 the list.   A This was the first I had heard that C on IA64 would come from thee( Intel code base rather than the DEC one. -- Alan   ------------------------------  % Date: Tue, 20 Nov 2001 09:29:58 -0500> From: <ed.vogel@compaq.com>50 Subject: Re: Is it a DEC C problem, or is it me?3 Message-ID: <HNtK7.1761$RL6.58374@news.cpqcorp.net>n  : "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in messageF | At September's US DECUS/CETS |conference they said DEC C and DEC C++C | would be ported to Itanium, but at some point further developmentgB | on those would be stopped and Intel compilers would be the routeC | forward for future C language developments.  Certain VMS-specific D | additions would be made to the Intel code, but VAX-C support would& | likely not be among those additions. |nL | As I recall that position was confirmed in yesterday's ISV teleconference,= | but I don't pay very close attention to issues involving C.        O.K....I will say more.e  A     Larry's statement is almost correct.  We are porting Compaq CgB     to IA64 for OpenVMS.  We expect this product to support almostG     all of the current language.  There will be some differences in thee>     area of asm's and probably things such as #pragma linkage.  D     He is also correct when he says that at some point in the futureI     Intel supplied compilers will also be released.  These compilers will A     support some, but not all Compaq C extensions.  For some timen?     we expect to support both compilers.  The Compaq C compiler^F     will be there for portability, the Intel compiler for performance.  A     The one item where Larry *may* be incorrect is the porting of ?     Compaq C++.  Because Intel's C++ language is quite close toe9     Compaq C++ language, we are hoping to only ship a C++sC     compiler supplied by Intel.  We will only do this if we believes8     the Intel compiler supports enough of the Compaq C++2     language extenstions to satisfy our customers.  B     The goal of the C/C++ engineering teams is to support Compaq's0     OpenVMS IA64 strategy of "recompile and go".  4                                             Ed VogelA                                             Compaq C Engineering.    ------------------------------  % Date: Tue, 20 Nov 2001 09:33:47 -0500I- From: JF Mezei <jfmezei.spamnot@videotron.ca> 0 Subject: Re: Is it a DEC C problem, or is it me?, Message-ID: <3BFA69CA.6F1E3886@videotron.ca>  * re: eventual widthdrawal of vax-c support.  H You know, this is quite smart. First port existing  DEC-C compiler. ThisN reduces the pain of being forced off Alpha and only that IA64 thing. A year orN two later, once the customer is on that IA64 thing, you force him off his lastM vestige of Digital quality and onto a painful migration to the Intel compilern without an OS change.:  K A few years later, with all his programs restructured to compile on Intel'so0 compiler, moving to NT will be that much easier.  V Step by step, VMS is being dumbed down to NT until the migration to NT will be simple.   ------------------------------  % Date: Tue, 20 Nov 2001 09:36:41 -0500l- From: JF Mezei <jfmezei.spamnot@videotron.ca>t0 Subject: Re: Is it a DEC C problem, or is it me?, Message-ID: <3BFA6A78.9B0F7EAD@videotron.ca>   Alan Greig wrote:iH > Certainly there was no promise that you will be able to compile a VAXC* > C program. ANSI C was expected to be ok.  K The promise I heard was not language specific. It was that one could simply G recompile your user mode VMS applications onto that IA64 version of VMSi when/iof it materialises.e  M If VAX-C support which is part of the Digital compilers on VMS is removed, ithD means that you will not be able to just recompile all your user mode applications to IA64.d  H Remember that if someone is still with VAX-C standard on an alpha, it is because there is a reason.   ------------------------------  % Date: Tue, 20 Nov 2001 14:43:43 +0000b( From: Nic Clews <sendspamhere@127.0.0.1>0 Subject: Re: Is it a DEC C problem, or is it me?) Message-ID: <3BFA6C1F.26CA0D12@127.0.0.1>u   JF Mezei wrote:i > , > re: eventual widthdrawal of vax-c support. > J > You know, this is quite smart. First port existing  DEC-C compiler. ThisP > reduces the pain of being forced off Alpha and only that IA64 thing. A year orP > two later, once the customer is on that IA64 thing, you force him off his lastO > vestige of Digital quality and onto a painful migration to the Intel compilera > without an OS change.  > M > A few years later, with all his programs restructured to compile on Intel'sc2 > compiler, moving to NT will be that much easier. > X > Step by step, VMS is being dumbed down to NT until the migration to NT will be simple.  ! You can also look at it this way:r  F Using a _common_ compiler on multiple platforms (including VMS) allowsD code from the lesser worlds to be ported much more easily to the VMS world.  H JF, I think you're much more of a coder/software engineer than I, so I'd: be interested in serious comment about possibilities here. -- -( Regards, Nic Clews CSC Computer Sciences nclews at csc dot comM   ------------------------------  % Date: Tue, 20 Nov 2001 10:00:45 -0500:- From: JF Mezei <jfmezei.spamnot@videotron.ca>n0 Subject: Re: Is it a DEC C problem, or is it me?, Message-ID: <3BFA701A.CD140DC2@videotron.ca>   Nic Clews wrote:H > Using a _common_ compiler on multiple platforms (including VMS) allowsF > code from the lesser worlds to be ported much more easily to the VMS > world.  H That would be true if you believed that Compaq/HP wantyed to promote andN expand the VMS marketplace. And until this happens, it is safer to assume thatM Compaq/HO wants to steer customers to "industry standard" stuff and away fromd their own products.i   ------------------------------  % Date: Tue, 20 Nov 2001 15:25:20 -0000,- From: wspencer@ap.nospam.org (Warren Spencer)v0 Subject: Re: Is it a DEC C problem, or is it me?7 Message-ID: <915F63E1Dwarrenspencer1977@207.126.101.97>   ) a.greig@virgin.net (Alan Greig) wrote in A- <k5akvt0d4k0264rh3o8kbtcn08v6s63uaa@4ax.com>:s  A >On Mon, 19 Nov 2001 10:44:51 -0500, <ed.vogel@compaq.com> wrote:t >h >j> >>    As a lowly engineer, I'm not in a position to talk about; >>    future plans for either the products or the engineers # >>    (at least not in this forum).e >nD >One of the things from Friday's DECUS in London was that DEC C is aG >dead end product. and will not be ported to IA64. Instead Intel C will'C >become the  standard C on Intel VMS. Unlike DEC C which can handle @ >VAXC syntax, Intel C on VMS will not. At least not targeted for) >initial release and possibly not at all.2 >o0 >At least that's how I understood what was said. >g >> >> >u >--: >Alan   L Geeze, I was hoping for re-compile and go.  There's little chance the VAX-C H on Alpha/OpenVMS applications around here are going to get the required 7 infusion of effort ($$$) to make them ansi-c compliant.   I After all that hot air from the top about how painless Compaq would make  K this port - now it turns out to be darned expensive.  I should really stop LK listening to anything that comes the top of Compaq.  Or perhaps invert its   meaning to derive the truth.   ws   -- C   Warren Spencer' Senior Software Engineer (not a writer)I The Associated Press  L ** My employer does not necessarily agree with my statements - neither do I  **   ------------------------------  # Date: Tue, 20 Nov 2001 15:28:11 GMT- From: danco@pebble.org ()e0 Subject: Re: Is it a DEC C problem, or is it me?- Message-ID: <slrn9vktkb.c7q.danco@pebble.org>I  J On Tue, 20 Nov 2001 14:00:07 +0000, Alan Greig <a.greig@virgin.net> wrote:  B >This was the first I had heard that C on IA64 would come from the) >Intel code base rather than the DEC one.u  F And this is certainly very bad news for us.  I can see about a millionG lines of our DEC C code is going to be extremely time consuming to portlF without a working /STANDARD=VAXC qualifier.  Perhaps we can limp alongH with the equivilent of a /STANDARD=RELAXED.  I'm not going to be lookingC forward to this port.  It's going to be a nightmare without a DEC Ce	 compiler!d   - DanC   ------------------------------  % Date: Tue, 20 Nov 2001 11:47:14 -0500m- From: JF Mezei <jfmezei.spamnot@videotron.ca>l0 Subject: Re: Is it a DEC C problem, or is it me?, Message-ID: <3BFA8907.CF493431@videotron.ca>   Martin Vorlaender wrote:H > When we first put one of our VAXC-developed projects through the DEC CI > compiler it would throw pages and pages of warning and errors at us. WeRI > looked after all of them, and even found some programming errors in the0
 > process.  N I did the same. had to go though all of the programs and change all referencesN to character arrays that were previously obvius with the & symbol to signify IL was passing the pointer to the array. And I had to build function prototypes; for software that had run for a long time without problems.U  N You get the hang of it. But it still takes time. That is where the lack of theJ VAX-C stuff could hurt some customers for whom the task of converting from$ VAX-C to DEC-C would be a large job.  L And when they kill DEC-C and we are forced to Intel-C, how much changes will have to be made ?    ------------------------------  % Date: Tue, 20 Nov 2001 11:56:01 -0500h2 From: rdeininger@mindspring.com (Robert Deininger)0 Subject: Re: Is it a DEC C problem, or is it me?L Message-ID: <rdeininger-2011011156020001@user-2iveans.dialup.mindspring.com>  7 In article <915F63E1Dwarrenspencer1977@207.126.101.97>, . wspencer@ap.nospam.org (Warren Spencer) wrote:    N > Geeze, I was hoping for re-compile and go.  There's little chance the VAX-C J > on Alpha/OpenVMS applications around here are going to get the required 9 > infusion of effort ($$$) to make them ansi-c compliant.j > K > After all that hot air from the top about how painless Compaq would make 0M > this port - now it turns out to be darned expensive.  I should really stop  M > listening to anything that comes the top of Compaq.  Or perhaps invert its a > meaning to derive the truth.    I  In article <slrn9vktkb.c7q.danco@pebble.org>, danco@pebble.org () wrote:n   H > And this is certainly very bad news for us.  I can see about a millionI > lines of our DEC C code is going to be extremely time consuming to portrH > without a working /STANDARD=VAXC qualifier.  Perhaps we can limp alongJ > with the equivilent of a /STANDARD=RELAXED.  I'm not going to be lookingE > forward to this port.  It's going to be a nightmare without a DEC Ce > compiler!S     Replying to to posts...t  J You guys (and anyone else facing similar difficulties) need to tell CompaqG about it NOW, through offical channels. Calmly explain to them how this,C will impact your work.  If you don't have an official channel, theneD emailing the right folks at Compaq will probably do almost as well. G Bleating in comp.os.vms is likely NOT an effective way to get Compaq to. notice.e  G If enough people need support for VAXC code on IPF, I expect Compaq cantF find a way to provide it.  But they need to know, or they won't do the extra work.    -- o Robert Deininger rdeininger@mindspring.comV   ------------------------------  % Date: Tue, 20 Nov 2001 18:13:24 -0000t- From: wspencer@ap.nospam.org (Warren Spencer)w0 Subject: Re: Is it a DEC C problem, or is it me?7 Message-ID: <915F8EEE2warrenspencer1977@207.126.101.97>u  5 rdeininger@mindspring.com (Robert Deininger) wrote inmB <rdeininger-2011011156020001@user-2iveans.dialup.mindspring.com>:   8 >In article <915F63E1Dwarrenspencer1977@207.126.101.97>,/ >wspencer@ap.nospam.org (Warren Spencer) wrote:v >v >sH >> Geeze, I was hoping for re-compile and go.  There's little chance theG >> VAX-C on Alpha/OpenVMS applications around here are going to get theeC >> required infusion of effort ($$$) to make them ansi-c compliant.6 >> rF >> After all that hot air from the top about how painless Compaq wouldF >> make this port - now it turns out to be darned expensive.  I shouldF >> really stop listening to anything that comes the top of Compaq.  Or2 >> perhaps invert its meaning to derive the truth. >  >,C > In article <slrn9vktkb.c7q.danco@pebble.org>, danco@pebble.org ()>	 > wrote: w > I >> And this is certainly very bad news for us.  I can see about a millioneE >> lines of our DEC C code is going to be extremely time consuming tonH >> port without a working /STANDARD=VAXC qualifier.  Perhaps we can limpI >> along with the equivilent of a /STANDARD=RELAXED.  I'm not going to bewH >> looking forward to this port.  It's going to be a nightmare without a >> DEC C compiler! >e >  >Replying to to posts... > D >You guys (and anyone else facing similar difficulties) need to tell  J I appreciate the advice, and the sentiment Robert, however I have no such I need.  Instead I believe it is Compaq that *needs* to either communicate EG clearly (stop fibbing) and poll their customers for their requirements.   F >Compaq about it NOW, through offical channels. Calmly explain to themH >how this will impact your work.  If you don't have an official channel,I >then emailing the right folks at Compaq will probably do almost as well. H >Bleating in comp.os.vms is likely NOT an effective way to get Compaq to >notice.  J Thank you, and in my case, I'm aware of that.  I also fill out the online L questionaires as they come up.  Would you happen have the email address for > the person at Compaq in charge of caring about customer needs?   >nH >If enough people need support for VAXC code on IPF, I expect Compaq canG >find a way to provide it.  But they need to know, or they won't do the- >extra work. >-  L True enough - and I consider the onus to be on them to find out.  I suspect H others here might agree, but no one is holding their breath waiting for 7 Compaq to call, I'm sure.  Aw screw it - who wants pie?    ws   -- 1   Warren Spencer' Senior Software Engineer (not a writer)  The Associated Press  L ** My employer does not necessarily agree with my statements - neither do I  **   ------------------------------   Date: 20 Nov 2001 08:14:35 GMT) From: leslie@clio.rice.edu (Jerry Leslie)h Subject: Re: Life After Alphar' Message-ID: <9td3db$q4l$1@joe.rice.edu>   $ John Plemons (john@mavin.com) wrote:N : Folks I think the tolling of the death bell for Alpha is a little early...  L : If you check the Samsung website you will see its alive and well, Samsung N : is making a series of boards and has a worldwide network of VAR's to market 
 : them....M : Check out http://www.samsungelectronics.com do a search on the 21264 there tN : is a whole section on the Alpha, with links to their worldwide distributors  : for the product....a :h3 Interesting. The following URLs would support that:s  F   http://samsungelectronics.com/semiconductors/Alpha_CPU/Alpha_CPU.htm  !   http://www.alpha-processor.com/   '   http://www.api-networks.com/products/   D but someone from API posted recently that they were out of the ALPHA	 business.0  A Hewlett Packard has licensed its OpenMail product to Samsung SDS:C  :    http://www.openmail.com/cyc/om/00/showfile.cgi?100-1757D    HP and Samsung SDS Sign Licensing Agreement for OpenMail Software  :    http://www.openmail.com/cyc/om/00/showfile.cgi?100-1758    OpenMail Q and A   A OpenMail on a supported unix variant is a drop-in replacement fort Microsoft Exchange.     4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------  + Date: Tue, 20 Nov 2001 09:50:19 +0000 (UTC) 9 From: Roar =?iso-8859-1?Q?Thron=E6s?= <roart@nvg.ntnu.no>i Subject: Re: Life After Alphaa- Message-ID: <9td90r$aii$1@tyfon.itea.ntnu.no>   5 Andrew Swallow <andrew.swallow@baesystems.com> wrote:t  / : IBM used to be a Cash Register and time clocks5 : company.  Being a marketing company has allowed IBMd1 : to survive the change over to type writers and s) : computers.  Its rivals no longer exist.e  H I have read some books about IBM history, and processing of huge amountsH of data was done very early. (At least in Hollerith's company, which was: one of the 3 that merged and a bit later got known as IBM)   -- h
 -Roar Thronsb   ------------------------------  % Date: Tue, 20 Nov 2001 11:00:34 +0100t' From: Carsten Gester <pentyern@gmx.net>B Subject: Re: Life After Alphae- Message-ID: <9td9jv$c7v$1@tyfon.itea.ntnu.no>a   Jerry Leslie wrote:   & > John Plemons (john@mavin.com) wrote:E > : Folks I think the tolling of the death bell for Alpha is a little,H > : early... If you check the Samsung website you will see its alive andJ > : well, Samsung is making a series of boards and has a worldwide network > : of VAR's to market them.... H > : Check out http://www.samsungelectronics.com do a search on the 21264H > : there is a whole section on the Alpha, with links to their worldwide$ > : distributors for the product.... > :o5 > Interesting. The following URLs would support that:u > H >   http://samsungelectronics.com/semiconductors/Alpha_CPU/Alpha_CPU.htm > # >   http://www.alpha-processor.com/b > ) >   http://www.api-networks.com/products/h > F > but someone from API posted recently that they were out of the ALPHA > business.e  L Yes, I've asked about Samsungs involvement in the future of Alpha and I got K the answer from Terry C. Shannon that they focused more on the netwprk and r. transport stuff than on the Alpha chip itself.    hC > Hewlett Packard has licensed its OpenMail product to Samsung SDS:  > < >    http://www.openmail.com/cyc/om/00/showfile.cgi?100-1757F >    HP and Samsung SDS Sign Licensing Agreement for OpenMail Software > < >    http://www.openmail.com/cyc/om/00/showfile.cgi?100-1758 >    OpenMail Q and Ae > C > OpenMail on a supported unix variant is a drop-in replacement for  > Microsoft Exchange.c >  > 6 > --Jerry Leslie     (my opinions are strictly my own)  I I think the problem is that everybody cries Alpha is dead. If I would be tK someone who has to buy a new high performance system and I only hear about eG Alpha that this system is dead, I wouldn't buy an Alpha system. And if  K there is no request for Alpha systems Alpha is dead. If the request is big tL enough Samsung will perhaps develop the chip further on, at least I hope so. Regardsa Carstent   ------------------------------  % Date: Tue, 20 Nov 2001 11:47:49 +0000m% From: Alan Greig <a.greig@virgin.net>A Subject: Re: Life After Alphao8 Message-ID: <1dgkvtoiqau1fl0rgn6i93us6usngbmdg4@4ax.com>  4 On Mon, 19 Nov 2001 03:48:25 GMT, "Terry C. Shannon"" <terryshannon@mediaone.net> wrote:   ...- >> >aK >Given that Power4 is a pretty decent piece of work, do you think IBM wouldo  F But according to Compaq's analysis Power4  is a dead end architecture.E Can't remember the name of the (senior) Compaq Alpha guy who gave therC presentation in London on Friday. Should have been Dave Fenwick butlE there was a last minute change. Anyone want to jump in with the name?   B Compaq's analysis said that IA64 would blow away everyone else andE IBM, AMD, Sun will all eventually have to jump on the IA64 bandwagon.uF The reason being that none of them could afford to keep up with Intel.F Following this logic Alpha had to go because Compaq couldn't afford to keep up either.T  D Asked what Plan B was if IA64 failed the answer was there is no plan B.  J >consider it worthwhile to add Alpha to their portfolio? Assuming that theI >VMS to IPF port works (I think it will), VMS no longer is tied to Alpha.e >oH >And it wouldn't be all that difficult to a Power4 port of the IPF-ified >VMS...F >D   -- Alan   ------------------------------  % Date: Tue, 20 Nov 2001 12:30:52 +0000 ( From: Nic Clews <sendspamhere@127.0.0.1> Subject: Re: Life After Alpha ) Message-ID: <3BFA4CFC.32C55F38@127.0.0.1>I   Alan Greig wrote: H > But according to Compaq's analysis Power4  is a dead end architecture.G > Can't remember the name of the (senior) Compaq Alpha guy who gave thehE > presentation in London on Friday. Should have been Dave Fenwick butaG > there was a last minute change. Anyone want to jump in with the name?b  H Doug Williams, and I recall you being nice to him despite your hard (and, good) line of questions. Polite to the last.  D > Compaq's analysis said that IA64 would blow away everyone else andG > IBM, AMD, Sun will all eventually have to jump on the IA64 bandwagon.sH > The reason being that none of them could afford to keep up with Intel.H > Following this logic Alpha had to go because Compaq couldn't afford to > keep up either.   B Interestingly I can report from the IBM camp than EVEN THEY do notD believe their Power4 will dominate. They reckon that Intel will quitC fabbing the IA32's and such apps will reply on the emulation of theaD IA64s. They see only a niche market for their microprocessors and an explosion in the use of IA64.   F > Asked what Plan B was if IA64 failed the answer was there is no plan > B.  F With the lack of an accurate crystal ball, I think given the position,F they are choosing a path I would probably follow in the circumstances,E and hopefully they won't repeat the mistakes of the past. Intel's notmB going to go away in the short term, they even have a vague idea atF marketing. IBM are in the position they can hedge their bets, which isF what I currently see them doing, but even that weakens IBM's position.   -- p( Regards, Nic Clews CSC Computer Sciences nclews at csc dot coms   ------------------------------  # Date: Tue, 20 Nov 2001 14:22:01 GMT2% From: Milton <mbhewitt@optonline.net>z Subject: Re: Life After Alphaa8 Message-ID: <lvokvtg251t0qa9hl8eebvhbojthp7e1tn@4ax.com>  C On Tue, 20 Nov 2001 11:47:49 +0000, Alan Greig <a.greig@virgin.net>  wrote:  5 >On Mon, 19 Nov 2001 03:48:25 GMT, "Terry C. Shannon" # ><terryshannon@mediaone.net> wrote:t >m >... >>>s >>L >>Given that Power4 is a pretty decent piece of work, do you think IBM would > G >But according to Compaq's analysis Power4  is a dead end architecture.   	 Say what?m   			SPECint2000 SPECfp2000  			Base Peak Base Peak      " 1.3 GHz Power4 	790 814 1098 1169 $ 1.0 GHz 21264C		621 679   776   960 % 800 MHz Itanium 	358 365   715   715 5% http://www.aceshardware.com/#55000402g  > Some pretty impressive numbers for a relatively new architect,' *especially* when compared to the IA64.7  F >Can't remember the name of the (senior) Compaq Alpha guy who gave theD >presentation in London on Friday. Should have been Dave Fenwick butF >there was a last minute change. Anyone want to jump in with the name? >IC >Compaq's analysis said that IA64 would blow away everyone else and F >IBM, AMD, Sun will all eventually have to jump on the IA64 bandwagon.G >The reason being that none of them could afford to keep up with Intel. G >Following this logic Alpha had to go because Compaq couldn't afford tom >keep up either. >IE >Asked what Plan B was if IA64 failed the answer was there is no planw >B.o  + Plan B should be -> buy a lot of IBM stock.a   Cheers,  Milton   ------------------------------    Date: 20 Nov 2001 06:23:24 -0800( From: bob@instantwhip.com (Bob Ceculski) Subject: Re: Life After Alpha = Message-ID: <d7791aa1.0111200623.621eda92@posting.google.com>h  h dashw459@aol.comeatspam (Doug W.) wrote in message news:<20011117173302.19275.00000625@mb-ch.aol.com>...O > While there has been much speculation on how VMS customers would react to thetQ > Alpha EOL and the planned merger with HP, what are large VMS customers actuallyhQ > doing now?   If you work for a large VMS customer, could you post a description N > on how your firm is reacting?  Staying the course, waiting for IPF, planningN > migrations off VMS, contacting other vendors or just ignoring the situation?  L you don't migrate from vms until you have to ... vms presently has many manyK years of life (7-10 years at least) ... the DOE contract and the government J ensures vms will be around a will as I don't think the military wants blueN screens abound it the battlefield and the Pentagon and a lot of other criticalN places (the Navy learned about windoze the hard way on one of their carriers)!I we will stay on vms as long as we can then see what is out their then ...aL if nothing changes, then linux with vms tools would seem the way to go next,I but if intel swallows their pride and puts alpha designs and compilers inp5 the itanium, and the vms port happens, then look out!m   ------------------------------  % Date: Tue, 20 Nov 2001 09:27:26 -0500r- From: JF Mezei <jfmezei.spamnot@videotron.ca>- Subject: Re: Life After Alphaa, Message-ID: <3BFA684D.673BDB3C@videotron.ca>   Nic Clews wrote:D > Interestingly I can report from the IBM camp than EVEN THEY do notF > believe their Power4 will dominate. They reckon that Intel will quitE > fabbing the IA32's and such apps will reply on the emulation of theCF > IA64s. They see only a niche market for their microprocessors and an > explosion in the use of IA64.m  K But if that niche market represents profitable enterprise systems while the M intel crap is relegated to unprofitable low margin PCs, then what do you knowr you want to be ?  H Everyone in the IT industry should know by now that volume does not mean profit.n   ------------------------------  # Date: Tue, 20 Nov 2001 14:41:22 GMTg* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Life After Alpha.@ Message-ID: <mYtK7.34292$uB.5584450@bin3.nnrp.aus1.giganews.com>  0 Milton <mbhewitt@optonline.net> wrote in message2 news:lvokvtg251t0qa9hl8eebvhbojthp7e1tn@4ax.com...E > On Tue, 20 Nov 2001 11:47:49 +0000, Alan Greig <a.greig@virgin.net>  > wrote:   ...-  I > >But according to Compaq's analysis Power4  is a dead end architecture.r >n > Say what?R  G My guess is that Alan was reporting this Compaq analysis as yet another-J example of the quality of Compaq's brain-trust rather than suggesting that he agreed with it.   >e > SPECint2000 SPECfp2000 > Base Peak Base Peakg >a >n" > 1.3 GHz Power4 790 814 1098 1169$ > 1.0 GHz 21264C 621 679   776   960% > 800 MHz Itanium 358 365   715   715O' > http://www.aceshardware.com/#55000402   K I've been told that the 358 base number (and I think the 365 peak number asjF well) for Itanic (IIRC on an HP box) is a bit bogus, insofar as it wasK obtained using an ILP32 compiler (i.e., hardly what one would choose to userL to support most 64-bit applications).  The 314 number obtained on a Dell box may be more realistic.  G And an important point to remember about the Power4 number is that it'sdB using only one of the two processor cores on the die:  the *total*K performance of the die (which is still smaller and consumes less power thaneJ the Itanic die, though a lot larger and hungrier than an EV68 die) is even more impressive.   - bill   ------------------------------  # Date: Tue, 20 Nov 2001 14:44:33 GMTl4 From: "Terry C. Shannon" <terryshannon@mediaone.net> Subject: Re: Life After Alphap< Message-ID: <l%tK7.6844$eh7.3892085@typhoon.ne.mediaone.net>  4 "Carsten Gester" <pentyern@gmx.net> wrote in message' news:9td9jv$c7v$1@tyfon.itea.ntnu.no...m >e >a > Jerry Leslie wrote:i >i( > > John Plemons (john@mavin.com) wrote:G > > : Folks I think the tolling of the death bell for Alpha is a little J > > : early... If you check the Samsung website you will see its alive andL > > : well, Samsung is making a series of boards and has a worldwide network! > > : of VAR's to market them....tJ > > : Check out http://www.samsungelectronics.com do a search on the 21264J > > : there is a whole section on the Alpha, with links to their worldwide& > > : distributors for the product.... > > :07 > > Interesting. The following URLs would support that:c > >:J > >   http://samsungelectronics.com/semiconductors/Alpha_CPU/Alpha_CPU.htm > >.% > >   http://www.alpha-processor.com/o > >b+ > >   http://www.api-networks.com/products/1 > >0H > > but someone from API posted recently that they were out of the ALPHA
 > > business.2 >0I > Yes, I've asked about Samsungs involvement in the future of Alpha and I  got L > the answer from Terry C. Shannon that they focused more on the netwprk and0 > transport stuff than on the Alpha chip itself. >   L That's the word from API NetWorks and apparently from Samsung itself. One of@ Samsung's strongest supporters, Nebosja Novakovic, proprietor ofD www.novaglobal.com.sg, recently got out of the Alpha business and isL flogging the NEW  fastest processor on the planet, IBM's Power4. Nova was anG Alpha advocate right from the get-go, but apparently dealing with Alphal> marketeers, Samsung, and Compaq itself finally got to the guy.  K Samsung was approached back in July about continuing Alpha development, bute= apparently opted not to do so. It's an expensive undertaking.u   >tE > > Hewlett Packard has licensed its OpenMail product to Samsung SDS:  > > > > >    http://www.openmail.com/cyc/om/00/showfile.cgi?100-1757H > >    HP and Samsung SDS Sign Licensing Agreement for OpenMail Software > >o> > >    http://www.openmail.com/cyc/om/00/showfile.cgi?100-1758 > >    OpenMail Q and Ae > >nE > > OpenMail on a supported unix variant is a drop-in replacement fore > > Microsoft Exchange.r > >v > >s8 > > --Jerry Leslie     (my opinions are strictly my own) >i< > I think the problem is that everybody cries Alpha is dead.  J On Usenet, this is pretty much the case. But how many customers base their& buying decisions on Usenet commentary?  
 If I would ber  L > someone who has to buy a new high performance system and I only hear aboutA > Alpha that this system is dead, I wouldn't buy an Alpha system.   J Agreed. This a job for Compaq marketing. If they aren't doing the job, ask	 them why.a   ------------------------------  % Date: Tue, 20 Nov 2001 09:55:58 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>h Subject: Re: Life After Alpha , Message-ID: <3BFA6EFB.55E158E3@videotron.ca>   Bob Ceculski wrote:rN > you don't migrate from vms until you have to ... vms presently has many many% > years of life (7-10 years at least)a  I That is what HP 3000 MPE users had also been told in August.  Once VMS is.L ported to IA64 and runs on the same servers as NT, then HP can pull the plugN on VMS development, make the OS mature and simply provide hardware upgrades to< the remaining customers for the duration of their contracts.  ) > ... the DOE contract and the governmento > ensures vms will be around t  N No, it ensures that Compaq/HP will provide a support infrastructure capable ofN supporting at least those customers who signed a DOE contract. It doesn't meanK that VMS will continue to be commercially available or that VMS will remainn4 supported for those customers without DOE contracts.    B It is a fair bet that VMS will be around for a few years.  But the3 announcement of its execution may come before that.k   ------------------------------  # Date: Tue, 20 Nov 2001 15:02:53 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net> Subject: Re: Life After Alphae< Message-ID: <xguK7.6855$eh7.3905198@typhoon.ne.mediaone.net>  5 "Bob Ceculski" <bob@instantwhip.com> wrote in messaget7 news:d7791aa1.0111200623.621eda92@posting.google.com...s4 > dashw459@aol.comeatspam (Doug W.) wrote in message5 news:<20011117173302.19275.00000625@mb-ch.aol.com>.../J > > While there has been much speculation on how VMS customers would react to theJ > > Alpha EOL and the planned merger with HP, what are large VMS customers actuallyG > > doing now?   If you work for a large VMS customer, could you post a- descriptionnG > > on how your firm is reacting?  Staying the course, waiting for IPF,/ planningE > > migrations off VMS, contacting other vendors or just ignoring thel
 situation? > I > you don't migrate from vms until you have to ... vms presently has manyr manyB > years of life (7-10 years at least) ... the DOE contract and the
 governmentL > ensures vms will be around a will as I don't think the military wants blueG > screens abound it the battlefield and the Pentagon and a lot of otherd criticalE > places (the Navy learned about windoze the hard way on one of theirw
 carriers)!  J The squids (sorry, I'm ex- US Army, gotta get the interservice rivalry jabK in there) apparently did NOT learn their lesson. Sad but true, a CVN slated K for deployment in ~2008 will have a Windoze-based battle management system.MK The ChiComs must be ecstatic over this decision. And with good reason: theyaI won't need a nuke to take out this bird farm... a simple virus will leavetG the aircraft carrier dead in the water. And after they win the war, the-; ChiComs will be able to convert the captured carrier into a % revenue-generating real estate asset.:   ------------------------------  # Date: Tue, 20 Nov 2001 15:25:21 GMTr  From: cjt <cheljuba@prodigy.net> Subject: Re: Life After Alphao+ Message-ID: <3BFA75DA.59557AE2@prodigy.net>    Alan Greig wrote:  > 6 > On Mon, 19 Nov 2001 03:48:25 GMT, "Terry C. Shannon"$ > <terryshannon@mediaone.net> wrote: >  > ...o > >> > >dM > >Given that Power4 is a pretty decent piece of work, do you think IBM would/ > H > But according to Compaq's analysis Power4  is a dead end architecture.G > Can't remember the name of the (senior) Compaq Alpha guy who gave theeE > presentation in London on Friday. Should have been Dave Fenwick buttG > there was a last minute change. Anyone want to jump in with the name?C > D > Compaq's analysis said that IA64 would blow away everyone else andG > IBM, AMD, Sun will all eventually have to jump on the IA64 bandwagon.hH > The reason being that none of them could afford to keep up with Intel.  L That sure sounds like a bogus argument to me.  Why would it suddenly be trueH now, but not 10 years ago?  Why doesn't everybody have a "True Blue" IBM/ PC on their desk?  How can VMS hope to survive?e  H > Following this logic Alpha had to go because Compaq couldn't afford to > keep up either.. > F > Asked what Plan B was if IA64 failed the answer was there is no plan > B. > L > >consider it worthwhile to add Alpha to their portfolio? Assuming that theK > >VMS to IPF port works (I think it will), VMS no longer is tied to Alpha.n > > J > >And it wouldn't be all that difficult to a Power4 port of the IPF-ified	 > >VMS...) > >  >  > -- > Alan   ------------------------------  # Date: Tue, 20 Nov 2001 15:34:32 GMTo  From: cjt <cheljuba@prodigy.net> Subject: Re: Life After Alpha + Message-ID: <3BFA7805.E210ADCD@prodigy.net>l   Bill Todd wrote: > 2 > Milton <mbhewitt@optonline.net> wrote in message4 > news:lvokvtg251t0qa9hl8eebvhbojthp7e1tn@4ax.com...G > > On Tue, 20 Nov 2001 11:47:49 +0000, Alan Greig <a.greig@virgin.net>-
 > > wrote: >  > ...- > K > > >But according to Compaq's analysis Power4  is a dead end architecture.t > >u
 > > Say what?  > I > My guess is that Alan was reporting this Compaq analysis as yet anothernL > example of the quality of Compaq's brain-trust rather than suggesting that > he agreed with it. >  > >a > > SPECint2000 SPECfp2000 > > Base Peak Base Peakn > >  > >o$ > > 1.3 GHz Power4 790 814 1098 1169& > > 1.0 GHz 21264C 621 679   776   960' > > 800 MHz Itanium 358 365   715   715p) > > http://www.aceshardware.com/#55000402  > M > I've been told that the 358 base number (and I think the 365 peak number aseH > well) for Itanic (IIRC on an HP box) is a bit bogus, insofar as it wasM > obtained using an ILP32 compiler (i.e., hardly what one would choose to use N > to support most 64-bit applications).  The 314 number obtained on a Dell box > may be more realistic. > I > And an important point to remember about the Power4 number is that it'shD > using only one of the two processor cores on the die:  the *total*M > performance of the die (which is still smaller and consumes less power than L > the Itanic die, though a lot larger and hungrier than an EV68 die) is even > more impressive. >  > - bill  M I thought I read that the Power4 number is a bit bogus, too, since it was run-E giving the benefit of an entire system's cache to a single processor.    ------------------------------  # Date: Tue, 20 Nov 2001 15:50:04 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net> Subject: Re: Life After AlphaC< Message-ID: <MYuK7.6888$eh7.3937552@typhoon.ne.mediaone.net>  2 "Milton" <mbhewitt@optonline.net> wrote in message2 news:lvokvtg251t0qa9hl8eebvhbojthp7e1tn@4ax.com...E > On Tue, 20 Nov 2001 11:47:49 +0000, Alan Greig <a.greig@virgin.net>e > wrote: > 7 > >On Mon, 19 Nov 2001 03:48:25 GMT, "Terry C. Shannon"n% > ><terryshannon@mediaone.net> wrote:o > >i > >... > >>>. > >>H > >>Given that Power4 is a pretty decent piece of work, do you think IBM woulde > > I > >But according to Compaq's analysis Power4  is a dead end architecture.  >  > Say what?t  0 Like I said, "according to Compaq's analysis..."  3 Far be it from me to claim that Power4 is dead-end.   L IBM should never be underestimated. Remember the US trade rag Datamation? ItI was sometime in the first half of the nineties that Datamation proclaimedo the death of the mainframe.n  K IBM is still selling mainframes and making big bags of money on same. Where  is Datamation these days?i   >r > SPECint2000 SPECfp2000 > Base Peak Base Peak  >  >s" > 1.3 GHz Power4 790 814 1098 1169$ > 1.0 GHz 21264C 621 679   776   960% > 800 MHz Itanium 358 365   715   715b' > http://www.aceshardware.com/#55000402e >o@ > Some pretty impressive numbers for a relatively new architect,) > *especially* when compared to the IA64.h   Yup.   >'H > >Can't remember the name of the (senior) Compaq Alpha guy who gave theF > >presentation in London on Friday. Should have been Dave Fenwick butH > >there was a last minute change. Anyone want to jump in with the name? > >pE > >Compaq's analysis said that IA64 would blow away everyone else and-H > >IBM, AMD, Sun will all eventually have to jump on the IA64 bandwagon.I > >The reason being that none of them could afford to keep up with Intel.-I > >Following this logic Alpha had to go because Compaq couldn't afford to4 > >keep up either.  K Be careful with this logic. Merely repeating the mantra will subject you to." NonStop flaming in this forum. ;-}   > >oG > >Asked what Plan B was if IA64 failed the answer was there is no plan  > >B.o >u- > Plan B should be -> buy a lot of IBM stock.s >a   Sounds like a Good Plan to me!  L Actually, Compaq *did* have a plan. The Fire/Ice/Wind fabric-and-blade basedB server due out in 2004-5 or thereabouts originally was designed toK accommodate IPF, Alpha, IA32, and Hammer chips. Plug in whatever it is that/. blows up your skirt or otherwise turns you on.  H Suffice it to say that the June 25 announcement took a few Blades out of: Compaq's post-Marvel enterprise server "Swiss Army Knife."  K Compaq *does* have an alternate plan, sort of. EV78 is in production today, G early EV78 silicon powers the 32-way Marvel boxes CPQ is fooling aroundIL with. EV79 is just a process shrink. The E7 generation could be re-spun into3 EV710 and perhaps EV711 if the need arose to do so.    ------------------------------  # Date: Tue, 20 Nov 2001 15:57:40 GMTi4 From: "Terry C. Shannon" <terryshannon@mediaone.net> Subject: Re: Life After Alpha < Message-ID: <U3vK7.6894$eh7.3942482@typhoon.ne.mediaone.net>  - "cjt" <cheljuba@prodigy.net> wrote in messageo% news:3BFA75DA.59557AE2@prodigy.net...h > Alan Greig wrote:- > >-8 > > On Mon, 19 Nov 2001 03:48:25 GMT, "Terry C. Shannon"& > > <terryshannon@mediaone.net> wrote: > >j > > ...L > > >> > > > I > > >Given that Power4 is a pretty decent piece of work, do you think IBM9 wouldm > >aJ > > But according to Compaq's analysis Power4  is a dead end architecture.I > > Can't remember the name of the (senior) Compaq Alpha guy who gave therG > > presentation in London on Friday. Should have been Dave Fenwick butVI > > there was a last minute change. Anyone want to jump in with the name?, > >dF > > Compaq's analysis said that IA64 would blow away everyone else andI > > IBM, AMD, Sun will all eventually have to jump on the IA64 bandwagon.nJ > > The reason being that none of them could afford to keep up with Intel. >vI > That sure sounds like a bogus argument to me.  Why would it suddenly be. trueJ > now, but not 10 years ago?  Why doesn't everybody have a "True Blue" IBM1 > PC on their desk?  How can VMS hope to survive?  >   L It may be a bogus argument, but the questions you pose don't really shed anyI light on the relative "bogusity" of the claim. I presume there's a lot ofmF stuff that's true today that wasn't true ten years ago. As for the IBMK peecee, which came out twenty years ago IIRC, that franchise got whacked bysH an Attaq of the Killer Clones. One of which is (for the moment) based inF Houston and sports a name which represents a contraction of COMPAtible Quality.  L And as for VMS, it'll survive on its merits, not the merits of the processorI it runs upon. VMS actually is pretty oblivious to the Alpha architecture,rJ that's why PALcode was created. All the PALcode goodies get moved into theE OS itself with the IPF port, hence VMS should be more portable in the  future.l  F That said, marketing, or lack thereof, will play a pivotal role in the& continued success--or failure--of VMS.   ------------------------------  # Date: Tue, 20 Nov 2001 16:34:16 GMTm* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: Life After Alpha @ Message-ID: <cCvK7.55444$2w.2870130@bin4.nnrp.aus1.giganews.com>  + cjt <cheljuba@prodigy.net> wrote in messagee% news:3BFA7805.E210ADCD@prodigy.net...t > Bill Todd wrote: > > 4 > > Milton <mbhewitt@optonline.net> wrote in message6 > > news:lvokvtg251t0qa9hl8eebvhbojthp7e1tn@4ax.com...I > > > On Tue, 20 Nov 2001 11:47:49 +0000, Alan Greig <a.greig@virgin.net>u > > > wrote: > >. > > ...n > >o? > > > >But according to Compaq's analysis Power4  is a dead endv
 architecture.b > > >p > > > Say what?  > >TK > > My guess is that Alan was reporting this Compaq analysis as yet another I > > example of the quality of Compaq's brain-trust rather than suggestingc that > > he agreed with it. > >s > > >t > > > SPECint2000 SPECfp2000 > > > Base Peak Base Peak  > > >  > > >q& > > > 1.3 GHz Power4 790 814 1098 1169( > > > 1.0 GHz 21264C 621 679   776   960) > > > 800 MHz Itanium 358 365   715   715a+ > > > http://www.aceshardware.com/#550004029 > >9L > > I've been told that the 358 base number (and I think the 365 peak number asJ > > well) for Itanic (IIRC on an HP box) is a bit bogus, insofar as it wasK > > obtained using an ILP32 compiler (i.e., hardly what one would choose too use L > > to support most 64-bit applications).  The 314 number obtained on a Dell box  > > may be more realistic. > >oK > > And an important point to remember about the Power4 number is that it'smF > > using only one of the two processor cores on the die:  the *total*J > > performance of the die (which is still smaller and consumes less power thanI > > the Itanic die, though a lot larger and hungrier than an EV68 die) isr even > > more impressive. > >l
 > > - bill >uK > I thought I read that the Power4 number is a bit bogus, too, since it was- run-G > giving the benefit of an entire system's cache to a single processor.o  J Hmmm.  It was certainly run giving the entire on-chip L2 cache to only oneI of the two processor cores on the die (which is why I didn't suggest thatnL the whole-die performance would be as much as double that of just one core).L But if (and I don't know) it was run on a 4-die system with only one processL or active but using the aggregate 4-die L2 cache, *that* would indeed seem a
 bit bogus.   - bill   ------------------------------    Date: 20 Nov 2001 08:39:26 -0800- From: tessier-ashpool@usa.net (Chris Bardell)k Subject: Re: Life After Alpha.= Message-ID: <9f261edc.0111200839.23da350f@posting.google.com>a  ' http://www.theinquirer.net/17110103.htmc   ------------------------------  % Date: Tue, 20 Nov 2001 16:20:51 +0000e% From: Alan Greig <a.greig@virgin.net>T Subject: Re: Life After Alpha 8 Message-ID: <u40lvto0pgaou2ebn6oddmc8lcq17toa9p@4ax.com>  C On Tue, 20 Nov 2001 15:25:21 GMT, cjt <cheljuba@prodigy.net> wrote:c    E >> Compaq's analysis said that IA64 would blow away everyone else andeH >> IBM, AMD, Sun will all eventually have to jump on the IA64 bandwagon.I >> The reason being that none of them could afford to keep up with Intel.  > M >That sure sounds like a bogus argument to me.  Why would it suddenly be truepI >now, but not 10 years ago?  Why doesn't everybody have a "True Blue" IBMw0 >PC on their desk?  How can VMS hope to survive?  A I put this question directly and the answer was "the industry nowoB wants fewer operating systems and fewer processors - you don't getF anywhere by being different". I pointed out that DEC became the secondF largest computer company in the world by being different. No reply wasB offered. I also asked why the statement about fewer processors andD fewer OSs did not logically imply a Compaq/HP eventual target of one= OS (Windows) on one bit of hardware (Intel) and did not get a  satisfactory reply.i  A In fairness I am not sure the speaker really believed some of theS@ Compaq party line but that was what he had to run with. He quiteE clearly wished I would shutup at times. Like it or not decisions haverC been taken and, like the Compaq engineers, he said we would have too
 "get over it"7 -- Alan   ------------------------------  # Date: Tue, 20 Nov 2001 16:49:35 GMTr4 From: "Terry C. Shannon" <terryshannon@mediaone.net> Subject: Re: Life After Alpha(< Message-ID: <zQvK7.6916$eh7.3975920@typhoon.ne.mediaone.net>  : "Chris Bardell" <tessier-ashpool@usa.net> wrote in message7 news:9f261edc.0111200839.23da350f@posting.google.com...i) > http://www.theinquirer.net/17110103.htmw  E Apropos to the above, t'is the BLISS cross-compiler that is done dealoJ already. Word has it that only about 25 or so VMS engineers are working onI the port itself; the job is much more complex but involves much less code  than did the VAX to Alpha port.-   ------------------------------    Date: 20 Nov 2001 10:10:08 -0800, From: mcbill20@hotmail.com (Bill McLaughlin) Subject: Re: Life After Alphas= Message-ID: <e9cbc4f2.0111201010.60b044a6@posting.google.com>r  h dashw459@aol.comeatspam (Doug W.) wrote in message news:<20011117173302.19275.00000625@mb-ch.aol.com>...O > While there has been much speculation on how VMS customers would react to theeQ > Alpha EOL and the planned merger with HP, what are large VMS customers actuallylQ > doing now?   If you work for a large VMS customer, could you post a description N > on how your firm is reacting?  Staying the course, waiting for IPF, planningN > migrations off VMS, contacting other vendors or just ignoring the situation?  F Since I left Digital in late 1994 I have held four positions and I was- lucky enough to work with VMS in all of them.c  C - The first was a small (~ 100 employees) division of a large cable B company. The parent company pulled the funding and the company wasD closed. In this case of course, VMS went away along with the rest of the company.  F - The next was a contract position at a fairly good sized utility thatA claimed to be "officially an NT/VB shop". Of course, all the mainCD applications were still running on VMS. There were constant problemsF trying to replace the VMS solutions with NT and VB. This was obviouslyB before alpha was killed but management perception was that VMS was dying.  E - The next was a Y2K contract with mission critical realtime systems. E The homegrown software was avaialable on VMS, HP-UX and a combination C of NT and 95. Needless to say, the VMS work was a breeze. The HP-UXt@ wasn't *too* bad but the Windows work was blue screen after blueB screen. Before the end of the year, the company was bidding on newF contracts and had decided that they would normally quote a windows andA a unix solution, and only quote a VMS solution if the prospectivei# customer specifically asked for it.n  F - Now, more relevant to the original message, I have been working at aD very large company (~16 billion revenue) for the past two years. TheE software is homegrown FORTRAN and C on alphaservers. The decision has B been made to do a line by line rewrite to C on some unix. EveryoneB here loves VMS but the decision came  from top management. While IF *love* VMS and will always have it at home, I can partially understandF some of the reasons we have been given for migrating. Most are related to perception:F  1) VMS was already perceived as dwindling or dying but when the alpha3 was killed it pretty much cemented that perception.hA  2) Oracle has consistently delivered their products for VMS much ? later (in spite of "tier one" claims) and does not support manye products on VMS.E  3) Oracle decided to stop supporting character cell so a change fromdD terminals to PC's (and the underlying software) is necessary anyway.B  4) Several Oracle DBA's were interviewed and were very interestedE until they found that the platform was VMS, which they perceived as a0 career dead-end.<  5) Some help wanted ads for developers on VMS had few or noF responses. A few candidates had said the same thing-- they thought VMS was a dead-end.NC  6) We have lost quite a few developers over the past year; some totE other teams and some to other companies. Many were afraid that if thenE economy went downhill and they were faced with layoffs, they would be'D unable to find another VMS position and perceived as having outdated skills.e  @ After the first of the year I will no longer be working with VMS? (other than at home). Upper management decided that I will be amB java/unix developer after that. As I said, I *love* VMS but on theE other hand, I am thankful that I am not being let go and that I don't  have to do VB/VC++.l  B It's been months since I've seen any VMS positions on monster.com.   Bill McLaughlin    ------------------------------  % Date: Tue, 20 Nov 2001 10:26:39 +0100y> From: Michael Gruth <Michael.Gruth@sysdev.deutsche-boerse.com>. Subject: Re: No advertisment for VMS stability: Message-ID: <3BFA21CF.3D6B18B3@sysdev.deutsche-boerse.com>   Thanks my Martin,b  A that you post a message to comments the articls in the newsgroup.t  L We do the very best to avoid these Situation, we still think that VMS is on= e of the best operatingp3 systems, but nobody is aware about the next bug ...P  
 Michael Gruthh" Head of System- and Networksupport Deutsche B=F6rse Systems AGo Frankfurt/Germanyd    ! "Dr. Martin P.J. Zinser" schrieb:i  L > > From: IN%"young_r@encompasserve.org"  "Rob Young" 19-NOV-2001 20:42:51.= 39/ > > Subj: RE: No advertisment for VMS stability@ >dL > > In article <IfeJzWHDJIcX@eisner.encompasserve.org>, young_r@encompasser= ve.org (Rob Young) writes:L > > > In article <3bf92be8$1_1@news.datacomm.ch>, "Jakob Erber" <erber@tisc= alinet.ch> writes:
 > > >> Hi, > > >>J > > >> the german Xetra trading system seems not to be too happy with VMS. > > >> > > >> > > >>3 > > >> http://de.news.yahoo.com/011119/3/2c64e.html  > > >> > > >e. > > >       But in conclusion via translation: > > >aL > > > For the current disturbance the German stock exchange made an error i= n thesL > > > network program of the operating system, which controls responsible t= heL > > > connection of the central computers with the commercial systems. Upda= ting of9L > > > the Xetra software ("release change") on Monday was not against it a = cause of > > > the disturbance. > > >oE > > >       So... system management error.  Seems they either need tokJ > > >       put a stiffer change control method and/or find new folks that6 > > >       understand how to manage VMS.  No offense. > > >. >a > Hello, >  > > J > >         I've received private communication with someone familiar withL > >         the situation.  What is wrong is something that is pretty trivi= alJ > >         and works in other production situations.  Since I did not askL > >         permission to post the content, I won't.  Since this is an open=  1 > >         issue, that is all I am going to say.d > >hL > >         They do know what they are doing and they do have change contro= l  > >         procedures.e > >a > >         My apologies.t > >s' > >                                 Robf >oH >         Well, I was the person contacting Rob. We do work hard here atE >         the exchange to avoid such problems. I can assure everybodynC >         that this was not a case of a simple miss handling of thesB >         system. Neither is it an error which is excercised underD >         trivial circumstances in OpenVMS, since we do this type ofB >         work regularly and never encountered any problems. ShortC >         summary: The problem is currently under investigation, we:A >         did change our internal working procedures to ensure iteE >         will not happen again until the result of the investigationt >         is available.i >I@ >         I do want to thank Rob for his posting, since it shows@ >         he is able to take new information into account and toF >         adjust his views accordingly also in public. I think in thisB >         he can be an example for all of us (I'm including myself >         here). >n3 >                                 Greetings, MartintL > Dr. Martin P.J. Zinser                       zinser@sysdev.deutsche-boers= e.comf > Deutsche Boerse Systems Inc.C > Suite 1580                                   Tel: +1-312-408-3085PC > 141 West Jackson Blvd.                       FAX: +1-312-408-30719 > Chicago, IL, 60604H > USA                                          Private:  zinser@decus.de   ------------------------------  # Date: Tue, 20 Nov 2001 13:54:06 GMTa8 From: hammond@not@peek.ppb.cpqcorp.net (Charlie Hammond): Subject: Re: OpenVMS o/s cd-rom insufficient quotas/limits3 Message-ID: <2gtK7.1758$RL6.58335@news.cpqcorp.net>t  , In article <9tc0g7$sq6$1@lead.zk3.dec.com>, 6 "Mark Buda" <buda@tabasco.zko.dec.no.spam.com> writes: .tF >A fellow engineer pointed out that the stand alone situation does notF >use the startup process, but a process that it creates with specified
 >quotas...  3 As the "fellow engineer", this is what I told Mark:t  = Quotas for the startup process might not be the problem here.   E When you boot the kit CD, the initial startup process runs a detached & process and exits.  The run commad is:  C $   define/system/exec/nolog sys$sylogin sys$system:sa1_startup.com} $!A $   term = f$trnlnm("SYS$OUTPUT")   ! Device for input and outputi< $   define/user sys$output nl:      ! Don't display feedback> $   define/user sys$error nl:       ! Don't display any errors $! $*H   run/noauth/detach/input='term'/output='term'/process_name=sa_startup -G         /file_limit=100/io_buffered=500/io_direct=4096/ast_limit=4096 - I         /buffer_limit=65536/working_set=10000/maximum_working_set=24000 -r,         /page_file=65536 sys$system:loginout  ? This is done specifically to set various quotas.  The procedures( SA1_STARTUP.COM is what runs the "menu".  ; Then, if the DCL option is selected, it is run via a SPAWN:i  B $   spawn/nolog/input=sys$output/output=sys$output/prompt="$$$ " -1         /process=sa_startup_dcl set control=(Y,T)e  D In any case, keep in mind that this is a WRITE LOCKED system with noB page or swap files.  It won't do everything that you can do from a "normal" system disk.1,                                              ====  G Remember: The environment when booted from the OpenVMS Alpha operating hE system CD-ROM is not the same as you get when booting a normal systeme? disk.  SOme commands and utilities will not work as documented.g  D I missed the earlier part of this discussion.  Did you say what size5 the disk was?  And how much physical memory you have?L   -- >K     Charlie Hammond -- Compaq Computer Corporation -- Pompano Beach  FL USAnH        (hammond@not@peek.ppb.cpqcorp.net -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------  % Date: Tue, 20 Nov 2001 10:26:32 -0500e2 From: "Sue Skonetski" <susan.skonetski@compaq.com>' Subject: OpenVMS Times  Special editione3 Message-ID: <zBuK7.1766$RL6.58383@news.cpqcorp.net>b   Dear Newsgroup,l  K If you have not subscribed to OpenVMS Times, now would be a good time to don> it since we will be having a special edition in about a month.  9 http://www.openvms.compaq.com/openvmstimes/subscribe.htmlt  
 Warm regards,i   suen   ------------------------------  + Date: Tue, 20 Nov 2001 13:11:47 +0100 (MET)u From: Robin.Goerlach@gmx.deH- Subject: Pathworks and SMBClient (Linux/Irix) , Message-ID: <30921.1006258307@www36.gmx.net>   Hi all,h  K I created a connection with smbclient from Linux or Irix to an VMS Station.oH I've fullcontrol rights on directories and files but can't change into a subdir: but I can change into a subdir on a nt server. (see below)  
 Any idea ?  5 obelix > smbclient \\\\VMSSrv.sasd.de\\robin -U robineF added interface ip=192.168.0.7 bcast=192.168.0.255 nmask=255.255.255.01 session request to VMSSRV.SASD.DE failed (code 0)v
 Password: E Domain=[SASD] OS=[OpenVMS VMS  V7.1] Server=[Advanced Server 3.51 forr OpenVMS Systems] smb: \> cd vms6 cd \vms\: ERRSRV - ERRerror (Non-specific error code.) smb: \> dir vms\* K    .                                   D     1024  Tue Nov 20 11:03:40 2001hJ   ..                                  D     3584  Thu Jun  7 09:52:38 2001J   AUTOGENHELP.TXT                          14813  Mon Dec 20 12:14:42 1999J   CLS.TXT                                     14  Tue Oct 24 14:33:36 2000J   CLUSTERCONFIG                       D     3584  Wed Dec 15 15:56:34 1999J   JAVA.BCK                               8612352  Tue Nov 20 11:03:16 2001J   JAVA                               DR    12288  Tue Jul  3 10:56:56 2001  =                 4651 blocks of size 22016. 0 blocks availablel  7 obelix > smbclient \\\\NTServer.sasd.de\\robin -U robin F added interface ip=192.168.0.7 bcast=192.168.0.255 nmask=255.255.255.0A session request to NTSERVER.SASD failed (Called name not present) 
 Password: = Domain=[SASD] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0]  smb: \> cd robin   smb: \robin\> cd div smb: \robin\div\> K smb: \e00356\> dir  .                                  DA        0  Mon Octg 22 09:16:03 2001J   ..                                 DA        0  Mon Oct 22 09:16:03 2001J   comreads.dbg                        A       57  Mon Sep  3 15:28:42 2001J   comused.dbg                         A       57  Mon Sep  3 15:28:42 2001J   Eigene Bilder                      DA        0  Tue Oct 30 15:04:36 2001J   Eigene Dateien                     DA        0  Mon Aug 20 14:19:29 2001J   EMD_TVMP.EXE                        A   508928  Mon Apr 26 13:47:40 1999J   GUTER Schrott                      DA        0  Tue Oct  9 08:48:19 2001J   Nichts.bmp                          A  1256958  Tue Jul 17 15:43:35 2001J   OraPwCng.INI                        A      688  Fri Apr 27 12:03:44 2001J   RECYCLER                         DAHS        0  Fri Jun  8 10:50:54 2001J   sendMail.bas.txt                    A     1569  Wed Sep 12 15:09:53 2001L   VMS-LOGO.BMP                        A     8658  Fri Sep 12 12:55:41 1997       C                 43382 blocks of size 2097152. 7075 blocks available L smb: \div\>                                                                        -- a                           _\\|//_                           ( . . )& -----------------------ooO-(_)-Ooo---- Robin.Goerlach@gmx.de   . GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net   ------------------------------    Date: 20 Nov 2001 08:51:25 -0800" From: lxschi@ispat.com (LSchiller) Subject: RWAST/LAT port problem = Message-ID: <8af707a9.0111200851.354678ce@posting.google.com>u   Hello!  @ I am hoping someone can help me with a problem that begain on myA system a few days ago.  I have a program that reads messages on a3E queue and uses sys$brkthru to send these messages to terminals.  This:F program was set up as a detached process a few years ago, and has beenF working great until last week.  Now it will go into an RWAST state and" does not clear up unless I reboot.   Additional background:D I have a different program that also runs as a detached process.  ItB is the operator menu program that is assigned to run on a specificC terminal (using a LAT port).  I actually have 3 of these processes,CB executing the identical program, on 3 different LAT ports, but I'm< only having problems with 1.  When the system starts up, theA message-sending process is started first.  Then the operator menueA process are started up.  Last week, I recompiled and relinked themE operator menu programs, and when I restarted them, the third operatoreF menu process went into a COM state when it was started up, practicallyB continuously (with an occasional RWMPB state popping up).  Further@ investigation seemed to point to the message-sending program notF releasing the LAT port.  However, when I showed that device, the ownerE process was non-existant, and therefore I could not kill it.  I'm notfC sure if I reached the correct conclusions.  I switched the order ofeB start-up so the operator menus were first, and at first everythingB looked okay, but after a little while, the message-sending programE would go into an RWAST state.  I rebooted, and darn if the same thing  didn't happen again.  F Now, the 2 programs do share a common user-library that was modified. 8 Only the operator-menu program was relinked though.  The5 message-sending program hasn't been touched in years.n  E Any ideas?  If you need more iformation, please let me know.  Thanks.-   LSchiller (lxschi@ispat.comu   ------------------------------    Date: 20 Nov 2001 06:43:40 -0800, From: dframeli@aus.telusa.com (Dale Frameli)! Subject: Scripting / batch files?@= Message-ID: <de844d64.0111200643.221d477b@posting.google.com>a  F I would like to create a script (a batch file) to automate processes. A Can someone direct me to information on writing scripts / commande procedures?t  ; I'm most interested in the ability to "prompt" the user fortB information, then in using their responses as variables within the script.j  1 Please reply directly to: dframeli@aus.telusa.com    Thanks,e Dale   ------------------------------  % Date: Tue, 20 Nov 2001 13:18:47 -0500:0 From: "Syltrem" <syltrem@videotron.spammenot.ca>% Subject: Re: Scripting / batch files?e4 Message-ID: <p3xK7.5454$qb4.36081@tor-nn1.netcom.ca>  = Scripting language on VMS is very powerful and is called DCL.:   Lookup the DCL dictionary.  + You can find DCL examples on my web site at H http://pages.infinit.net/syltrem/dcl_exemple.htm but the comments are inG french. If you have the DCL dictionary then you don't need the commentsoJ anyway. Functions that start with F$ are called lexicals, and you can find+ them in the documentation under "lexicals".u   The DCL dictionary is atL http://www.openvms.compaq.com:8000/72final/9996/9996pro.html#first_page%20<h< ttp://www.openvms.compaq.com:8000/72final/9996/9996pro.html>   Have fun. DCL is fun.n     SyltremwI http://pages.infinit.net/syltrem (OpenVMS related web site - en franais)i> To reply to myself directly, remove .spammenot from my address      F "Dale Frameli" <dframeli@aus.telusa.com> a crit dans le message news:2 de844d64.0111200643.221d477b@posting.google.com...G > I would like to create a script (a batch file) to automate processes.cC > Can someone direct me to information on writing scripts / commandl
 > procedures?S >h= > I'm most interested in the ability to "prompt" the user for D > information, then in using their responses as variables within the	 > script.t > 3 > Please reply directly to: dframeli@aus.telusa.comr > 	 > Thanks,n > Dale   ------------------------------  # Date: Tue, 20 Nov 2001 14:32:10 GMT ' From: Rick Dyson <Rick-Dyson@UIowa.EDU>s3 Subject: Server vs. Workstation:  You Make The Callt) Message-ID: <3BFA696A.83C13347@UIowa.EDU>r  D     For the purposes of licensing the Compaq CSLG/ESL, they define a0 "system" as a server *OR* five (5) workstations.  A     Can anyone help me "officially" clarify whether the followingM? Digital/Compaq hardware are either a 'server' or 'workstation'?t       DEC 3000/400     Alpha 3000/500
     XP1000     ES45     ES40 68/833e  
     uVAX 3300(   Thanks in Advance!   Regards, Rick   ------------------------------  % Date: Tue, 20 Nov 2001 10:09:03 -0500 2 From: rdeininger@mindspring.com (Robert Deininger)7 Subject: Re: Server vs. Workstation:  You Make The CalleL Message-ID: <rdeininger-2011011009050001@user-2ive7v8.dialup.mindspring.com>  4 In article <3BFA696A.83C13347@UIowa.EDU>, Rick Dyson <Rick-Dyson@UIowa.EDU> wrote:e  F >     For the purposes of licensing the Compaq CSLG/ESL, they define a2 > "system" as a server *OR* five (5) workstations. > C >     Can anyone help me "officially" clarify whether the followingdA > Digital/Compaq hardware are either a 'server' or 'workstation'?n >  >     DEC 3000/400D Sold in both server and workstation configurations.  The hardware isJ identical, as far as I can tell.  There's a "SERVER" environment variable,E but it doesn't seem to matter. The S3 switch chooses the console. ThetG server configuration is sometimes named a 3000/400S, and probably has a0, slightly different model number on the back.   >     Alpha 3000/500I If you mean the DEC 3000/500, it's "mainly" a workstation, since it has agE built-in graphics adapter.  But it will work as a server if desired. t( (I've never heard of an "Alpha 3000/500"   >     XP1000 Intended as a workstation.  
 >     ES45 >     ES40 68/833n= AFAIK, all the "modern" alpha systems will work as servers oraI workstations.  Supposedly you can add a graphics card to a GS320 and make  a really big workstation.    >     uVAX 3300i Dunno.     Of course, I'm not "official".   -- d Robert Deininger rdeininger@mindspring.come   ------------------------------   Date: 20 Nov 2001 09:34:23 GMT3 From: gartmann@immunbio.mpg.de (Christoph Gartmann)t> Subject: Re: Software to emulate someone sitting at a terminal0 Message-ID: <9td82v$egj$1@n.ruf.uni-freiburg.de>  R In article <3BF9E9CF.6737F300@vsm.com.au>, Jeremy Begg <jeremy@vsm.com.au> writes:L >Earlier this month I enquired about NEXUS BSI for MANMAN.  No one seemed toG >know what it was but since then I have learned that it's a utility for>J >emulating a user sitting at a terminal, typing responses to prompts.  The, >comments in various files have this header: >t >    NEXUS Software Services >      Gainsborough Houseb >       109 Portland Stb >      Manchester   M1 6DN >       Tel: 061 237 3126r >hG >(I'm going to try calling that number tonight, but I've been told thatf; >previous attempts to contact the business failed totally.)r > H >In our case, NEXUS BSI is being used to automate data entry into MANMANI >V11.2.  There are a serious of script files, each of which specifies theDG >prompts to expect and the responses to supply.  Variable responses arewM >supplied by defining logical names which get substituted at run-time.  TheretK >are also facilities to specify that a prompt must appear at certain screen D >coordinates, but I'm not sure if this is a critical feature for us. >>J >Does anyone know of any software -- commercial or freeware -- which couldL >perform a similar task?  I can probably put something together using Kermit$ >but I'm interested in alternatives.  L Kermit is perfectly suitable for this kind of a task. Of course, use a newer+ version of C-Kermit and not the old stuff. a  E Some time ago we had a software using some kind of a GUI on terminals L (pull-down menus, highlighting and the like) that required a restart of someN of its components from time to time. This task had to be performed via the GUIK under the SYSTEM account. So we created a scribt using C-Kermit that ran in  batch just to do the restart.e   Regards,    Christoph Gartmanns  H -- --------------------------------------------------------------------+H | Max-Planck-Institut fuer      Phone   : +49-761-5108-464   Fax: -452 |H | Immunbiologie                                                        |H | Postfach 1169                 Internet: gartmann@immunbio.mpg.de     |H | D-79011  Freiburg, FRG                                               |H +--------- http://www.immunbio.mpg.de/home/english/menue.html ---------+   ------------------------------  % Date: Tue, 20 Nov 2001 11:53:08 +0000   From: Steve.Spires@yellgroup.com> Subject: Re: Software to emulate someone sitting at a terminal: Message-ID: <OF4E330865.59F62C9F-ON00256B0A.00410CFE@btyp>  H I don't know if this is the same company, but searching through the Yell" database here I came up with this;   Nexus Software (UK) Ltd 6 The Spinney Parklands Business Park, Forest Rd Denmead Waterlooville Hampshire PO7 6ARm   Tel: 023 9224 8300   It may be worth a try.   As for the number you have below, that has to be quite a few years old, as the Manchester code changed some time ago. It's now 0161 rather than 061.   Cheers   Steve Sk        9 Jeremy Begg <jeremy@vsm.com.au> on 11/20/2001 05:27:43 AM     To:        Info-VAX@Mvb.Saic.Com cc: G From:      Jeremy Begg <jeremy@vsm.com.au>, 20 November 2001, 5:27 a.m.i  1 Software to emulate someone sitting at a terminala     Hi,   K Earlier this month I enquired about NEXUS BSI for MANMAN.  No one seemed toiF know what it was but since then I have learned that it's a utility forI emulating a user sitting at a terminal, typing responses to prompts.  Thei+ comments in various files have this header:        NEXUS Software Servicesr       Gainsborough House        109 Portland St       Manchester   M1 6DN         Tel: 061 237 3126  F (I'm going to try calling that number tonight, but I've been told that: previous attempts to contact the business failed totally.)  G In our case, NEXUS BSI is being used to automate data entry into MANMAN H V11.2.  There are a serious of script files, each of which specifies theF prompts to expect and the responses to supply.  Variable responses areE supplied by defining logical names which get substituted at run-time.a There<J are also facilities to specify that a prompt must appear at certain screenC coordinates, but I'm not sure if this is a critical feature for us.   I Does anyone know of any software -- commercial or freeware -- which couldiK perform a similar task?  I can probably put something together using Kermitk# but I'm interested in alternatives.m   Thanks,            Jeremy Beggh  =   +---------------------------------------------------------+e=   |            VSM Software Services Pty. Ltd.              |/=   |                 http://www.vsm.com.au/                  |m=   |       "OpenVMS Systems Management & Programming"        | =   |---------------------------------------------------------|e=   | P.O.Box 402, Walkerville, |  E-Mail:  jeremy@vsm.com.au |*=   | South Australia 5081      |   Phone:  +61 8 83592155    |a=   |---------------------------|  Mobile:  0414 422 947      |0=   |  A.C.N. 068 409 156       |     FAX:  +61 8 82231777    |0=   +---------------------------------------------------------+s      F ______________________________________________________________________     [Information] -- PostMaster:D This transmission is intended solely for the addressee(s) and may beG confidential. If you are not the named addressee, or if the message has"G been addressed to you in error, you must not read, disclose, reproduce,e$ distribute or use this transmission.  H Delivery of this message to any person other than the named addressee isG not intended in any way to waive confidentiality.  If you have received K this transmission in error please contact the sender or delete the message.a  
 Thank you.  D Yell Limited, Queens Walk, Oxford Road, Reading, Berkshire, RG1 7PT.; Registered in England and Wales, registered number 4205228.   I Yellow Pages Sales Limited, Queens Walk, Oxford Road, Reading, Berkshire,kD RG1 7PT. Registered in England and Wales, registered number 1403041.   ------------------------------    Date: 20 Nov 2001 08:37:34 -0800- From: tessier-ashpool@usa.net (Chris Bardell)n> Subject: Re: Software to emulate someone sitting at a terminal= Message-ID: <9f261edc.0111200837.7e28e0e4@posting.google.com>-   >     NEXUS Software Services3 >       Gainsborough House >        109 Portland St >       Manchester   M1 6DNs >        Tel: 061 237 3126 > H > (I'm going to try calling that number tonight, but I've been told that< > previous attempts to contact the business failed totally.)  E 1. UK phone numbers changed about 4 years back, with an extra digit 1tD after the 0 in the area code. Try this format: +44 161 237 3126 (you5 drop the zero when dialling into UK internationally).   > Stop Press - don't bother trying. The BT automated response toC dialling that number: "sorry, this number has not been recognised",1 ie: it's a dead phone number.i  E 2. Don't Computer Ass-ociates own MANMAN nowadays? Can they help you?V. http://interbiz.com/Products/SC/ERP/manman.asp  C 3. Another 'emulate humans typing stuff in' product is Cyrano Test. D See http://www.cyrano.com/products/test.html NB: used to be known as) Performance Software V-TEST a while back.    Not much, but HTH. Cheers mate.1  
 Chris Bardell5 Pommie-lande   ------------------------------    Date: 20 Nov 2001 07:52:10 -0600+ From: young_r@encompasserve.org (Rob Young) B Subject: Re: Solaris: ready for prime time?  Keep your VMS system.3 Message-ID: <gMhjB2Cuz0h9@eisner.encompasserve.org>m  i In article <E0gK7.37552$4m.2405972@news2.aus1.giganews.com>, "Bill Todd" <billtodd@metrocast.net> writes:  > 8 > Rob Young <young_r@encompasserve.org> wrote in message/ > news:ItztRomoRSJk@eisner.encompasserve.org...1 >  > ...9 > A >> What if our idea of clustering is failing over to another box? $ >> Can we still call that a cluster? >>6 >> Sure kid.... why not.  If it makes you feel better. > B > And so can customers, since in most cases it provides equivalentG > *functionality*, which is, after all, what customers are looking for.  >   ; 	But it doesn't...  We could (I'm sure) spend a lot of times@ 	on this... but the fact of the matter they aren't "functionallyA 	equivalevent" but often "good enough we hope".  Testing and moresC 	testing to ensure it works... good.  But one gotcha in a "failoveraA 	cluster" I know if is that once box A fails over to box B a full B 	integrity check must be run, which takes quite a while to trundle 	through all those blocks.  > 	They aren't equivalent paradigms.  One is far superior to the< 	other and I'll give you a few seconds to take a stab at it.   > M > As long as VMS bigots keep calling anything that isn't a VMS cluster a pooreK > imitation, they'll miss the need for VMS to match in other respects thoseBE > other forms of clusters that *are* competing successfully with VMS,e/ > regardless of what people like Rob may think.u >   A 	I'm a VMS bigot because I understand both sides of the argument, ? 	(remember Bill?) not in spite of it.  I also try to talk about C 	experience... first or second hand where second hand is the people : 	are describing what takes place and I'm paying attention.   				Rob    ------------------------------    Date: 20 Nov 2001 07:57:13 -0600- From: koehler@encompasserve.org (Bob Koehler) B Subject: Re: Solaris: ready for prime time?  Keep your VMS system.3 Message-ID: <pVcoAl$uvOQo@eisner.encompasserve.org>6  N In article <3BF9BC2B.7561FAEE@prodigy.net>, cjt <cheljuba@prodigy.net> writes: > Bob Koehler wrote: >> mP >> In article <3BF94D2E.15FB@c-lab.de>, Michael Joosten <joost@c-lab.de> writes: >> >' >> > What do you mean with 'wiped out'?  >>  I >>    As in kernel starts generating messages claiming the file system isg >>    full.  > , > That seems appropriate -- not 'wiped out.'  H    The users have no files after the crash, but the file system is full.E    That's what I mean by wiped out.  After all I was listening to thebA    beeps that came with the kernel messages and neither I nor theuD    actuall users were particularly worried.  After all, Solaris is a    modern UNIX, right?    g   ------------------------------  # Date: Tue, 20 Nov 2001 14:27:52 GMTu* From: "Bill Todd" <billtodd@metrocast.net>B Subject: Re: Solaris: ready for prime time?  Keep your VMS system.7 Message-ID: <ILtK7.110$YD.8935@news2.aus1.giganews.com>   6 Rob Young <young_r@encompasserve.org> wrote in message- news:gMhjB2Cuz0h9@eisner.encompasserve.org...rJ > In article <E0gK7.37552$4m.2405972@news2.aus1.giganews.com>, "Bill Todd"  <billtodd@metrocast.net> writes: > >e: > > Rob Young <young_r@encompasserve.org> wrote in message1 > > news:ItztRomoRSJk@eisner.encompasserve.org...r > >A > > ...b > >mC > >> What if our idea of clustering is failing over to another box?g& > >> Can we still call that a cluster? > >>8 > >> Sure kid.... why not.  If it makes you feel better. > >dD > > And so can customers, since in most cases it provides equivalentI > > *functionality*, which is, after all, what customers are looking for.d > >p >t > But it doesn't...(  F Yes, it does:  you may not understand it, but shouldn't be so quick to propagate your ignorance.n  )   We could (I'm sure) spend a lot of timewA > on this... but the fact of the matter they aren't "functionallytB > equivalevent" but often "good enough we hope".  Testing and more% > testing to ensure it works... good.o  G Exactly how is this different from the testing that a cluster-aware VMSgK application must go through?  For that matter, since the fail-over paradigmoA is *a lot* simpler at the application level than building a trulynK cluster-aware application (in failing over, the new copy of the applicationaC on another node just takes over the data the same way a stand-aloneeF application would pick it up on a reboot), I suspect that a great manyD robust applications use exactly the same approach on VMS rather thanL synchronizing parallel cooperating instances on multiple nodes (which can ofH course also be done on a platform that uses fail-over for the underlying" system facilities if one chooses).     But one gotcha in a "failover.B > cluster" I know if is that once box A fails over to box B a fullC > integrity check must be run, which takes quite a while to trundlec > through all those blocks.t  K No, it takes a few seconds if the file system is protected by a log - e.g.,tI as the log-enhanced UFS is on Solaris, ext3fs is on Linux, VxFS is on allpF the platforms Veritas supports, AdvFS is on Tru64, JFS is on AIX, etc.   >-? > They aren't equivalent paradigms.  One is far superior to theS= > other and I'll give you a few seconds to take a stab at it.g >b > >fJ > > As long as VMS bigots keep calling anything that isn't a VMS cluster a poorG > > imitation, they'll miss the need for VMS to match in other respects. those G > > other forms of clusters that *are* competing successfully with VMS,m1 > > regardless of what people like Rob may think.f > >h > B > I'm a VMS bigot because I understand both sides of the argument,& > (remember Bill?) not in spite of it.  F From your comments above, you certainly don't appear to understand the
 non-VMS side.i   - bill   ------------------------------  % Date: Tue, 20 Nov 2001 04:05:28 -0500t- From: JF Mezei <jfmezei.spamnot@videotron.ca>9N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org, Message-ID: <3BFA1CD7.3E15A01C@videotron.ca>   Peter da Silva wrote:cP > > presented in a court of law and without hard evidence, they will have to set > > Bin Laden free.m > 0 > Not if they try him under a military tribunal.  L What is the difference between a real court of law and a military tribunal ?I Is it a case of the "evidence" being usable in a military tribunal due to K secrecy, or a case of the evidence not being needed to convinct Bin Laden ?   K And in a military tribunal, once summarily convincted of whatever crimes hecM would be guilty of under military law, what sort of punishment could be givennL ? Just kept in a military prison ? Not much point in stripping him of Bin's ) USA military ranks and discharging him...U  M If the military court will just be a rubber stamping of his guilt, what's the3 point ?o  H Wouldn't it be better to send him to some muslim country where the courtI system doesn't pretend to be fair and who would have a vested interest inlM declaring him guilty and cutting off whatever limb corressponds to the crimesiL he organised ? This way, the USA court system wouldn't have to be tested, orC the USA wouldn't be seen as giving him an unfair (military)  trial.d   ------------------------------  # Date: Tue, 20 Nov 2001 13:56:19 GMT2  From: chrisv <chrisv@chrisv.com>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org8 Message-ID: <2bokvtk06qjv4aj05kqqtoqt1tgvvkq51k@4ax.com>  A Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>C wrote:  ) >"Jeff Killeen" <Jeff@IDM-IO.com> writes:w >eM >> Got it - in the world of Bill Todd anyone who sees things differently from M >> the great sage Todd is a weak-minded or obstinate fool.  It must be such a"K >> burden on you being the absolute source of subjective of opinion that ish  >> indisputably without error... > N >I have yet to read anything - from you, from Terry, from Compaq, from anybody: >- that puts substantative holes in Bill's arguumentation. >e >	Jane  ' Exactly.  Nothing but personal attacks..   ------------------------------    Date: 20 Nov 2001 10:37:25 -0600+ From: kuhrt@encompasserve.org (Marty Kuhrt) N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org3 Message-ID: <9NHd$s6tHMrr@eisner.encompasserve.org>e  N In article <9tch93$4ha@web.nmti.com>, peter@abbnm.com (Peter da Silva) writes:G > In article <akIJ7.50970$hZ.4821948@newsread2.prod.itd.earthlink.net>, / > aaron spink <aaronspink@earthlink.net> wrote:F? >> "We the People of the United States".  The Constitution is akL >> convonent/contract entered into by the people of the united states(aka USN >> citizens).  The protections and rights are really just contracts between inL >> the parties involved in the contract(aka US citizens).  The contract onlyK >> applied to those who have signed the contract.  The contract can only be.F >> signed by those parties who have been invited to sign the contract. > , > How does a newborn infant sign a contract? >  > -- g- >  `-_-'   In hoc signo hack, Peter da Silva.uG >   'U`    "A well-rounded geek should be able to geek about anything."dN >                                                        -- nicolai@esperi.org >          Disclaimer: WWFD?  : And what does this have to do with Alpha, VMS, or anything4 relevant to the newsgroups this was cross posted in?   I'll give you a hint.  NOTHING!f   ------------------------------  % Date: Tue, 20 Nov 2001 19:01:07 +0100 1 From: John McLean <mcleanj@swissonline.delete.ch>hN Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org5 Message-ID: <3BFA9A63.F6D12B26@swissonline.delete.ch>r   JF Mezei wrote:  >  > Peter da Silva wrote:tR > > > presented in a court of law and without hard evidence, they will have to set > > > Bin Laden free.p > >s2 > > Not if they try him under a military tribunal. > N > What is the difference between a real court of law and a military tribunal ?K > Is it a case of the "evidence" being usable in a military tribunal due tonM > secrecy, or a case of the evidence not being needed to convinct Bin Laden ?   G As much as I don't want to prolong this discussion - at least not underu3 this topic - there's a point that needs to be made.t  D In the rush of adrenalin by the US Congress after Sep 11th they haveF passed bills to say that acts of terrorism will be tried by a militaryF court.  According to reports I have read, this means that the need forE evidence will not be as stringent and that detention for long periodshH before being charged is a real possibility.  In effect we are looking atH legal niceties being dispensed with.  Okay, for the bad guys it might beG fair punishment, but what about the innocents who get caught up in thisu ...   @ Note that hacking and various other IT related events can now be considered to be terrorism.-     John McLean-   ------------------------------  # Date: Tue, 20 Nov 2001 18:04:47 GMT 4 From: "Terry C. Shannon" <terryshannon@mediaone.net>N Subject: Re: Special IPF-Inside Issue of Shannon Knows Compaq at www.tru64.org< Message-ID: <3XwK7.6952$eh7.4030670@typhoon.ne.mediaone.net>  > "John McLean" <mcleanj@swissonline.delete.ch> wrote in message/ news:3BFA9A63.F6D12B26@swissonline.delete.ch...  >- <snip> > ...- >-B > Note that hacking and various other IT related events can now be > considered to be terrorism.f >r   A point well worth noting.   ------------------------------  % Date: Tue, 20 Nov 2001 09:43:41 -0700 + From: Linda Luik <p14175@email.sps.mot.com> % Subject: TZ887 installation questionsr1 Message-ID: <3BFA883D.F5560136@email.sps.mot.com>    All,  F I haven't done a tape drive installation in a little while so I have a$ couple of easy no-brainer questions:  H I am hooking a TZ887 to a Alpha 2000 running Alpha O/S 6.2-1h3 with full patches (as far as I know).sG There are three disks installed (dka100, 200, 600) and an internal  4mm F tape drive (mka500). This leaves scsi ports 3 and 4 open for business.A The system has a storageworks box containing more disks, but this 1 shouldn't be important to the tape drive install.m   Do I:t& 1) set the TZ887 dip switch to 3 or 4?8 <<< install the tape drive by plugging it in , etc... >>6 2) run autoconfigure or will a reboot be needed first?  , * Is there anything else I need to consider?   Thanks!l   ------------------------------  # Date: Tue, 20 Nov 2001 17:15:28 GMTo' From: Rick Dyson <Rick-Dyson@UIowa.EDU> ) Subject: Re: TZ887 installation questionsn) Message-ID: <3BFA8FB0.3FBBFCCC@UIowa.EDU>    Linda Luik wrote: J > I am hooking a TZ887 to a Alpha 2000 running Alpha O/S 6.2-1h3 with full > patches (as far as I know).oI > There are three disks installed (dka100, 200, 600) and an internal  4mmBH > tape drive (mka500). This leaves scsi ports 3 and 4 open for business.C > The system has a storageworks box containing more disks, but thisc3 > shouldn't be important to the tape drive install.e >  > Do I: ( > 1) set the TZ887 dip switch to 3 or 4?: > <<< install the tape drive by plugging it in , etc... >>8 > 2) run autoconfigure or will a reboot be needed first?  B 	I would just choose one.  It doesn't matter in the long run.  TheM more important concerns are total SCSI cabling length and proper termination. < I will assume you already are up to speed with those issues.  ) 	No need to reboot, unless you want to...    		$ MCR Sysman 		SYSMAN> IO Autoconfig /Log  F 	I might suggest you look into the MRU (Media Robot Utility, I think),I with it's ROBOT and XROBOT interfaces for controlling the robotic unit on/J the drive from a remote terminal.  Very handy unless you like driving into7 work to move a tape from one slot to another at 3am. :)-   Regards, Rick   ------------------------------  % Date: Tue, 20 Nov 2001 11:21:00 +0000t% From: Alan Greig <a.greig@virgin.net>1D Subject: Re: VMS on IBM power chip would make IBM No. 1 in high end!8 Message-ID: <7rekvtku1lmimhvrfl24gt8utksu4nimnt@4ax.com>  F On Fri, 16 Nov 2001 22:44:11 -0500, David Froble <davef@tsoft-inc.com> wrote:   >John Eisenschmidt wrote:_ >_H > > Alpha is already gone. IBM won't be doing anything with that - which( > >  is fine, Power is a great platform.  C But part of the justification Compaq used to decide that IA64 wouldeF become industry standard was that nobody else would be able to keep upC with Intel investment. A power point slide at Friday#s London DECUSeB actually said that "IBM will not be able to afford to keep up with> Intel". This was challenged from the audience - one of the fewF challenges that didn't come from me...The question was put as "How canB you say that the biggest computer company in the world will not be? able to keep up with Intel".The answer was just "that's what weaF predict". I also took issue with the use of "Industry Standard" in all' the powerpoint slides to describe IA64.G  ? >That's not a given.  It would depend upon the perdeived future G >capabilities of Alpha.  Note that IBM had their own architechures, andmF >still adder another, POWER.  Multiple CPUs don't seem to bother them. >eH > > As for a VMS port to Power - you're more likely to see a discount onB > >  IBM services to migrate to one of their other offerings. They@ > > already have two non-Unix OSes, why would they want a third? >sJ >One answer, to make even more money.  They're making as much as they can J >on what they have.  Having another money maker would be a good thing for  >IBM.t >lF >And they'd be no more successful with the 'M' word that anyone else. F >There will definitely be a shoot the messenger mentality when anyone I >tells VMS users that they must move on.  IBM doesn't need Compaq to woo -? >VMS users, and having Compaq would actually be a disadvantage.  >b >Daver   -- Alan   ------------------------------  % Date: Tue, 20 Nov 2001 05:44:51 -0800C# From: "Tom Linden" <tom@kednos.com>yD Subject: RE: VMS on IBM power chip would make IBM No. 1 in high end!9 Message-ID: <CIEJLCMNHNNDLLOOGNJIGEKPDJAA.tom@kednos.com>C   > -----Original Message-----. > From: Alan Greig [mailto:a.greig@virgin.net]* > Sent: Tuesday, November 20, 2001 3:21 AM > To: Info-VAX@Mvb.Saic.ComrF > Subject: Re: VMS on IBM power chip would make IBM No. 1 in high end! >  >aH > On Fri, 16 Nov 2001 22:44:11 -0500, David Froble <davef@tsoft-inc.com> > wrote: >R > >John Eisenschmidt wrote:i > >KJ > > > Alpha is already gone. IBM won't be doing anything with that - which* > > >  is fine, Power is a great platform. >.E > But part of the justification Compaq used to decide that IA64 would H > become industry standard was that nobody else would be able to keep upE > with Intel investment. A power point slide at Friday#s London DECUStD > actually said that "IBM will not be able to afford to keep up with@ > Intel". This was challenged from the audience - one of the fewH > challenges that didn't come from me...The question was put as "How canD > you say that the biggest computer company in the world will not beA > able to keep up with Intel".The answer was just "that's what wemH > predict". I also took issue with the use of "Industry Standard" in all) > the powerpoint slides to describe IA64.   J For someone to claim that IBM couldn't keep with Intel in spending strikesH me as foolhardy and irresponsible.  The fact that the speaker offered no analysisG backing his prediction, suggests it has no value.  It is BS and drivel.a >tA > >That's not a given.  It would depend upon the perdeived futurerI > >capabilities of Alpha.  Note that IBM had their own architechures, and H > >still adder another, POWER.  Multiple CPUs don't seem to bother them. > >oJ > > > As for a VMS port to Power - you're more likely to see a discount onD > > >  IBM services to migrate to one of their other offerings. TheyB > > > already have two non-Unix OSes, why would they want a third? > >SK > >One answer, to make even more money.  They're making as much as they canoK > >on what they have.  Having another money maker would be a good thing forh > >IBM.  > >dG > >And they'd be no more successful with the 'M' word that anyone else.eG > >There will definitely be a shoot the messenger mentality when anyone J > >tells VMS users that they must move on.  IBM doesn't need Compaq to wooA > >VMS users, and having Compaq would actually be a disadvantage.  > >A > >Davei >r > -- > Alan >g   ------------------------------    Date: 20 Nov 2001 06:00:45 -0800( From: bob@instantwhip.com (Bob Ceculski)D Subject: Re: VMS on IBM power chip would make IBM No. 1 in high end!= Message-ID: <d7791aa1.0111200600.440d44d1@posting.google.com>>  x "Terry C. Shannon" <terryshannon@mediaone.net> wrote in message news:<I3aK7.4454$eh7.2928925@typhoon.ne.mediaone.net>...4 > "Dan O'Reilly" <dano@process.com> wrote in message> > news:5.1.0.14.2.20011116104611.00a86400@raptor.psccos.com.../ > > At 10:42 AM 11/16/2001, Bob Ceculski wrote: I > > >If IBM bought Compaq they could use either alpha or power or a comboa@ > > >to run VMS and rule the high end ... linux is not high end! > > - > > ..and pigs could be taught to fly <grin>.- > > I > > Do you REALLY think they would give up their flagship midrange systems
 >  (OS400) > > in favor of VMS? > L > Hell no. Do the math: AS400 brings in lots more filthy lucre than VMS everH > did. At its peak, the AS400 business was $15B, bigger than DEC itself. > = > Remember, IBM originally marketed that as the "VAX-Killer".K > K > The trade press called the 9370 the VAX Killer. They were dead wrong. The>J > AS400, however, sure as hell deprived DEC of a lot of potential revenue. > " > And it's a nice machine besides. >  > >rJ > > IBM buying CPQ would be about the worst scenario from VMS's standpoint >  thatr > > could occur. > L > Can't see the rationale for making such an acquisition in the first place.  ? it may be a nice machine, but is has no decent os to run on it!pH OS400 is not a high end OS like VMS ... it is a piece of garbage writtenH to keep their system 3x customers ... os400 is a lousy menu based closedE OS ... I spent a month on one once to see if it was comparible to vmsnF and that one month was about all I could have taken!  We crashed twiceI in that month and their support people had no clue as to why!  Most os400eH users like the one I worked for are running in system 3x mode which justE kills the processor ... would have been cheaper to just stay on theireF 3x box ... their is "nothing" that compares with vms, and IBM I'm sureH would love to have a real high end os instead of the junk they have now!   ------------------------------  % Date: Tue, 20 Nov 2001 08:04:55 -0800h' From: David Mathog <mathog@caltech.edu>sD Subject: Re: VMS on IBM power chip would make IBM No. 1 in high end!+ Message-ID: <3BFA7F27.BD8DBD9D@caltech.edu>    Tom Linden wrote:sL > For someone to claim that IBM couldn't keep with Intel in spending strikesJ > me as foolhardy and irresponsible.  The fact that the speaker offered no
 > analysisI > backing his prediction, suggests it has no value.  It is BS and drivel.u  D Agreed.  But I'd like to nominate the use of the "industry standard" nomenclature as applied D to the IA64 processor for the very top position in the BS and drivel list.  There is no argument F that the x86 architecture is currently the industry standard. However, the IA64 is not only unproven H (more accurately, it's proving to be nearly impossible for Intel to ship in a working form)E but it is also incompatible with the existing standard.  Just because  this chip exists (sort of)G does not mean it will become the next standard - much as Intel, HP, andf Compaq conspire toG make it so.  The number of units shipped to date in no way qualifies ittD for the title of "industry standard". There are plenty of reasons to? think that the industry standard will remain x86 related, whichiD suggests to me that if AMD can make it's 64 bit Hammer series run as well as they claim theysG may relegate the IA64 to a niche little bigger than that held by Alpha.t     Regards,   David Mathog mathog@caltech.edu   ------------------------------  # Date: Tue, 20 Nov 2001 14:52:31 GMT-4 From: "Terry C. Shannon" <terryshannon@mediaone.net>D Subject: Re: VMS on IBM power chip would make IBM No. 1 in high end!< Message-ID: <P6uK7.6847$eh7.3898499@typhoon.ne.mediaone.net>  . "Tom Linden" <tom@kednos.com> wrote in message3 news:CIEJLCMNHNNDLLOOGNJIGEKPDJAA.tom@kednos.com...  >  >  > > -----Original Message-----0 > > From: Alan Greig [mailto:a.greig@virgin.net], > > Sent: Tuesday, November 20, 2001 3:21 AM > > To: Info-VAX@Mvb.Saic.ComaH > > Subject: Re: VMS on IBM power chip would make IBM No. 1 in high end! > >u > > J > > On Fri, 16 Nov 2001 22:44:11 -0500, David Froble <davef@tsoft-inc.com>
 > > wrote: > >c > > >John Eisenschmidt wrote:t > > >bL > > > > Alpha is already gone. IBM won't be doing anything with that - which, > > > >  is fine, Power is a great platform. > >iG > > But part of the justification Compaq used to decide that IA64 wouldoJ > > become industry standard was that nobody else would be able to keep upG > > with Intel investment. A power point slide at Friday#s London DECUSoF > > actually said that "IBM will not be able to afford to keep up withB > > Intel". This was challenged from the audience - one of the fewJ > > challenges that didn't come from me...The question was put as "How canF > > you say that the biggest computer company in the world will not beC > > able to keep up with Intel".The answer was just "that's what weiJ > > predict". I also took issue with the use of "Industry Standard" in all+ > > the powerpoint slides to describe IA64.o > L > For someone to claim that IBM couldn't keep with Intel in spending strikesJ > me as foolhardy and irresponsible.  The fact that the speaker offered no
 > analysisI > backing his prediction, suggests it has no value.  It is BS and drivel.D  D I have seen this prediction (in another PPT slideshow and in writtenJ collateral) and have yet to see Compaq fully support or justify the claim.J The permutation I heard was that IPF performance would be equal or greater. to that of then-shipping Power chips by ~2005.  F I'll stick by my own observation: IBM has plenty of resources, capableH marketeers, and an extensive R&D program. Whether the Power architectureK outpaces IPF chips or not, IBM has the wherewithal and the customer base to G continue building Power-based systems for as long as it wants to do so.   L And at the end of the day, raw processor speed doesn't mean a hell of a lot.> If it did, Alpha would have trounced UltraSparc years ago. ;-}   cheers,c  1 terry "It's STILL the Marketing, Stupid!" shannono   ------------------------------  # Date: Tue, 20 Nov 2001 16:11:28 GMTZ4 From: "Terry C. Shannon" <terryshannon@mediaone.net>D Subject: Re: VMS on IBM power chip would make IBM No. 1 in high end!< Message-ID: <QgvK7.6900$eh7.3950448@typhoon.ne.mediaone.net>  4 "David Mathog" <mathog@caltech.edu> wrote in message% news:3BFA7F27.BD8DBD9D@caltech.edu...  > Tom Linden wrote:aF > > For someone to claim that IBM couldn't keep with Intel in spending strikesnL > > me as foolhardy and irresponsible.  The fact that the speaker offered no > > analysisK > > backing his prediction, suggests it has no value.  It is BS and drivel.o >oF > Agreed.  But I'd like to nominate the use of the "industry standard" > nomenclature as applied F > to the IA64 processor for the very top position in the BS and drivel > list.   I Alas, IA64 (then P7) attained "Industry Standard" status on June 3, 1994. E That's the day Intel and HP announced the architecture. The press andoG analyst community immediately conferred the coveted "De Facto Standard"gJ label on the vaporous chip. This despite a downright nebulous announcement; and a roadmap that rivalled old Soviet maps for inaccuracy.n   And so it goes...j   ------------------------------  # Date: Tue, 20 Nov 2001 17:54:59 GMTg= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)MD Subject: Re: VMS on IBM power chip would make IBM No. 1 in high end!0 Message-ID: <00A0554B.066FD27C@SendSpamHere.ORG>  U In article <3BFA7F27.BD8DBD9D@caltech.edu>, David Mathog <mathog@caltech.edu> writes:  >Tom Linden wrote:M >> For someone to claim that IBM couldn't keep with Intel in spending strikesoK >> me as foolhardy and irresponsible.  The fact that the speaker offered no  >> analysisvJ >> backing his prediction, suggests it has no value.  It is BS and drivel. >pE >Agreed.  But I'd like to nominate the use of the "industry standard"i >nomenclature as appliedE >to the IA64 processor for the very top position in the BS and drivele >list.  There is no argumentG >that the x86 architecture is currently the industry standard. However,I >the IA64 is not only unprovenI >(more accurately, it's proving to be nearly impossible for Intel to shipi >in a working form)aF >but it is also incompatible with the existing standard.  Just because >this chip exists (sort of) H >does not mean it will become the next standard - much as Intel, HP, and >Compaq conspire tonH >make it so.  The number of units shipped to date in no way qualifies itE >for the title of "industry standard". There are plenty of reasons to-@ >think that the industry standard will remain x86 related, whichE >suggests to me that if AMD can make it's 64 bit Hammer series run asI >well as they claim theyH >may relegate the IA64 to a niche little bigger than that held by Alpha. >d >n	 >Regards,J > 
 >David Mathogj >mathog@caltech.eduh  ? But David, it's just as industry standard as the intel iAPX432.    --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMo            dJ   "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: Tue, 20 Nov 2001 19:04:04 +0100-1 From: John McLean <mcleanj@swissonline.delete.ch> D Subject: Re: VMS on IBM power chip would make IBM No. 1 in high end!5 Message-ID: <3BFA9B14.7F2E682D@swissonline.delete.ch>g   David Mathog wrote:0 >  > Tom Linden wrote:3N > > For someone to claim that IBM couldn't keep with Intel in spending strikesL > > me as foolhardy and irresponsible.  The fact that the speaker offered no > > analysisK > > backing his prediction, suggests it has no value.  It is BS and drivel.t > ^ > Agreed.  But I'd like to nominate the use of the "industry standard" nomenclature as appliedL > to the IA64 processor for the very top position in the BS and drivel list.  F ... and I suggest that we shorten the term to "IS".  Some may think itC is "Industry Standard" but we will know hat more often it is "Idiote Speaking"...  :-)1     John McLeanm   ------------------------------  + Date: Tue, 20 Nov 2001 07:59:05 +0100 (MET) & From: Rudolf Wingert <win@fom.fgan.de> Subject: Xetra, on which OS?6 Message-ID: <200111200659.HAA01972@sinet1.fom.fgan.de>   Hello,  A today I red in a German newspaper, that here in Germany the stockeB system Xetra was down for two hours. On which OS runs Xetra? Or isC Xetra the OS? Was the underlaying OS OpenVMS? If yes, why did it bes down  for two hours?   TIA and regards Rudolf Wingert   ------------------------------  % Date: Tue, 20 Nov 2001 08:54:38 +0100T$ From: "Jakob Erber" <erberj@post.ch>  Subject: Re: Xetra, on which OS? Message-ID: <3bfa0c3f$1@hcwe67>i   It runs on OpenVMS AXP.e  9 "Rudolf Wingert" <win@fom.fgan.de> schrieb im Newsbeitrag 0 news:200111200659.HAA01972@sinet1.fom.fgan.de... > Hello, >iC > today I red in a German newspaper, that here in Germany the stocktD > system Xetra was down for two hours. On which OS runs Xetra? Or isE > Xetra the OS? Was the underlaying OS OpenVMS? If yes, why did it bey > down  for two hours? >   > TIA and regards Rudolf Wingert >O   ------------------------------  % Date: Tue, 20 Nov 2001 08:51:33 +0100r, From: "Bart Zorn" <B.Zorn@TrueBit.nospam.nl>H Subject: Re: [VMS Motif] How to avoid starting the DECW$SERVER process ?* Message-ID: <9td24g$adu$1@news1.xs4all.nl>  7 "Peter LANGSTOEGER" <eplan@kapsch.net> wrote in messagel$ news:3bf98fcc$1@news.kapsch.co.at...J > I just want to start a system (a workstation) with MOTIF but without theH > DECW$SERVER process (I don't use the graphics console and want to save mem).0 >a% > What is the best/suggested method ?: > F > Defining DECW$IGNORE_DECWINDOWS is not ok, because MOTIF is then not startedt% > at all (images not installed, ...).o > C > SYSGEN WINDOW_SYSTEM=0 does normally only lead to endless AUTOGENd
 questions. >  > Anyone, please ?  ) You could define DECW$IGNORE_WORKSTATION.l  J An other option is to remove the graphics card. That will save you energie as well!   HTH,  	 Bart Zorni   ------------------------------   End of INFO-VAX 2001.646 ************************