1 INFO-VAX	Tue, 24 Jul 2001	Volume 2001 : Issue 408       Contents:: ??== Postscript version of Installation Guides incomplete.F Alpha Environment System Translator - AEST (was: IA-64 has Little-...)( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate( Re: Alpha:  an invitation to communicate Re: Alpha:  ostriches and sheep ' Re: Alpha: an invitation to communicate ! Re: Basic questions from a newbie  Re: Basic VMS Question
 Block Size
 Block Size RE: Block Size Re: Block Size$ Re: Can a "White Alpha" box run VMS?0 Can OpenVMS 7.2 use LDAP for user authorization?+ Re: Check out the Wall Street Journal today + Re: Check out the Wall Street Journal today + Re: Check out the Wall Street Journal today & Re: Compaq FUD and lack of information! Re: Compaq have committed suicide ! Re: Compaq have committed suicide ! Re: Compaq have committed suicide 8 Re: Digital industry standards (Was: A Primrose Path...)8 Re: Digital industry standards (Was: A Primrose Path...)8 Re: Digital industry standards (Was: A Primrose Path...)8 Re: Digital industry standards (Was: A Primrose Path...)8 RE: Digital industry standards (Was: A Primrose Path...)0 Re: DS20e's 667Mhz in Stock - Waiting for a home  Re: Full port of VMS to Itanium. Re: Future of Alpha/VMS support  Re: Future of Alpha/VMS support  Re: Future of Alpha/VMS support  Re: Intel/Alpha announcment ) Re: IPF already needs a face-lift for VMS ) Re: IPF already needs a face-lift for VMS ) Re: IPF already needs a face-lift for VMS : Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)L Re: IPF Memory management (was: Re: VMS remains secure at DEFCON hacker festM Re: LG06 Line Printer; Manual?; Vibrates with SHTL error when printing starts L RE: LG06 Line Printer; Manual?; Vibrates with SHTL error when printingstarts" Re: LPs on the Web (Was: Re: DCPS) Migration from VMS Re: Migration from VMS
 Re: Minimerge 
 Re: Minimerge - Re: Need help with rsh from Sun to OpenVMS...  Re: No chance for OpenVMS  Re: No chance for OpenVMS ? Re: Now we're cooking with gas. (was:  Wailing and moaning....) ? Re: Now we're cooking with gas. (was:  Wailing and moaning....) ? Re: Now we're cooking with gas. (was:  Wailing and moaning....) B Re: OpenVMS on IPF (was re: IPF already needs a face-lift for VMS)B Re: OpenVMS on IPF (was re: IPF already needs a face-lift for VMS)B Re: OpenVMS on IPF (was re: IPF already needs a face-lift for VMS)& Oracle Magazine: Where is Oracle RDB ?" Re: Penance for Compaq's VMS sins? Re: Process adopts Itanium$ Re: Selling VMS to another company ?$ Re: Selling VMS to another company ?$ Re: Selling VMS to another company ?$ Re: Selling VMS to another company ?$ Re: Selling VMS to another company ?$ Re: Selling VMS to another company ? Re: SMTP and distribution lists  Re: SMTP and distribution lists  Re: SMTP and distribution lists  tcpip routing information  Re: tcpip routing information $ Re: Terry Shannon Tech Talk on IA-64$ Re: Terry Shannon Tech Talk on IA-64$ Re: Terry Shannon Tech Talk on IA-64$ Re: Terry Shannon Tech Talk on IA-64 trK Re: Triggering tasks from network file arrival - Was Re: Basic VMS  Questio  VAX 11/785 cabinet needed ...  VM: checking some myths. Re: VM: checking some myths. Re: vms backup Re: vms backup Re: vms backup Re: vms backup Re: VS3100 & (dead?) ST51080N @ What is the maximum number of mirrorsets on a HSG80 controller ?+ Re: Why Compaq won't succeed on IA64 either  Re: Zero Quadword Time Poll  Re: Zero Quadword Time Poll  Re: Zero Quadword Time Poll  Re: Zero Quadword Time Poll 5 Re: [HSJ40] Bad Cache Battery hangs OpenVMS Cluster ?   F ----------------------------------------------------------------------  % Date: Tue, 24 Jul 2001 10:14:03 +0200 , From: aus@vim.uni-wuerzburg.de (Hans M. Aus)C Subject: ??== Postscript version of Installation Guides incomplete. D Message-ID: <aus-2407011014030001@wvia48.virologie.uni-wuerzburg.de>  H The Installation Guides Postscript version are incomplete on our copy ofF the June 2001 OVMS Alpha CD-ROM Distribution. Only the first few pages= print for updates I've tried. The text versions are complete.    --  B Cheers, Hans M. Aus, Wuerzburg, Germany,  aus@vim.uni-wuerzburg.de   ------------------------------    Date: 24 Jul 2001 07:06:48 -05009 From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) O Subject: Alpha Environment System Translator - AEST (was: IA-64 has Little-...) 3 Message-ID: <Q6IC6IGwg7I8@eisner.encompasserve.org>   [ In article <3B5CC144.8B6723BD@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:  > Hoff Hoffman wrote:  >>  V >> In article <3B5A89E0.6C170D2B@dplanet.ch>, John McLean <mcleanj@dplanet.ch> writes:A >> :No not at all.  I am talking about using the recovered files.  >>  6 >>   BACKUP will be available, and will be compatible. >>  K >> :Exectuable images for VMS on Alpha may be unusable on IPF and trying to * >> :rebuild a scenario will be impossible. >>  H >>   That is nothing different than the present VAX to Alpha operations. >>  K >>   I know that we have been receiving at least a little feedback and some H >>   questions around any plans for binary translation and/or for binaryL >>   emulation, but I'll have to defer an answer to those questions for now. > F > Well, I can only speak for myself, but I should think that an "AEST"H > (Alpha-environment translator) would be expected. I could be wrong, as	 > always.   F I think a very important differentiator in the thoroughness of an AESTE would be whether one can use it to support VESTed images.  There is a C lot of support for VEST included in the TIE runtime system (and the E image activator, for that matter), and supporting those on IA64 would F require emulation not only of user images but also of operating system	 activity.    ------------------------------  + Date: Tue, 24 Jul 2001 06:32:51 +0000 (UTC) 2 From: Anil T Maliyekke <amaliy1@icarus.cc.uic.edu>1 Subject: Re: Alpha:  an invitation to communicate + Message-ID: <9jj4qj$4jr$1@newsx.cc.uic.edu>   9 In comp.arch Anne & Lynn Wheeler <lynn@garlic.com> wrote: H > i think that if you look closely ... LPARS are essentially a whole lot? > of VM moved into the "microcode" of the hardware with various C > options/features simplified. it basically started out as hardware D > accelerater for VM kernel (by incorporting significant performanceH > parts of vm kernel into the microcode of the hardware) ... and at some@ > point enuf of the VM kernel functions had been migrated to theE > hardware of the machine that it was possible to provide a subset of D > the VM kernel functions w/o even running the full-blown vm kernel.  D As long as we are on the subject of LPARs, does anyone know anythingH about the implementation of LPARs on the PPC AS/400s and how it comparesG with the S/390 implementations? They support up to four partitions on a F processor for newer PPC systems, with a max of 32 LPARs for the largerG multiprocessor systems.  The patches for PPC Linux kernel are available A and show how Linux interacts with the hypervisor to access system B resources, but I haven't found any documentation on the hypervisor* and how an individual processor is shared.   Anil   ------------------------------  % Date: Tue, 24 Jul 2001 13:14:23 +0200 * From: Alexis Cousein <al@brussels.sgi.com>1 Subject: Re: Alpha:  an invitation to communicate - Message-ID: <3B5D588F.10405@brussels.sgi.com>    mulp wrote:   G >>Given identical design styles (and tools used to layout transistors), C >>probably. But in this case, I'd say it's probably anyone's guess, / >>as design methodologies are really different.  >> > 4 > All things being equal, die size determines yield. >   & Yes. All things, though, aren't equal.   --  ? <these messages express my own views, not those of my employer> ) Alexis Cousein				Senior Systems Engineer . SGI Belgium and Luxemburg		al@brussels.sgi.com   ------------------------------  % Date: Tue, 24 Jul 2001 13:18:39 +0200 F From: Martin =?iso-8859-1?Q?H=F8yer?= Kristiansen <martin@netimage.dk>1 Subject: Re: Alpha:  an invitation to communicate + Message-ID: <3B5D598F.306D3D6D@netimage.dk>    Alexis Cousein wrote:  > 
 > mulp wrote:  > I > >>Given identical design styles (and tools used to layout transistors), E > >>probably. But in this case, I'd say it's probably anyone's guess, 1 > >>as design methodologies are really different.  > >> > > 6 > > All things being equal, die size determines yield. > >  > ( > Yes. All things, though, aren't equal.  G Die size minus SRAM arrays with build in redundancy, is closer to equal  ?   G I believe to have read a paper concerning the PA-8500, stating that the F large caches did not impact yield because of said build in redundancy.< Of course I can't find it on HP's site (only pressreleases).   Cheers Martin   ------------------------------  % Date: Tue, 24 Jul 2001 06:00:00 -0700 + From: "Dennis O'Connor" <dmoc@primenet.com> 1 Subject: Re: Alpha:  an invitation to communicate - Message-ID: <9jjrhf$p0m$1@nnrp1.phx.gblx.net>   9 "Martin Hyer Kristiansen" <martin@netimage.dk> wrote ...  > Alexis Cousein wrote:  > > mulp wrote: K > > >>Given identical design styles (and tools used to layout transistors), G > > >>probably. But in this case, I'd say it's probably anyone's guess, 3 > > >>as design methodologies are really different.  > > >> > > > 8 > > > All things being equal, die size determines yield. > > * > > Yes. All things, though, aren't equal.   Hey, that was my line !   I > Die size minus SRAM arrays with build in redundancy, is closer to equal   = Not quite.  For example, number of mask layers affects yield. D So, a chip built on a six-level-metal process will yield differently0 than a chip built on a four-level-metal process.  E Consider all the things that can cause defects:  I'm not an expert on E yield or fab processes by any means, but I imagine foreign particles, = mask misalignment, dopant concentration variations, etch rate C differences, and lattice geometry mismatches can all cause defects. B Now imagine all the things that go on in a fab that can affect the> rate at which each of these defects occur ... and then imagine= all the different ways a particular die might be more or less 6 sensitive to a particular defect ... the mind boggles. --3 Dennis O'Connor                   dmoc@primenet.com . Vanity Web Page http://www.primenet.com/~dmoc/   ------------------------------    Date: 24 Jul 2001 16:56:39 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> 1 Subject: Re: Alpha:  an invitation to communicate H Message-ID: <y43d7mqst4.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  - "Dennis O'Connor" <dmoc@primenet.com> writes:   B > No one with any knowledge of me is going to think I'm psychotic.  L I have read your posts on comp.arch for a number of years. That qualifies as% "any knowledge of [you]" in my book.    K Based on that knowledge, I consider your behaviour psychotic in many of the 2 posts I have read, including those in this thread.   Your mileage will surely vary.   	Jan   ------------------------------    Date: 24 Jul 2001 17:06:47 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> 1 Subject: Re: Alpha:  an invitation to communicate H Message-ID: <y4zo9updrs.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  0 "mulp" <michaelpettengill@earthlink.net> writes:  K > The port to Alpha was done with a lot of compromises with the expectation G > that there would be an opportunity to fix things later.  The level of A > investment in the past 7 years has not allowed that to happen.    M Be concrete - what hasn't happened up to now that was expected to happen when  VMS/AXP V1.0 was introduced?   	Jan   ------------------------------  # Date: Tue, 24 Jul 2001 16:30:11 GMT   From: jlsue <jlsuexxxz@home.com>1 Subject: Re: Alpha:  an invitation to communicate 8 Message-ID: <0k7rltg5b9er2esg35fb1kemhrgenhekv4@4ax.com>  F On Mon, 23 Jul 2001 20:54:28 -0400, Bill Gunshannon <bill@cs.uofs.edu> wrote:  " >On Mon, 23 Jul 2001, jlsue wrote: >  >>  H >> Exactly what committments are you talking about?  Certainly you don'tH >> mean the Alpha Roadmap?  Roadmaps certainly aren't to be construed asI >> something to be  followed come-hell-or-highwater.  If business climate F >> changes enough, then the company must do something else in order to >> survive.  >>   ><snip>  >>G >> But in no way did I ever see any committment to any long-term future I >> for Alpha.  And, in the real world, I don't expect that you'd ever see G >> such a committment that you could really depend upon.  It just isn't - >> possible in the business world to do that.  > ? >And yet, when people here apply the same logic to VMS they get & >accused of spreading FUD.  Go figure.  C This is only true to a point.  Surely *all* vendors of all products B can choose to cease making any products that aren't delivering theD level of profit they need.  It's a Econ 101 idea:  Opportunity cost.A The cost of doing "X" includes the cost (loss?) of not doing "Y". + When you add it all up, is it all worth it?   = The difference between this and FUD is that a competitor uses F under-handed methods to convince potential customers that this is whatE their current vendor will do to them.  It assumes that the competitor C actually knows what the other vendor will decide to do.  Basically, D it's a lie because the competitor knows that it could be in the same? boat in the unforeseeable future over the product that they are  competing with.   A The funny thing is, when HP, IBM, etc. announced awhile back that ? they'd be switching to IA64 (this was before the long delays of B delivering merced systems forced them to reevaluate), they weren'tD seen as breaking any committments.  But somehow Compaq is being heldD to a different standard by these competitors.  Yep, that's FUD in my book.    ------------------------------  # Date: Tue, 24 Jul 2001 06:06:30 GMT . From: "mulp" <michaelpettengill@earthlink.net>( Subject: Re: Alpha:  ostriches and sheepE Message-ID: <Gf877.11746$Xn.1412510@newsread1.prod.itd.earthlink.net>   : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B5B9FF8.6EC32640@videotron.ca...  H > And it also depends on whether you lump Alpha sales as well as support: > contracts. Does Compaq do much VMS consulting business ?  F Probably 20% of what DEC did before the management stuff was killed byJ giving it to CA, since the middleware was sold, since the affinity programL made it clear that staying around in services meant being Windows certified, etc.   ------------------------------    Date: 24 Jul 2001 16:17:13 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> 0 Subject: Re: Alpha: an invitation to communicateH Message-ID: <y4elr6qumu.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  7 "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:   N > Like I said, it's a Business School high-holy writ - the temporary workforceI > is a good thing.  A small "core" of long term employees, and a flexible O > temporary workforce.  No retraining, just hire contractors *with* the skills.   G Of course, the MBAs don't know that the assumptions behind this are all J broken, in particular for any company working with technology. For a well-L publicized example, look at Boeing - recently, they were trying to put theirM quality-control problems down to "sabotage" and called in the FBI on your tax  dollar to boot.    	Jan   ------------------------------    Date: 24 Jul 2001 09:51:01 -0700# From: paszty@xoma.com (Nick Paszty) * Subject: Re: Basic questions from a newbie= Message-ID: <14ce1c21.0107240851.3fe286f8@posting.google.com>   Z Didier Morandi <Didier.Morandi@gmx.ch> wrote in message news:<3B58841E.61CAEFAE@gmx.ch>... > "Richard D. Piccard" wrote:  > > L > > If this is a single-user system, OK.  But for a multi-user platform, theM > > system manager should be aware that ANALYZE/REPAIR will block all pending  > > I/O to the disk, > F > Yes it does, and better said :-) it actually write locks the disk. I > prefer TREEDEL.COM > ) > Thanks, Richard, for pointing this out.0 >  > D.  4 does anyone have treedel.com that they can email me?   thanks,s   nick   ------------------------------  # Date: Tue, 24 Jul 2001 12:48:18 GMT.8 From: hammond@not@peek.ppb.cpqcorp.net (Charlie Hammond) Subject: Re: Basic VMS Question / Message-ID: <m8e77.14$Yx2.269@news.cpqcorp.net>   / How about WAIT?  (See HELP WAIT for more info.)t  t In article <8D878D0628C2AF22.EF93CBD799203689.38DE43866729058B@lp.airnews.net>, "Hal Kuff" <kuff@tessco.com> writes: >e >n >h5 >    There is a sleep statement available in DBL ....i >u >i8 >"Andrew Robinson" <arobinson@hspg.com> wrote in messageH >news:CDA4BAD1E10ED41181AC00508B6051D3C3E2E7@grumpy.internal.hspg.com.../ >> Please could anyone help with the following:t >>H >> I have a procedure running on one of my VMS boxes which is constantlyJ >> checking a directory for a file which can be FTPed into it. If the fileL >> appears it then runs another routine to process and remove the file readyM >> for the next one. I have a simple routine at the moment written in Diaboldy$ >> which runs as a detached process.G >> The problem I have is that to make this process work, it is a simpleu >looping4 >> check, which eats CPU and slaughters the disk IO.F >> Is there anything in VMS which you can utilize which you can use to >trigger5 >> an event if a file appears in a specific location. 5 >> I using an Alpha 1200 running OVMS 7.2-1 + patchesl >> >> Thank you in advanceo >> >> Andrew Robinson >u >e >    -- MK     Charlie Hammond -- Compaq Computer Corporation -- Pompano Beach  FL USAoH        (hammond@not@peek.ppb.cpqcorp.net -- remove "@not" when replying)J       All opinions expressed are my own and not necessarily my employer's.   ------------------------------    Date: 24 Jul 2001 10:04:57 -0700# From: paszty@xoma.com (Nick Paszty)M Subject: Block Size = Message-ID: <14ce1c21.0107240904.624f9cec@posting.google.com>?   hello.  D we're running vms 7.1 on an alphaserver 800 5/333 and i am trying to/ find the amount of free disk space on a device.   C show device/full $3$DRA4 yields information on block size.  if free.E blocks value is 13,840,218 is that 13.8 gigs?  what is the block sizer in K or is it K?   thanks,i   nick   ------------------------------  + Date: Tue, 24 Jul 2001 12:09:40 -0500 (CDT)  From: sms@antinode.org Subject: Block Sizeg) Message-ID: <01072412094008@antinode.org>   # From: paszty@xoma.com (Nick Paszty)MC > show device/full $3$DRA4 yields information on block size.  [...])  D    block = 512 bytes.  (Please try not to restart the argument about# whether K or k means 1000 or 1024.)   H ------------------------------------------------------------------------  C    Steven M. Schweda               (+1) 651-699-9818  (voice, home)lC    382 South Warwick Street        (+1) 763-781-0308  (voice, work)eG    Saint Paul  MN  55105-2547      (+1) 763-781-0309  (facsimile, work) 9    sms@antinode.org                sms@provis.com  (work)    ------------------------------  % Date: Tue, 24 Jul 2001 13:12:26 -0400c2 From: "Kent, Philip  JW1811" <kent@jwfc.jfcom.mil> Subject: RE: Block SizenH Message-ID: <5B57189920E7D41190B500606D210686011A6AB3@mailsvr.jfcom.mil>  3 A block is 512 bytes.  This would be about 6.9 GBs.   	 Phil Kenta -----Original Message-----. From: paszty@xoma.com [mailto:paszty@xoma.com]$ Sent: Tuesday, July 24, 2001 1:05 PM To: Info-VAX@Mvb.Saic.Com  Subject: Block Sizem     hello.  D we're running vms 7.1 on an alphaserver 800 5/333 and i am trying to/ find the amount of free disk space on a device.o  C show device/full $3$DRA4 yields information on block size.  if freeeE blocks value is 13,840,218 is that 13.8 gigs?  what is the block size  in K or is it K?   thanks,a   nick   ------------------------------  % Date: Tue, 24 Jul 2001 13:09:01 -0400-+ From: John Eisenschmidt <jeisensc@aaas.org>u Subject: Re: Block Sizer# Message-ID: <sb5d737d.061@aaas.org>   H Under VMS, the block size is 512K. My quick rule of thumb is divide by =# two, so you have ABOUT 7 gigs free.a  ; >>> Nick Paszty <paszty@xoma.com> 07/24/2001 1:04:57 PM >>>c hello.  D we're running vms 7.1 on an alphaserver 800 5/333 and i am trying to/ find the amount of free disk space on a device.a  C show device/full $3$DRA4 yields information on block size.  if freeME blocks value is 13,840,218 is that 13.8 gigs?  what is the block size- in K or is it K?   thanks,l   nick   ------------------------------  % Date: Tue, 24 Jul 2001 10:47:10 +0200u" From: "Hans Vlems" <hvlems@iae.nl>- Subject: Re: Can a "White Alpha" box run VMS?s( Message-ID: <9jjcev$dqn$1@news.IAEhv.nl>  K It is not possible to upgrade the console firmware, the one that boots VMS?o  B D.B. Turner, islandco.com <dbturner@islandco.com> wrote in message) news:tlpkkobt5a5c06@news.supernews.com...m# > With the right Flash Eeprom - Yest > J > Now I can't say that I have done this but if you should happen to have aK > friend with the blue box version of your system - you can easily copy thenK > flash eprom on a flash burner (be careful - these are a special type thatiF > are quite hard to come by) and I can 100% guarantee it will work (in theory > of course) >  > DT >o > -- > David Turner >v > We sell Alpha's & Alpha Partsd > http://www.islandco.comn > sales@islandco.com > Island Computers US Corp.y > 2700 Gregory Street' > Savannah GA 31404n > Tel: 912 447 6622n > Fax: 912 201 0096l > . > Tom Linden <tom@kednos.com> wrote in message5 > news:CIEJLCMNHNNDLLOOGNJIKEJGDAAA.tom@kednos.com...  > > or Linux, using Milo > >   > > > -----Original Message------ > > > From: Hal Kuff [mailto:kuff@tessco.com]E) > > > Sent: Monday, July 23, 2001 4:46 AMo > > > To: Info-VAX@Mvb.Saic.Como3 > > > Subject: Re: Can a "White Alpha" box run VMS?t > > >  > > >m > > >i > > >     No... NT ROMS only > > >n3 > > > "Hans Vlems" <hvlems@iae.nl> wrote in message ( > > > news:9jgsv2$bko$1@news.IAEhv.nl...@ > > > > A friend of mine has an unused Alpha sitting on a shelf.@ > > > > It's a white box Alpha, and IIRC it was sold to run WNT.F > > > > Is it possible to boot VMS on it, and if so what modifications > > > > are needed?e > > > >c > > > > Hans Vlems > > > >  > > > >l > > >n > > >. >> >o   ------------------------------  % Date: Tue, 24 Jul 2001 16:25:04 +1000l. From: Michael Dixon <Michael_Dixon@oz.sas.com>9 Subject: Can OpenVMS 7.2 use LDAP for user authorization?i8 Message-ID: <u05qltslnatu70j79iu34idoijn7pqdis1@4ax.com>  C We have a Unix network using Netscape Directory Services (LDAP) forh? authentication. Is it possible for OpenVMS to use LDAP for user  authetication as well?   Thanks Michaele   ------------------------------    Date: 24 Jul 2001 16:40:53 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> 4 Subject: Re: Check out the Wall Street Journal todayH Message-ID: <y4bsmaqtje.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ) "Bill Todd" <billtodd@foo.mv.com> writes:o  6 > > > Ummm....  Isn't OpenVMS proprietary technology??A > > Yes, just like Tru64, Solaris, HP-UX, AIX, MacOS and Windows.o: > 'Just like'?  I think not.  Your glasses need replacing.  L You mean Microsoft will not object to the unlicensed copy of Windows runningM on my PC, or Sun doesn't mind that I resell their OS to others without askingd them for permission?   	Jan   ------------------------------    Date: 24 Jul 2001 16:42:02 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> 4 Subject: Re: Check out the Wall Street Journal todayH Message-ID: <y48zheqthh.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  4 "Sue Skonetski" <susan.skonetski@compaq.com> writes:  N > Our customers consistently say that they prefer the choice,  flexibility andN > cost-efficiency of systems based on industry-leading components, rather than > proprietary technologies.   L These marketing writers need a new dictionary. "industry-leading" is not the antonym of "proprietary".u   	Jan   ------------------------------  % Date: Tue, 24 Jul 2001 13:11:00 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com>u4 Subject: Re: Check out the Wall Street Journal today( Message-ID: <9jk9uj$8p9$1@pyrite.mv.net>  L "Jan Vorbrueggen" <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote inJ message news:y4bsmaqtje.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de...+ > "Bill Todd" <billtodd@foo.mv.com> writes:u > 8 > > > > Ummm....  Isn't OpenVMS proprietary technology??C > > > Yes, just like Tru64, Solaris, HP-UX, AIX, MacOS and Windows.r< > > 'Just like'?  I think not.  Your glasses need replacing. > F > You mean Microsoft will not object to the unlicensed copy of Windows running H > on my PC, or Sun doesn't mind that I resell their OS to others without asking > them for permission?  G I mean that VMS in no enjoys the perception of 'standardness' that UnixlI variants and Windows do.  The only entry in the list that VMS is remotelyiK like in such respects (which I believe are the respects that largely define L 'proprietary' in many minds) is MacOS.  Hence the phrase 'just like' - i.e.,? *identically to* that entire list - seems wildly inappropriate.s   - bill   >$ > Jann   ------------------------------  # Date: Tue, 24 Jul 2001 06:03:04 GMTt. From: "mulp" <michaelpettengill@earthlink.net>/ Subject: Re: Compaq FUD and lack of informationsE Message-ID: <sc877.9554$Px1.1114878@newsread2.prod.itd.earthlink.net>a  ? "Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in message - news:1eI57.1019$rc5.69027@news.cpqcorp.net...h8 > In article <3B571499.2DF74206@dplanet.ch>, John McLean <mcleanj@dplanet.ch> writes:B >   I find it intriguing that you cite various engineering-related discussionsrI >   and concerns and you make various assumptions based on these, yet youa areaH >   (very reasonably) asking largely business-related questions.  I will passE >   your questions along to the folks here in OpenVMS that handle thet businessK >   issues related to OpenVMS and OpenVMS on IPF, as these questions should K >   be answered -- various of the OpenVMS business folks have been visitingt+ >   customers, and more visits are planned.l  G Were the layoffs of the business folk aborted or was the last day for an* number the Friday before the announcement?  I My last week with access to Compaq I talked to some discouraged "businessr: folk" and that was at least six weeks before the decision.  J I suspect that the business folk are playing catchup and are just as short handed as the engineers.   ------------------------------  # Date: Tue, 24 Jul 2001 06:35:09 GMT-. From: "mulp" <michaelpettengill@earthlink.net>* Subject: Re: Compaq have committed suicideE Message-ID: <xG877.11838$Xn.1423217@newsread1.prod.itd.earthlink.net>c  > "Bill Gunshannon" <bill@triangle.cs.uofs.edu> wrote in message% news:9j9epj$ncd$2@info.cs.uofs.edu...@H > Maybe, but a search of monster.com turns up a number of PDP-11/RSX-11M: > jobs so a handfull of DEC/VAX jobs wouldn't surprise me.  F The PDP-11 jobs are for ongoing support.  The VMS jobs are largely forH porting to Solaris except for the ones that require the ability to get aJ security clearance (US govt contract).  And they are all 6 month to 2 year contracts, not full time.n   ------------------------------    Date: 24 Jul 2001 15:59:17 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> * Subject: Re: Compaq have committed suicideH Message-ID: <y4k80yqvgq.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  3 bill@triangle.cs.uofs.edu (Bill Gunshannon) writes:i  M > |> I suppose one machine was MIPS.  That has only 2 levels for kernel/user,oN > |> not the 4 used by VMS.  And the negative half of 32-bit virtual addressesI > |> has a fixed usage.  If those were the problems, they could have beenr: > |> easily fixed by some minor cooperation from Mips Inc.D > And what would have been the incentive for Mips Inc. to make these! > changes to their architecture??0  I Selling chips. They changed at least the implementation for Tandem (addednH lock-stepping) , and I remember John Mashey saying they modified several; things after receiving feedback from prospective customers.o   	Jan   ------------------------------    Date: 24 Jul 2001 16:02:06 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> * Subject: Re: Compaq have committed suicideH Message-ID: <y4hew2qvc1.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  7 "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:    > The commitment is to OpenVMS.r  H This is the crucial point. Of your commitment there is no doubt. But the: commitment of Compaq's decision makers is in severe doubt.   	Jan   ------------------------------    Date: 24 Jul 2001 13:48:38 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>sA Subject: Re: Digital industry standards (Was: A Primrose Path...)sH Message-ID: <y48zhesg2x.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  . "Michael L. Umbricht" <mikeu@osfn.org> writes:  C > I believe Digital was also instrumental in supporting the MIT X11iL > standard.  Were they the first company to offer a commercial release of X?  L They financed the development of X at MIT (jointly with IBM?). But the wholeN thing was severly lacking in software quality control, which is the reason why$ we now have this mess on our hands.   I Someone who had to port the MIT sample code to a very different system (arL transputer very definitely is _not_ a VAX) is quoted as saying that the veryI least one should do to the people who wrote the code (in a CS department)o# would be to withdraw their degrees.    	Jan   ------------------------------  % Date: Tue, 24 Jul 2001 09:21:53 -0300 ) From: fabio_compaq@ep-bc.petrobras.com.brnA Subject: Re: Digital industry standards (Was: A Primrose Path...)oL Message-ID: <OF30BEDEB0.4CB2C760-ON03256A93.0043BAA0@ep-bc.petrobras.com.br>  9 I am not a Linux fan (at least now) but I dont understand 7 why others graphical interfaces are not being ported tom: OpenVMS like their KDE, etc...  Motif itself is too heavy.   Regards-   FC          D Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> em 24/07/2001 08:48:38p  ! Favor responder a Jan Vorbrueggen 7       <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>              Info-VAX@Mvb.Saic.Come      A Assunto: Re: Digital industry standards (Was: A Primrose Path...)n    . "Michael L. Umbricht" <mikeu@osfn.org> writes:  C > I believe Digital was also instrumental in supporting the MIT X11eI > standard.  Were they the first company to offer a commercial release of  X?  F They financed the development of X at MIT (jointly with IBM?). But the wholeiJ thing was severly lacking in software quality control, which is the reason why-# we now have this mess on our hands.   I Someone who had to port the MIT sample code to a very different system (aiG transputer very definitely is _not_ a VAX) is quoted as saying that the  veryI least one should do to the people who wrote the code (in a CS department) # would be to withdraw their degrees.c        Jan   ------------------------------  % Date: Tue, 24 Jul 2001 09:37:51 -0400r# From: Jim Agnew <Agnew@hsc.vcu.edu>cA Subject: Re: Digital industry standards (Was: A Primrose Path...).+ Message-ID: <3B5D7A2E.CC1408D2@hsc.vcu.edu>   H i know.. my linux box fires up startx like it's got a warp core in it...  ) how may kilograms is motif, anyhow??? ;-)o  	 hee hee..    Jimc  * fabio_compaq@ep-bc.petrobras.com.br wrote:  ; > I am not a Linux fan (at least now) but I dont understando9 > why others graphical interfaces are not being ported toy< > OpenVMS like their KDE, etc...  Motif itself is too heavy. >-	 > Regards  >J > FC >9F > Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> em > 24/07/2001 08:48:38  >s# > Favor responder a Jan Vorbrueggen@9 >       <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>c >w >       Info-VAX@Mvb.Saic.Com6 >EC > Assunto: Re: Digital industry standards (Was: A Primrose Path...)a >n0 > "Michael L. Umbricht" <mikeu@osfn.org> writes: >tE > > I believe Digital was also instrumental in supporting the MIT X11lK > > standard.  Were they the first company to offer a commercial release ofc > X? >iH > They financed the development of X at MIT (jointly with IBM?). But the > wholesL > thing was severly lacking in software quality control, which is the reason > why % > we now have this mess on our hands.- > K > Someone who had to port the MIT sample code to a very different system (a(I > transputer very definitely is _not_ a VAX) is quoted as saying that thex > veryK > least one should do to the people who wrote the code (in a CS department)t% > would be to withdraw their degrees.. >E
 >      Jan   ------------------------------  % Date: Tue, 24 Jul 2001 10:32:46 -0400e2 From: rdeininger@mindspring.com (Robert Deininger)A Subject: Re: Digital industry standards (Was: A Primrose Path...):L Message-ID: <rdeininger-2407011032470001@user-2ive6ha.dialup.mindspring.com>  
 In articleA <OF30BEDEB0.4CB2C760-ON03256A93.0043BAA0@ep-bc.petrobras.com.br>,o* fabio_compaq@ep-bc.petrobras.com.br wrote:  ; > I am not a Linux fan (at least now) but I dont understandi9 > why others graphical interfaces are not being ported tor< > OpenVMS like their KDE, etc...  Motif itself is too heavy.  G I think Fred has mentioned KDE as a possibility.  With limited manpower.G and budgets, I guess it hasn't got to the top of the priority list yet.u  B I've never used KDE, so I can't comment on it's virtues.  Have youH requested KDE on VMS through official channels?  It will likely get done( sooner if a lot of customers ask for it.   -- o Robert Deininger rdeininger@mindspring.comM   ------------------------------  % Date: Tue, 24 Jul 2001 09:52:58 -0500u+ From: Christopher Smith <csmith@amdocs.com>aA Subject: RE: Digital industry standards (Was: A Primrose Path...)oL Message-ID: <3B55D7F383B0D31197D9009027541CBF1170DA5B@cmiexch1.cmi.itds.com>  L Yes, Motif is heavy.  There likely are other window managers that will buildH on VMS.  AFAIK FVWM used to.  I don't see why you couldn't get somethingK simple like WMX working in short order.  Or are you after something more ofn6 a "desktop environment," than just a window manager?     Regards,   Chris   ! Christopher Smith, Perl Developerf Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");v 'e      > -----Original Message-----+ > From: fabio_compaq@ep-bc.petrobras.com.brh  ; > I am not a Linux fan (at least now) but I dont understand29 > why others graphical interfaces are not being ported tou< > OpenVMS like their KDE, etc...  Motif itself is too heavy.   ------------------------------  % Date: Tue, 24 Jul 2001 08:56:52 -0400 8 From: "Island Computers US Corp" <dbturner@islandco.com>9 Subject: Re: DS20e's 667Mhz in Stock - Waiting for a home / Message-ID: <tlqrpk1n5n7h24@news.supernews.com>-   Geez    % Do I feel like a complete utter Moron-  < The warranty on these systems is good until February 24 2004   David T    ------------------------------  % Date: Tue, 24 Jul 2001 13:39:04 -0400t5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>e) Subject: Re: Full port of VMS to Itanium. / Message-ID: <ooi77.26$Yx2.399@news.cpqcorp.net>-  = JF Mezei wrote in message <3B5C76DD.CDB5218B@videotron.ca>...P >Fred Kleinsorge wrote:.G >> protocol handler.  It remains to be seen *exactly* what we will want6 added8G >> to the console, if anything.  And what we will move into the O/S (ast> >> appropriate).  We are working on these questions right now. >x >Questions:t >aF >Is "console" just some ROM chip that sits next to the CPU, or is that embedded >into the CPU ?z >     L Firmware generally resides in ROM, flash ROM, or serial ROM.  In the case ofI the IPF, the Processor Abrstaction Layer, Platform Abstraction Layer, andRL System Abstraction Layers reside in ROM.  Usually this type of thing is in a? seperate chip from the CPU chip.  The IPF console also containsnF "applications" as part of the Extensible Firmware Interface, which canJ reside in a disk partition (I haven't figured out everything about network" booting yet) dedicated to the EFI.  D >For instance, if MOP were considered essential, would the computers destinedH >to boot VMS simply be designed with a special ROM chip that allowed MOPK >booting, or would you guys have to go to Intel and beg for them to includel MOPr  >support in their architecture ? >d    G Since hardware contains Platform specific code, vendors have to providedH their own console instances anyway (although I imagine cookie-cutter OEMK designs have a common firmware image).  Some things might have to reside as B ROM resident code, some things could be loadable EFI applications.   >Also: >HI >From the information you have been given so far, have you been given any C >indication on whether Intel would be willing to modify its chip tor
 accomodateJ >VMS, or have you already been told that it is the VMS engineers that will haveJ >to implement VMS on a "vanilla" IA64 ? Or is that still something that is to
 >be decided ?E >o    G I have been given both indications.  That Intel is receptive to changesnK needed by Compaq, and that VMS plans to port on the assumption that we willy  use the IA64 architecture as-is.    K >I realise that IA64 may in the future be modified to support stuff such asb? >Wildfire style systems. But that isn't VMS specific, correct ?)  L I have no idea what things a system designer might want to change/add to the% hardware - but it isn't VMS specific.o   ------------------------------    Date: 24 Jul 2001 14:19:14 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de><( Subject: Re: Future of Alpha/VMS supportH Message-ID: <y466cisenx.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  5 malmberg@encompasserve.org (John E. Malmberg) writes:u  7 > Economics are a different issue.  Frequently an exact29 > replacement part is more costly than a newer and betterc
 > equivalent.h  L When NASA was given the money to replace Challenger, Rockwell offered them aK copy of the current shuttles for $2B, or two copies of an upgraded shuttle.v  + NASA took the former, now called Endeavour.i   	Jan   ------------------------------    Date: 24 Jul 2001 14:22:35 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> ( Subject: Re: Future of Alpha/VMS supportH Message-ID: <y43d7mseic.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  , eplan@kapsch.net (Peter LANGSTOEGER) writes:  F > With the only exception, that there where technical/economic reasonsI > to migrate from VAX to Alpha and there are now legal reasons. (from Q'ssH > point of view of course - the made a contract with INTEL where the endN > of Alpha is part of the deal) Technical reasons can change => time can slip,F > legal reasons cannot change because INTEL most likely won't agree...  K Given that Compaq and Intel made much noise about the Alpha "license" being N non-exclusive (which it couldn't be, anyway, given that Samsung and MitsubishiH already hold an architectural license) and the FTC also quite capable ofJ reading the news, Intel can make no public move to ask Compaq to desupportL Alpha systems. And Compaq will likely have contractual obligations that willD make such a move unattractive, even for the most bean-counter-minded management.    	Jan   ------------------------------  % Date: Tue, 24 Jul 2001 09:24:23 -0400h2 From: rdeininger@mindspring.com (Robert Deininger)( Subject: Re: Future of Alpha/VMS supportL Message-ID: <rdeininger-2407010924240001@user-2ive6ha.dialup.mindspring.com>  H In article <y466cisenx.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>,H Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:  7 > malmberg@encompasserve.org (John E. Malmberg) writes:t > 9 > > Economics are a different issue.  Frequently an exacts; > > replacement part is more costly than a newer and betters > > equivalent.e > N > When NASA was given the money to replace Challenger, Rockwell offered them aM > copy of the current shuttles for $2B, or two copies of an upgraded shuttle.t > - > NASA took the former, now called Endeavour.t  F But the various shuttles are not at all identical in the details.  For? example, one of them (the oldest one?) has sufficiently smallerlC payload/altitude limits that it can't do certain missions.  NASA isd$ considering putting it in mothballs.  I The 4 shuttles have parts in common, but I suspect each is treated like a , unique beast for operational considerations.  J I think there is a bit of urban legend in this 2-for-the-price-of-1 offer.   --   Robert Deininger rdeininger@mindspring.comr   ------------------------------    Date: 24 Jul 2001 12:48:48 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>n$ Subject: Re: Intel/Alpha announcmentH Message-ID: <y4y9pezjov.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ) "Bill Todd" <billtodd@foo.mv.com> writes:t  M > Leaving aside the question of whether Alpha had the potential to make majoroJ > profits for Compaq (i.e., whether with any kind of reasonable backing itJ > could have grabbed and held a lot more market share - and hence reflectsJ > incompetence from Compaq's management in their choice to drop it), VMS'sH > position in the market (and perhaps more importantly within Compaq) isL > sufficiently precarious that a significant drop in acceptance could easilyM > be enough to kill it as well (Compaq applying exactly the same logic to VMS@ > that they applied to Alpha). > H > If customers believe this is a possibility, or even believe that otherL > customers believe this is a possibility, this will - correctly - influenceN > their decisions about whether to commit their organizations' futures to VMS. > This is far from foolish.,  L And this type of thinking will of course set a vicious circle in motion that? will make such a decision by Compaq a self-fulfilling prophecy.d  N The _really_ surprising thing is that earlier decisions by DEC and Compaq haveN _not_ resulted in such a vicious circle for VMS. It remains to see how current% customers react to the new situation.h   	Jan   ------------------------------    Date: 24 Jul 2001 14:56:14 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>f2 Subject: Re: IPF already needs a face-lift for VMSH Message-ID: <y4u202qydt.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ? system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) writes:   J > What?  UR pages?  Modify the PTE to KW, invalidate the TB, write, modify% > the PTE to UR, invalidate the TB?  o  O No. KW, and have the access-violation handler notice it's meant to be URKW, ands* emulate any lesser-mode read instructions.  : > Or, double map the pages.  One mapping UR, another KW?    , Quite acceptable. Page table space is cheap.   	Jan   ------------------------------    Date: 24 Jul 2001 14:58:53 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>a2 Subject: Re: IPF already needs a face-lift for VMSH Message-ID: <y4r8v6qy9e.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  + "Neil Rieck" <n.rieck@sympatico.ca> writes:   I > We all know that this is not the case with IA-32 (make one mistake and .B > you get the blue screen of death no matter which OS is running).  F Nonsense. Don't mix Microsoft's software quality with Intel's hardwareH quality. Or do you have a specific fault of either the IA32 architectureI or any implementation thereof in mind that prohibits writing a stable OS?o   	Jan   ------------------------------  # Date: Tue, 24 Jul 2001 16:26:59 GMT = From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)u2 Subject: Re: IPF already needs a face-lift for VMS0 Message-ID: <009FF7C4.6628EABB@SendSpamHere.ORG>   In article <y4r8v6qy9e.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>, Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:, >"Neil Rieck" <n.rieck@sympatico.ca> writes: >mJ >> We all know that this is not the case with IA-32 (make one mistake and C >> you get the blue screen of death no matter which OS is running).a >tG >Nonsense. Don't mix Microsoft's software quality with Intel's hardwaretI >quality. Or do you have a specific fault of either the IA32 architectureeJ >or any implementation thereof in mind that prohibits writing a stable OS? >m >	Janc  L Intel quality?  You mean like the "perfect circle" around the "intel inside"L warning which was drawn by the Pentium processor with "small" floating point calculation discrepancies. --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: Tue, 24 Jul 2001 13:15:44 -0400o5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> C Subject: Re: IPF Console Bootstrap (was: Re: No chance for OpenVMS)i/ Message-ID: <x2i77.25$Yx2.499@news.cpqcorp.net>t  G It is unlikely that VMS will support having a single disk with multiplesJ partitions (beyond the EFI partition) to allow multiple OS types to resideG on a single spindle.  However, all my research so far would support theoG notion that you will easily be able to have a VMS disk, a Tru64 disk, aoL Linux disk, and a Windows disk all attached to the system, and bootable from; the console by simply selecting which OS partition to boot.r  ? There should be a single console (unlike ARC versus SRM) image.n  I A VMS disk will probably contain a legacy MBR record at LB 0, and containnG partition information to find the EFI partition, along with one or moreiL "dummy" partitions which cover the remainder of the disk.  The volume itselfI would be an ODS2/5 volume, with the bootblock replaced by a modified MBR,-F and a contiguous file which maps the EFI partition.  A TBD utility (orL perhaps even an ACP/XQP) would be able to read/write the FAT32 EFI partition* (which is contained in the "file" on ODS).  H The EFI console would then find the MBR, and be able to locate the FAT32G firmware partition needed to boot VMS.  While on the VMS side, the diske0 would look just like any normal VMS system disk.   _Fred   ! Hoff Hoffman wrote in message ...-J >In article <9jhvmm$tgh$1@milo.mcs.anl.gov>, "Scandora, Anthony \(35048\)" <scandora@cmt.anl.gov> writes: > H >:As an ISV, I would want to support as many customers as I could for asL >:little investment on my part as is reasonable.  If I could multi-boot someF >:collection of Windows, Linux, VMS, and Tru64 on the same developmentL >:machines, I might be more motivated to make my stuff work on VMS and Tru64L >:than I would if I had to support my own Alpha systems for my VMS and Tru64 >:products.l >eK >  I expect to have a way to bootstrap a specified disk device, among thosetL >  disks that are present on the system.  (I'll check with the engineer thatJ >  was looking at this area, as I'm not immediately aware of the specifics >  of that.) >pI >  The EFI (the IPF console) and the MBR-like stuff out on the disk is an K >  area that is quite interesting, and a subject of discussions.  (Andy and K >  I had a conversion on this area just last week.  We know what we have tocJ >  do here for the EFI MBR, and we know of at least two potentially useful >  extensions to OpenVMS here.)n >hG >  MBR: Master Boot Record, a structure that is located at disk logicaltI >  block zero, and that describes the locations of other disk structures.o >iH >  EFI reads the MBR as part of a process to locate required structures,F >  akin to the Alpha SRM console's use of the disk bootblock to locate1 >  the OpenVMS primary bootstrap image (APB.EXE).t >w' > ---------------------------- #includea' <rtfaq.h> -----------------------------yK >      For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com + > --------------------------- pure personals# opinion --------------------------- 0 >   Hoff (Stephen) Hoffman   OpenVMS Engineering hoffman#xdelta.zko.dec.com >n   ------------------------------  # Date: Tue, 24 Jul 2001 13:00:35 GMTS= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) U Subject: Re: IPF Memory management (was: Re: VMS remains secure at DEFCON hacker festi0 Message-ID: <009FF7A7.90B365CA@SendSpamHere.ORG>  Z In article <4kkpltsdcckihnvnkrbdniefbti4pvimii@4ax.com>, LBohan@dbc.spam_less..com writes:F >On Mon, 23 Jul 2001 20:00:18 GMT, hoffman@xdelta.zko.dec.nospam (Hoff >Hoffman) wrote: >hg >>In article <mVG67.6333$eY6.299639@news20.bellglobal.com>, "Neil Rieck" <n.rieck@sympatico.ca> writes: O >>:I wonder if OpenVMS systems will still be this solid once they're running onr? >>:IA-64? (with inferior memory management hardware protection)u >>9 >>  Some details of these problem(s) (via email), please?p >>P >>  Is this a reference to the lack of URKW, NA, and a few other modes expected K >>  by OpenVMS?  If so, the engineers working on memory management here in 1J >>  OpenVMS do not presently believe the (lack of) these page protections K >>  will be a constraint on the OpenVMS port to IPF.  For details on this, nM >>  please take a look at the protection key mechanism, and please also take BE >>  a look at how the page tables and even the page table design are pK >>  interestingly implemented almost entirely in the host operating system  L >>  software.  (This stuff is covered in detail in the Intel IA-64 manuals.) >>N >>  If this is a reference to something else, then I would definitely be quiteF >>  interested in (email with) any available details and any pointers. >>P >> ---------------------------- #include <rtfaq.h> -----------------------------P >>      For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    P >> --------------------------- pure personal opinion ---------------------------N >>   Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com > 5 >Do the mem mgmt folks forsee making "improvements"  eA >(ie, copy-on-write),  or would that be too risky, given the timed9 >frames involved.    (just asking out of curiousity ...) 9  A Improvements?  As long as they are not "compromises" in disguise..  J If I load (for example) an execlet, I fully expect that its non-paged dataK image section be writeable *only* from kernel mode and readable from/in all $ modes.  There can be no compromises.       --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM             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, 24 Jul 2001 10:27:31 -0400 2 From: rdeininger@mindspring.com (Robert Deininger)V Subject: Re: LG06 Line Printer; Manual?; Vibrates with SHTL error when printing startsL Message-ID: <rdeininger-2407011027310001@user-2ive6ha.dialup.mindspring.com>  = In article <797d2369.0107231528.7b368af5@posting.google.com>,S4 mjnews@wildernesscomputing.com (Matt Jenkins) wrote:  H > We have an LG06 line printer in one of our buildings.  It was recently= > moved and I suspect may have gotten "bumped" by the movers.  > D > When I begin printing on it the printer vibrates and I believe the > error code it gave was SHTL. >  > Any ideas what this means?  = I don't know this printer.  I'm just offering a wild guess...e  @ Maybe the "L" stands for "luck", and the preceeding "out of" wasD suppressed because both words begin with vowels.  (There is a severe; shortage of vowels where these error messages are created.)   J This interpretatation is consistent with my experience.  Printers often do/ not survive the tender ministrations of movers.t  ! I hope you have a happier ending.a   -- i Robert Deininger rdeininger@mindspring.como   ------------------------------  % Date: Tue, 24 Jul 2001 10:35:35 -0700 . From: Hank Vander Waal <hvanderw@novagate.com>U Subject: RE: LG06 Line Printer; Manual?; Vibrates with SHTL error when printingstartso; Message-ID: <000801c11467$0c3fa850$9c96a8c6@manufact5l8vs8>y  9 it means there is a problem with the shuttle (print head)tI check to see if something is blocking it or is either too close or to farn away from the paper    -----Original Message-----9 From: Robert Deininger [mailto:rdeininger@mindspring.com]'$ Sent: Tuesday, July 24, 2001 7:28 AM To: Info-VAX@Mvb.Saic.Com F Subject: Re: LG06 Line Printer; Manual?; Vibrates with SHTL error when printing startsd    = In article <797d2369.0107231528.7b368af5@posting.google.com>,w4 mjnews@wildernesscomputing.com (Matt Jenkins) wrote:  H > We have an LG06 line printer in one of our buildings.  It was recently= > moved and I suspect may have gotten "bumped" by the movers.e > D > When I begin printing on it the printer vibrates and I believe the > error code it gave was SHTL. >  > Any ideas what this means?  = I don't know this printer.  I'm just offering a wild guess...   @ Maybe the "L" stands for "luck", and the preceeding "out of" wasD suppressed because both words begin with vowels.  (There is a severe; shortage of vowels where these error messages are created.)   J This interpretatation is consistent with my experience.  Printers often do/ not survive the tender ministrations of movers.   ! I hope you have a happier ending.    -- Robert Deininger rdeininger@mindspring.como   ------------------------------  % Date: Tue, 24 Jul 2001 09:31:20 -0400a2 From: rdeininger@mindspring.com (Robert Deininger)+ Subject: Re: LPs on the Web (Was: Re: DCPS) L Message-ID: <rdeininger-2407010931200001@user-2ive6ha.dialup.mindspring.com>  ; In article <3B5CD91D.53DA6FAD@fsi.net>, "David J. Dachtera"d <djesys.nospam@fsi.net> wrote:   > Robert Deininger wrote:t
 > > [snip]M > > If Rich Marcello could discover the MORON at Compaq who's responsible forl > > this kind of pricing, ...  > H > Careful, there! That may be part of Richard's job - and we don't wanna > piss *HIM* off now, do we?  I If he happens to be the one responsible for keeping these prices so high,m2 then somebody needs to get his attention, somehow.   -- n Robert Deininger rdeininger@mindspring.comx   ------------------------------    Date: 24 Jul 2001 10:37:50 -0700  From: alanb@cloud9.net (Alan B.) Subject: Migration from VMSe= Message-ID: <88599d89.0107240937.4d08b858@posting.google.com>B  E Just for giggles, check the job postings using the VMS keyword on anylC of the common job search sites. There seems to always be at least aJE few containing the "VMS" string, where they are migrating FROM VMS toaD either NT and/or Unix. I have not seen any where the migration is TOF VMS. This is somewhat discouraging. Compaq does not seem to be able toC control the damage done by DEC in the 90's, and even after the "VMSeB revival" of the past year or two which was encouraging, the recentC Alpha>Itanium "Black Monday" news surely put a damper on VMS in thefE minds of many people. This is not to say that having VMS on Intel maypD be bad in the long-term in several aspects, but for the short-term IA believe does not give IT managers and CIO's a warm, fuzzy feelinge
 about VMS.    Alan B.   ------------------------------  % Date: Tue, 24 Jul 2001 14:47:42 -0300 ) From: fabio_compaq@ep-bc.petrobras.com.bra Subject: Re: Migration from VMSdL Message-ID: <OFA61131BD.00181503-ON03256A93.0061A423@ep-bc.petrobras.com.br>  9 I  read that  ABB is not planning to use Alphas anymore !l6 Is it true abroad ? Was a news from ABB Brazil........   Regardsa   FC        1 alanb@cloud9.net (Alan B.) em 24/07/2001 14:37:50n  , Favor responder a alanb@cloud9.net (Alan B.)             Info-VAX@Mvb.Saic.Com        Assunto: Migration from VMSi    E Just for giggles, check the job postings using the VMS keyword on anysC of the common job search sites. There seems to always be at least amE few containing the "VMS" string, where they are migrating FROM VMS touD either NT and/or Unix. I have not seen any where the migration is TOF VMS. This is somewhat discouraging. Compaq does not seem to be able toC control the damage done by DEC in the 90's, and even after the "VMSxB revival" of the past year or two which was encouraging, the recentC Alpha>Itanium "Black Monday" news surely put a damper on VMS in thelE minds of many people. This is not to say that having VMS on Intel may D be bad in the long-term in several aspects, but for the short-term IA believe does not give IT managers and CIO's a warm, fuzzy feelingn
 about VMS.    Alan B.   ------------------------------    Date: 24 Jul 2001 12:35:41 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>s Subject: Re: MinimergeH Message-ID: <y41yn61uo2.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  * kparris@my-deja.com (Keith Parris) writes:  A > A Shadowing Full Copy occurs when you add a disk to an existingtF > shadowset using a MOUNT command; the entire contents of the disk areD > effectively copied to the new member (using an algorithm that goesE > through in 127-block increments and reads one member, compares with.B > the target disk, and if the data differs, writes the data to theF > target disk and loops back to the read step, until the data is equal > for that 127-block section).  L What is the rationale for going through these shenanigans (as you later callM them) for a full copy (and not for a mini-copy)? Why not just copy the sourcea to the target in one go?   	Jan   ------------------------------  % Date: Tue, 24 Jul 2001 09:19:35 -0400t2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: MinimergeL Message-ID: <rdeininger-2407010919350001@user-2ive6ha.dialup.mindspring.com>  H In article <y41yn61uo2.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>,H Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:  , > kparris@my-deja.com (Keith Parris) writes: > C > > A Shadowing Full Copy occurs when you add a disk to an existinglH > > shadowset using a MOUNT command; the entire contents of the disk areF > > effectively copied to the new member (using an algorithm that goesG > > through in 127-block increments and reads one member, compares withlD > > the target disk, and if the data differs, writes the data to theH > > target disk and loops back to the read step, until the data is equal  > > for that 127-block section). > N > What is the rationale for going through these shenanigans (as you later callO > them) for a full copy (and not for a mini-copy)? Why not just copy the sourcer > to the target in one go?  J Perhaps it is done without write-locking that section of the disk.  If theG source disk gets written while the copy is in progress, a section mighthI not match after it is written to the target and read back.  Then a re-try C is likely to solve the problem.  Faulty disks would also cause dataT2 mismatches, but that is probably much less common.  H It might be that copying in chunks, with no write-locking and occasionalI retries, makes less performance impact than locking a section and copyingpF it once.  (Is there even a mechanism in place to write-lock a range ofI blocks on a disk?)  Certainly, you wouldn't want to lock the disk for thel% duration of the whole copy operation.g  I I haven't seen the actual algorithms; I just tossing up a possibility fora folks to swat at.t   -- S Robert Deininger rdeininger@mindspring.comn   ------------------------------  $ Date: Tuesday, 24 JUL 2001 02:43 EDT From: bjj@arlvax.arl.psu.edu6 Subject: Re: Need help with rsh from Sun to OpenVMS...+ Message-ID: <9jj63n$l3c@r02n01.cac.psu.edu>h  * In article <3B58C083.5C303DE@bigfoot.com>,-    Hamlyn Mootoo <univms@bigfoot.com> writes:u >t >"Helmuth,Paul" wrote: >> fH >> All I am trying to do is run an "rsh" (remote shell) process on a SunI >> Unix box to run a com proc in the vms users home directory that runs a-K >> program which will read <stdin> from the unix process and write <stdout>B >> back to the Unix process. >> jJ >> program running on the VMS side that is reading "stdin" doesn't see the >> input from unix.  >n$ >I don't belive it is supposed to.    I Of course it's supposed to -- but not every client or server will do whatkK it's supposed to do.  UCX in particular has varied from release to release.m  - I tried this from Sun to VMS and it did work:A    	% rsh vmsnode 'create test.tmp' 	Test.  F There were glitches - like no way to terminate rsh - but it did createF the file, which unfortunately had a linefeed at the end of each record* making rsh input a pretty useless feature.   ------------------------------  % Date: Tue, 24 Jul 2001 10:41:39 -0500t: From: "Scandora, Anthony \(35048\)" <scandora@cmt.anl.gov>" Subject: Re: No chance for OpenVMS+ Message-ID: <9jk4vm$5fd$1@milo.mcs.anl.gov>P  9 "mulp" <michaelpettengill@earthlink.net> wrote in messagec? news:5e577.11323$Xn.1346699@newsread1.prod.itd.earthlink.net...1E > "Scandora, Anthony (35048)" <scandora@cmt.anl.gov> wrote in messagee' > news:9jhvmm$tgh$1@milo.mcs.anl.gov... L > > > Correction "A future Itanium might" or even "A future Itanium should";K > > > this is in a future with far too many unknowns at this point in time.0 > >rK > > Academic articles have claimed EPIC to have the potential to outperformeK > > RISC.  If a resonable EPIC chip and compilers can do what the academicse > say,J > > VMS, Tru64, and NSK will have an advantage over Solaris and AIX.  I doK > > respect the combined resources of Intel, HP, and Compaq.  Remember RISC G > > being denounced because it could never surpass the power of the VAXrG > > architecture?  And if EPIC crashes and burns, Compaq will still owni Alpha. >uG > I don't recall anyone claiming that RISC couldn't match or exceed VAX E > performance.  The major issue was whether there would be sufficienthE > resources to make VMS and VMS apps perform as well as the same appsw > performed on VAX.a  J And the answer was the people who gave us VAX VMS and its layered productsI are far too talented to be limited by what they're already good at.  TheymK made Alpha VMS a success, and I expect them to keep making VMS work well ono2 whatever is the hardware architecture of the time.  I > Bob Supnik justified switching to RISC because it would deliver a given/L > level of performance in a given technology 1-2 years earlier than it couldK > be done with a CISC implementation.  The primary reason was that RISC waseI > relatively easier to implement.  He didn't argue that you couldn't keepV% > making faster CISC implementations.e >yD > IA64 is more complex than Alpha, plus it includes an IA32 core for > compatibility.  D I haven't studied it carefully -- I let compiler writers worry aboutL architectural details, but my recollection is that unlike AMD's Hammer, IA64K does not run IA32 binaries without software emulation.  This will be a longc@ transition period for IA32 applications running on Pentium 4 and) incompatibilty mode via software on IA64.i  > > To me this says that IPF chips will deliver a given level ofH > CISC performance at least 1-2 years later than the CISC implementation used,cF > and it will likely deliver EPIC performance 1-2 years later than the! > comparible RISC implementation.r >n" > ... VMS customers value a lot ofI > things more than performance; the lack of performance relative to unix, H > either tru64 or linux, has not prevented people from continuing to buy VMS.  K Which I read as even if the first production VMS on IA64 is not faster thantK VMS on EV8, raw speed won't be the top priority for VMS customers, who willeJ be able to run their applications on Compaq, and for the first time, other vendors' hardware.  F > If IA64 doesn't make it in the market place, VMS will be in the same > position as VMS on Alpha.   J What's to stop it from making it in the marketplace?  Microsoft needs a 64L bit platform.  So does Linux.  When Merced's original schedule was forced toJ face reality, HP put PA on life support, but HP/UX owns more of the marketI than Tru64, and it will move to IA64, which HP helped design.  Now Compaq-H will be able to put what VMS, Tru64, and NSK need into IA64.  Microsoft,J Linux, HP, and Intel have substantial coat tails.  Compaq might as well go along for the ride.-  1 Tony Scandora, Argonne National Lab, 630-252-7541- scandora@cmt.anl.gov   ------------------------------  % Date: Tue, 24 Jul 2001 13:20:14 -0400-' From: "Bill Todd" <billtodd@foo.mv.com>," Subject: Re: No chance for OpenVMS( Message-ID: <9jkag0$93o$1@pyrite.mv.net>  C "Scandora, Anthony (35048)" <scandora@cmt.anl.gov> wrote in messages% news:9jk4vm$5fd$1@milo.mcs.anl.gov...D >0; > "mulp" <michaelpettengill@earthlink.net> wrote in messageiA > news:5e577.11323$Xn.1346699@newsread1.prod.itd.earthlink.net...    ...,  H > > If IA64 doesn't make it in the market place, VMS will be in the same > > position as VMS on Alpha.3 >e6 > What's to stop it from making it in the marketplace?  L At least some of the same things that stopped iAPX-432 from making it in the@ marketplace:  complexity and inferior performance, for starters.     Microsoft needs a 64 > bit platform.  So does Linux.b  ? They both had a really good one until Compaq screwed things up.c  /   When Merced's original schedule was forced to L > face reality, HP put PA on life support, but HP/UX owns more of the marketK > than Tru64, and it will move to IA64, which HP helped design.  Now CompaqiJ > will be able to put what VMS, Tru64, and NSK need into IA64.  Microsoft,3 > Linux, HP, and Intel have substantial coat tails.n  K And both of the first two were riding on Alpha long before IA64 entered the  picture.     Compaq might as well gon > along for the ride.t  H Would you junk a great car just because someone offered you a ride in anL inferior one?  Me, I'd accept the ride *and* keep the original (and not only( because the free ride might break down).   - bill   >a3 > Tony Scandora, Argonne National Lab, 630-252-7541  > scandora@cmt.anl.gov >- >    ------------------------------  % Date: Tue, 24 Jul 2001 10:13:25 -0400l2 From: rdeininger@mindspring.com (Robert Deininger)H Subject: Re: Now we're cooking with gas. (was:  Wailing and moaning....)L Message-ID: <rdeininger-2407011013250001@user-2ive6ha.dialup.mindspring.com>  J In article <9jhvcm$agc$1@pyrite.mv.net>, "Bill Todd" <billtodd@foo.mv.com> wrote:  A > "Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in messagev/ > news:tL_67.1120$rc5.73614@news.cpqcorp.net...m> > > In article <3B5C65CD.DA57978C@uk.sun.com>, andrew harrison$ > <andrew.nospam@uk.sun.com> writes: >   I > Unfortunately, I've seen at least equally unequivocal statements to thekN > contrary from senior Alpha engineers and I find it difficult to believe thatN > you know as much about the technical aspects of chip performance as they do.K > So I'm left with the conclusion that any inability of Alpha to retain and L > even increase its performance lead over IA64 was not a technical issue butL > the result of some business decision - which is not inconsistent with whatN > you state above, but hardly the impression that your statement appears to be > trying to convey.a  G Bill, I think you have jumped on the "technical" aspect of future alphaeF performance in a number of posts in recent weeks.  I haven't noted anyD Compaq posters claiming the limitations were technical.  One post inF particular, in another group, started a firestorm when the poster saidH something like "no further alpha improvements will be possible".  When IH read that post, I did NOT think he was speaking technically, but clearlyJ almost everyone participating in the firestorm did think so.  The originalJ poster was slapped around for several days, and never came back to clarifyH as far as I know.  He was probably scared off, and I can't blame him.  AH sentence or two from his post started an inquisition, including personal& insults and verbal fingernail-pulling.  J When you wrote "the impression that your statement appears to be trying toH convey", I wonder if you shouldn't have written "the impression that I'MF trying to make your statement convey"?  Hoff appears to seem to try toC write fairly precisely; is it wise to read between the lines of his C posts?  And then respond in detail to that between-the-lines stuff?   C I suppose this will earn me another "ostrich" label.  Are ostrichespI usually cooked with gas?  I just want to know what's in store for me.  Ory am I extrapolating again...e   -- t Robert Deininger rdeininger@mindspring.come   ------------------------------    Date: 24 Jul 2001 08:17:41 -0700  From: nclews@csc.com (Nic Clews)H Subject: Re: Now we're cooking with gas. (was:  Wailing and moaning....)< Message-ID: <a720d610.0107240717.bc4c6a4@posting.google.com>  3 "Bill Todd" <billtodd@foo.mv.com> wrote in message rI > Unfortunately, I've seen at least equally unequivocal statements to thesN > contrary from senior Alpha engineers and I find it difficult to believe thatN > you know as much about the technical aspects of chip performance as they do.K > So I'm left with the conclusion that any inability of Alpha to retain andtL > even increase its performance lead over IA64 was not a technical issue butL > the result of some business decision - which is not inconsistent with whatN > you state above, but hardly the impression that your statement appears to be > trying to convey.s  D I have spent some time trying to understand the IA-64 and compare it	 to Alpha.e  D My current understanding, and I'm prefectly prepared to be correctedB here, is that while Alpha EVx9 is (will be) a nine way instructionE issue chip, the current or near future Itanium chip is a 4 way (4 way  scalar) instruction issue.  B However one major difference is that the Itanium is designed to be@ scalar up to 'n', so in theory 4, 8, 12, 16, whatever, should beF possible for multiple (albeit inline / parallel) instruction issue per clock cycle.  F OK, so maybe if Alpha carried on and we got an EV812 lets say, Itanium@ could be competing out there supporting 16 or 32 way instruction issue, or more.i  F This topic is probably better in comp.arch groups however, but this isD my (laymans) understanding. If I'm wrong, tell me, and of course I'mB talking about things that aren't available, but I'm using a littleF 'educated' imagination. However if this is the case, the arguments for@ stopping Alpha development and moving to Itanium become clearer.  ( Regards, Nic Clews CSC Computer Sciences nclews at csc dot comn   ------------------------------  % Date: Tue, 24 Jul 2001 14:03:21 -04000' From: "Bill Todd" <billtodd@foo.mv.com> H Subject: Re: Now we're cooking with gas. (was:  Wailing and moaning....)( Message-ID: <9jkd0p$b0k$1@pyrite.mv.net>  - "Nic Clews" <nclews@csc.com> wrote in messagel6 news:a720d610.0107240717.bc4c6a4@posting.google.com...4 > "Bill Todd" <billtodd@foo.mv.com> wrote in messageK > > Unfortunately, I've seen at least equally unequivocal statements to thewK > > contrary from senior Alpha engineers and I find it difficult to believe  thatL > > you know as much about the technical aspects of chip performance as they do. I > > So I'm left with the conclusion that any inability of Alpha to retaint and J > > even increase its performance lead over IA64 was not a technical issue butsI > > the result of some business decision - which is not inconsistent withv whatJ > > you state above, but hardly the impression that your statement appears to bem > > trying to convey.  >.F > I have spent some time trying to understand the IA-64 and compare it > to Alpha.0 > F > My current understanding, and I'm prefectly prepared to be correctedD > here, is that while Alpha EVx9 is (will be) a nine way instructionG > issue chip, the current or near future Itanium chip is a 4 way (4 wayl > scalar) instruction issue. >fD > However one major difference is that the Itanium is designed to beB > scalar up to 'n', so in theory 4, 8, 12, 16, whatever, should beH > possible for multiple (albeit inline / parallel) instruction issue per > clock cycle. >fH > OK, so maybe if Alpha carried on and we got an EV812 lets say, ItaniumB > could be competing out there supporting 16 or 32 way instruction > issue, or more.s >nH > This topic is probably better in comp.arch groups however, but this isF > my (laymans) understanding. If I'm wrong, tell me, and of course I'mD > talking about things that aren't available, but I'm using a littleH > 'educated' imagination. However if this is the case, the arguments forB > stopping Alpha development and moving to Itanium become clearer.  K I'm in no position to tell you you're wrong:  I'm no hardware engineer, and C my main sources of information about the relative merits of Alpha's J technology vs. EPIC's are Paul DeMone's articles at realworldtech.com (andI his occasional posts in comp.arch) and the infamous 1999 Compaq technical  comparsion .pdf.  G But I'll question why you believe you understand the situation anywhereuD nearly as well as those sources and most especially the senior AlphaH engineers who are stating (as I said, unequivocally) that maintaining orL increasing Alpha's performance lead for the foreseeable future was eminently	 feasible.h  F It's easy to say "What if...?".  But lacking supporting data it reallyL doesn't carry any weight, whereas the sources I'm basing my understanding on do.o  E If you point to increased IA64 instruction-issue width as a potentialdL catcher-upper, I'll point to the rapidly decreasing gains that this providesJ (unless integrated with an SMT mechanism such as EV8's) due to the limitedH instruction-level parallelism of most sequential processes (and Amdahl'sG law), and to the fact that in high-end *server* installations (the mainsL market at which both beasts are likely aimed) multi-thread parallelism seemsL a far more cost-effective course to follow (and that adding SMT to somethingI already as complex as EPIC will not happen overnight and *still* wouldn't08 leverage the synergies between SMT and OOO as EV8 does).  H But I suspect we're both talking about areas we're far less competent to3 judge than people like Alpha's designers (or Paul).:   - bill   >y* > Regards, Nic Clews CSC Computer Sciences > nclews at csc dot coms   ------------------------------    Date: 24 Jul 2001 14:41:57 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>eK Subject: Re: OpenVMS on IPF (was re: IPF already needs a face-lift for VMS)nH Message-ID: <y4zo9uqz1m.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ? system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-) writes:h  K > >Sure.  They range from making them system calls (not highly favored), tohG > >using an instruction that will trap (pehaps a reserved opcode, maybelI > >something like "break").  Some things might be possible as inline codesM > >sequences, depending on if the failure semantics can be correctly handled.t > Yuch, yuch, yuch!s  M For all practical purposes, the interlocked VAX instructions, being mapped tohL PAL calls on Alpha, already are emulation traps. All the hardware does is toO make this emulation more efficient (for instance with regard to trap overhead).sH The question is whether IA64 has opcode space available for the purpose.   	Jan   ------------------------------    Date: 24 Jul 2001 14:48:37 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>aK Subject: Re: OpenVMS on IPF (was re: IPF already needs a face-lift for VMS)uH Message-ID: <y4wv4yqyqi.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  4 hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes:  L >   The internal implementation of the TDF and of time-keeping would be one L >   such area -- I'd like to provide a central time-keeping kernel-mode API,H >   switch to UTC for all internal operations, keep a per-process and a I >   system-wide TDF, while (of course) continuing to present the classic  L >   VAX environment for all existing user-mode calls to $bintim and similar  >   calls.    K I have always considered this to be one of the few areas where VMS was, andoK still is, much weaker than its competitors. Even Unix does much better thanmM base VMS. Allocating 64 bits for a time value was far-sighted; not making theeL distinction between internal time and external/presentation time was myopic,J IMO. Look at what the hacks required for daylight savings time and similarE exercises (e.g., simple clock adjustments) have caused in problems in M particular for the DECnet code over the years - the amount of effort requirednM for that likely cost an order of magnitude or so more than a concerted effortSE in the, say, V4 timeframe would have cost. (IIRC, because of this the K _semantics_ of delta-time TQEs when doing a SET TIME flip-flopped at least h once!)  N Was there a specific reason this change wasn't at least put on the map for the Alpha port?    	Jan   ------------------------------  % Date: Tue, 24 Jul 2001 09:27:44 -0400S2 From: rdeininger@mindspring.com (Robert Deininger)K Subject: Re: OpenVMS on IPF (was re: IPF already needs a face-lift for VMS)vL Message-ID: <rdeininger-2407010927440001@user-2ive6ha.dialup.mindspring.com>  H In article <y4zo9uqz1m.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>,H Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:  O > For all practical purposes, the interlocked VAX instructions, being mapped touN > PAL calls on Alpha, already are emulation traps. All the hardware does is toF > make this emulation more efficient (for instance with regard to trap
 overhead).  G Reading the alpha docs, it seems to me that these PALcode traps are not ? all that efficient.  They may be ok compared to VAX interlockedeG instructions, but they are terrible compared to straight-line, non-PAL,, alpha instuction sequences.S   --   Robert Deininger rdeininger@mindspring.coms   ------------------------------  % Date: Tue, 24 Jul 2001 08:44:55 -0330o) From: fabio_compaq@ep-bc.petrobras.com.br / Subject: Oracle Magazine: Where is Oracle RDB ?rL Message-ID: <OF6E508420.C5098557-ON03256A93.00406981@ep-bc.petrobras.com.br>  7 I received  the Oracle Magazine and again serarched forl1 some  information about Oracle RDB: Where is it ?   7 Oracle RDB is really dead and nobody told us: customersr   Regards    FC   ------------------------------    Date: 24 Jul 2001 16:46:09 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de> + Subject: Re: Penance for Compaq's VMS sins?tH Message-ID: <y466ciqtam.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ' Alan Greig <a.greig@virgin.net> writes:   A > REPLACEMENT INVOLVES AN NT BOX FRONT-ENDING YOUR VMS SYSTEM ANDl" > COMMUNICATING OVER THE INTERNET.  $ This is pure technical incompetence.   	Jan   ------------------------------  # Date: Tue, 24 Jul 2001 06:01:20 GMTt4 From: "Terry C. Shannon" <terryshannon@mediaone.net># Subject: Re: Process adopts Itaniumt= Message-ID: <Qa877.18117$N21.5973952@typhoon.ne.mediaone.net>i  9 "mulp" <michaelpettengill@earthlink.net> wrote in messagei? news:%s677.11493$Xn.1379097@newsread1.prod.itd.earthlink.net...o4 > "Alan Greig" <a.greig@virgin.net> wrote in message4 > news:susnlt4m1cij8k13uv7mirtic9ijl1dq70@4ax.com...G > > Richard also presented some slides of what the 2004 servers will beII > > like. They showed one system running NT, Tru64 (or was it Linux?) andrI > > VMS in partitions. So in four years time Compaq will start selling anEI > > Intel based server which can do what was first demonstrated in publicr$ > > about two years ago on an Alpha. > ? > This was demonstrated more like 4-5 years ago on a tlaser....t >n  4 Yeah, the last Fall DECUS symposium in Anaheim IIRC.  F I guess it makes sense that if you can hard-partition a TLaser you can2 partition an Infiniband-based ICE or FIRE machine.  I Herewith is the verbiage accompanying the  Customer benefits - Datacentert view:p Investment optimizationfL Only purchase the pieces needed for a given customer solution (give example)> No "extra" slots/bays included (taking up valuable rack space)$ More efficient use of the datacenter Datacenter flexibility, Partitioning (and repartitioning) of systems Premium = dynamic partitions1 Multi-host = sharing and/or fail over of adaptersn# Load balancing within the partition  Routing between islandsn Easy to grow, re-deployh, Simplified console-based solution deployment Separate HW/SW deployment tasksK- Maximize value of personality migration (Ice)t Growth = add to partitioni Resource managementwG Manage pools of resources across the datacenter (capacity, performance)2@ Dynamic provisioning (reach threshold, auto-order more capacity)   ------------------------------  # Date: Tue, 24 Jul 2001 14:17:27 GMT.  From: jlsue <jlsuexxxz@home.com>- Subject: Re: Selling VMS to another company ?.8 Message-ID: <q8vqltos4gnruftne1enbp8p9h5sprqrem@4ax.com>  0 There are other things to consider here as well:  / 1.  Business is down for many (most?) companiese< 2.  Compaq has *two* high-end server groups:  One working onE Alphaserver systems, and one working on Intel/AMD systems.  Ever lookeE at the details of the Proliant 8500 architecture?  It has an internal D switched bus... but it doesn't use switch technology we own.  HavingE two completely different "systems" engineering groups has got to be aa drain on resources.y  F I see one huge benefit of the IA64-based VMS/Tru64/NSK systems is thatD we will probably end up with one consolidated group working togetherB to engineer the best high-end servers.  Combining them should help- make Compaq much more competitive/profitable.p  , On Mon, 23 Jul 2001 13:49:50 -0400, JF Mezei% <jfmezei.spamnot@videotron.ca> wrote:P   >Burnie M wrote:Q >> >The killing of Alpha is simply a corporate decision by Compaq because this is,1 >> >not where Compaq wants to go in its strategy.s >>  + >> Exactly where does Compaqs strategy go ?aI >> Anybody from Compaq ? or are you guys/gals as much in the dark as us ?l >  > I >Compaq did state some time ago that they would move to industry standard H >hardware. Shortly after than, they started to call their wintel serversC >"industry standard", meaning that Alpha was not industry standard.  > K >Their past financial statements indicated that they beleived that NT would  >rule the enterprise.- >-H >The TV ad campaign that was designed to portray Compaq as an enterpriseL >company featured Proliant servers. (granted, that was 2 seconds on an alphaH >mainframe shown, but most would think it is another big wintel server). >iL >Compaq's killing of Alpha was designed to cut costs and put everything intoJ >one industry standard chip. (yeah, as if Compaq is going to drop the 8086 >anytime soon).e > L >In hindsight, Compaq has sent lots of messages that anything non-wintel wasL >not considered a strategic/core product. Doesn't mean that Compaq will killN >anything that isn't industry standard, but it certaintly leads one to beleiveL >that Compaq won't be pushing those "weird" platforms such as Alpha and VMS.   ------------------------------  # Date: Tue, 24 Jul 2001 16:19:00 GMTn4 From: "Terry C. Shannon" <terryshannon@mediaone.net>- Subject: Re: Selling VMS to another company ?i= Message-ID: <Udh77.18964$N21.6243620@typhoon.ne.mediaone.net>e  - "jlsue" <jlsuexxxz@home.com> wrote in messagei2 news:q8vqltos4gnruftne1enbp8p9h5sprqrem@4ax.com...2 > There are other things to consider here as well: >t1 > 1.  Business is down for many (most?) companiese> > 2.  Compaq has *two* high-end server groups:  One working onG > Alphaserver systems, and one working on Intel/AMD systems.  Ever looksG > at the details of the Proliant 8500 architecture?  It has an internaloF > switched bus... but it doesn't use switch technology we own.  HavingG > two completely different "systems" engineering groups has got to be a  > drain on resources.e >nH > I see one huge benefit of the IA64-based VMS/Tru64/NSK systems is thatF > we will probably end up with one consolidated group working togetherD > to engineer the best high-end servers.  Combining them should help/ > make Compaq much more competitive/profitable.    Yup.  Stay tuned...e   ------------------------------  % Date: Tue, 24 Jul 2001 13:38:15 -0300.) From: fabio_compaq@ep-bc.petrobras.com.brr- Subject: Re: Selling VMS to another company ?wL Message-ID: <OFC0221FD4.97C7325D-ON03256A93.005B50E7@ep-bc.petrobras.com.br>  K Stay Tuned .... it  means ... let's sleep waiting for the princess kiss ! !  !i   May be some day !n   Regardso   FC        E "Terry C. Shannon" <terryshannon@mediaone.net> em 24/07/2001 13:19:00p  @ Favor responder a "Terry C. Shannon" <terryshannon@mediaone.net>             Info-VAX@Mvb.Saic.Como      - Assunto: Re: Selling VMS to another company ?g      - "jlsue" <jlsuexxxz@home.com> wrote in messages2 news:q8vqltos4gnruftne1enbp8p9h5sprqrem@4ax.com...2 > There are other things to consider here as well: > 1 > 1.  Business is down for many (most?) companiesa> > 2.  Compaq has *two* high-end server groups:  One working onG > Alphaserver systems, and one working on Intel/AMD systems.  Ever lookmG > at the details of the Proliant 8500 architecture?  It has an internalnF > switched bus... but it doesn't use switch technology we own.  HavingG > two completely different "systems" engineering groups has got to be ap > drain on resources.. > H > I see one huge benefit of the IA64-based VMS/Tru64/NSK systems is thatF > we will probably end up with one consolidated group working togetherD > to engineer the best high-end servers.  Combining them should help/ > make Compaq much more competitive/profitable.    Yup.  Stay tuned...a   ------------------------------  # Date: Tue, 24 Jul 2001 17:20:49 GMTn4 From: "Terry C. Shannon" <terryshannon@mediaone.net>- Subject: Re: Selling VMS to another company ?r= Message-ID: <R7i77.18997$N21.6271044@typhoon.ne.mediaone.net>   J The BCSG and ISSG no longer are separated by architectural instruction setI issues. The ISSG already has one IPF platform; 4 and 8-way McKinley boxesrC will come out sometime next year followed by a 32-way McKinley box.h  H The ISSG works quite closely with Intel and has plenty of expertise with high volume platforms.  H Given the architectural consolidation and Compaq's continuing efforts toL reduce structural expenses, a consolidation of the ISSG and BCSG makes sense to me.  6 <fabio_compaq@ep-bc.petrobras.com.br> wrote in messageF news:OFC0221FD4.97C7325D-ON03256A93.005B50E7@ep-bc.petrobras.com.br...K > Stay Tuned .... it  means ... let's sleep waiting for the princess kiss !e !u > !  >n > May be some day !' >a	 > Regardso >e > FC >  >t >c >,G > "Terry C. Shannon" <terryshannon@mediaone.net> em 24/07/2001 13:19:00m >lB > Favor responder a "Terry C. Shannon" <terryshannon@mediaone.net> >o >  >- >       Info-VAX@Mvb.Saic.Com  >e >u >2/ > Assunto: Re: Selling VMS to another company ?l >d >o >v/ > "jlsue" <jlsuexxxz@home.com> wrote in message(4 > news:q8vqltos4gnruftne1enbp8p9h5sprqrem@4ax.com...4 > > There are other things to consider here as well: > > 3 > > 1.  Business is down for many (most?) companieso@ > > 2.  Compaq has *two* high-end server groups:  One working onI > > Alphaserver systems, and one working on Intel/AMD systems.  Ever lookwI > > at the details of the Proliant 8500 architecture?  It has an internalvH > > switched bus... but it doesn't use switch technology we own.  HavingI > > two completely different "systems" engineering groups has got to be ao > > drain on resources.  > >vJ > > I see one huge benefit of the IA64-based VMS/Tru64/NSK systems is thatH > > we will probably end up with one consolidated group working togetherF > > to engineer the best high-end servers.  Combining them should help1 > > make Compaq much more competitive/profitable.  >e > Yup.  Stay tuned...  >u >r >n >h >A >  >  >p   ------------------------------  % Date: Tue, 24 Jul 2001 19:45:53 +0200p& From: John McLean <mcleanj@dplanet.ch>- Subject: Re: Selling VMS to another company ?i* Message-ID: <3B5DB451.7650D542@dplanet.ch>   jlsue wrote: > 2 > There are other things to consider here as well: > 1 > 1.  Business is down for many (most?) companiesn  G And that's a retrospective justification for dumping Alpha and claimingeH that it was not making money, especially after the lack of marketing for the Alpha-based platforms ???m    > > 2.  Compaq has *two* high-end server groups:  One working onG > Alphaserver systems, and one working on Intel/AMD systems.  Ever lookoG > at the details of the Proliant 8500 architecture?  It has an internal,F > switched bus... but it doesn't use switch technology we own.  HavingG > two completely different "systems" engineering groups has got to be a  > drain on resources.i  G Intel/AMD stuff seems aimed at the companies who are still "growing up"a from being PC users.  H One of contributing factors to Compaq's situation is that it is treatingH the entire IT user community as PC buyers.  Compaq will assemble the boxD - preferably with someone else's operating system (either MS and nowG also Linux) - then flog it to the customers, who they hope will replaced it in 2 or 3 years maximum.h  G Compaq's latest idea of being a "solutions company" and working closelydF with the resellers shows that they are still doing their best to avoid' getting heavily involved with software.     H > I see one huge benefit of the IA64-based VMS/Tru64/NSK systems is thatF > we will probably end up with one consolidated group working togetherD > to engineer the best high-end servers.  Combining them should help/ > make Compaq much more competitive/profitable.   E Not unless their mindset changes and they start treating customers asc( knowing something about technologically.    D If they are really unhappy about being software engineers then maybeB they should spin-off the Tru64, OpenVMS and Himalaya groups into aH separate company.  They could hold most of the shares but let the publicA get involved.  What do you think ?  Would a good name for the newt- company be "Digital Equipment Corporation" ??y     John McLeaneG (I have to tell you, it felt really good to be typing those three wordst !)       . > On Mon, 23 Jul 2001 13:49:50 -0400, JF Mezei' > <jfmezei.spamnot@videotron.ca> wrote:  >  > >Burnie M wrote:S > >> >The killing of Alpha is simply a corporate decision by Compaq because this ise3 > >> >not where Compaq wants to go in its strategy.s > >>- > >> Exactly where does Compaqs strategy go ?cK > >> Anybody from Compaq ? or are you guys/gals as much in the dark as us ?- > >- > > K > >Compaq did state some time ago that they would move to industry standardiJ > >hardware. Shortly after than, they started to call their wintel serversE > >"industry standard", meaning that Alpha was not industry standard.n > >nM > >Their past financial statements indicated that they beleived that NT wouldV > >rule the enterprise.r > >hJ > >The TV ad campaign that was designed to portray Compaq as an enterpriseN > >company featured Proliant servers. (granted, that was 2 seconds on an alphaJ > >mainframe shown, but most would think it is another big wintel server). > >nN > >Compaq's killing of Alpha was designed to cut costs and put everything intoL > >one industry standard chip. (yeah, as if Compaq is going to drop the 8086 > >anytime soon).p > >lN > >In hindsight, Compaq has sent lots of messages that anything non-wintel wasN > >not considered a strategic/core product. Doesn't mean that Compaq will killP > >anything that isn't industry standard, but it certaintly leads one to beleiveN > >that Compaq won't be pushing those "weird" platforms such as Alpha and VMS.   ------------------------------  % Date: Tue, 24 Jul 2001 14:36:16 -0300r) From: fabio_compaq@ep-bc.petrobras.com.br - Subject: Re: Selling VMS to another company ?mL Message-ID: <OF723C19BA.CF4CF3F3-ON03256A93.00603039@ep-bc.petrobras.com.br>  I I've read that the Unisys CMP ES7000 is already prepared to run IA-64 and E can work with the IA-32 / IA-64 architecture in the same "box" (???).lB May be CPQ will have a "Galaxy" for Itanium machines.. which means; having OpenVMS / Tru64 / WNT in the same "box" and managingi< the CPUs on demand... hmmmmm....what worries me more is dont: have the possibility to run OpenVMS / AIX in the same box.1 The ROMs should be "opened" for this possibility.f  K It is my personal opinion ! I believe sometimes you think I am crazy .. butU I am not ! :-)   Regards    FC          E "Terry C. Shannon" <terryshannon@mediaone.net> em 24/07/2001 14:20:49t  @ Favor responder a "Terry C. Shannon" <terryshannon@mediaone.net>             Info-VAX@Mvb.Saic.Comr      - Assunto: Re: Selling VMS to another company ?e    J The BCSG and ISSG no longer are separated by architectural instruction setI issues. The ISSG already has one IPF platform; 4 and 8-way McKinley boxes C will come out sometime next year followed by a 32-way McKinley box.e  H The ISSG works quite closely with Intel and has plenty of expertise with high volume platforms.  H Given the architectural consolidation and Compaq's continuing efforts toF reduce structural expenses, a consolidation of the ISSG and BCSG makes sense  to me.  6 <fabio_compaq@ep-bc.petrobras.com.br> wrote in messageF news:OFC0221FD4.97C7325D-ON03256A93.005B50E7@ep-bc.petrobras.com.br...K > Stay Tuned .... it  means ... let's sleep waiting for the princess kiss !D !r > !n >- > May be some day !- >e	 > Regardsm >s > FC >> >  >a >cG > "Terry C. Shannon" <terryshannon@mediaone.net> em 24/07/2001 13:19:00b >gB > Favor responder a "Terry C. Shannon" <terryshannon@mediaone.net> >l >r >i >       Info-VAX@Mvb.Saic.ComA >n >u >o/ > Assunto: Re: Selling VMS to another company ?d >r >m >t/ > "jlsue" <jlsuexxxz@home.com> wrote in messagei4 > news:q8vqltos4gnruftne1enbp8p9h5sprqrem@4ax.com...4 > > There are other things to consider here as well: > >e3 > > 1.  Business is down for many (most?) companiest@ > > 2.  Compaq has *two* high-end server groups:  One working onI > > Alphaserver systems, and one working on Intel/AMD systems.  Ever lookqI > > at the details of the Proliant 8500 architecture?  It has an internal-H > > switched bus... but it doesn't use switch technology we own.  HavingI > > two completely different "systems" engineering groups has got to be a  > > drain on resources.5 > >.J > > I see one huge benefit of the IA64-based VMS/Tru64/NSK systems is thatH > > we will probably end up with one consolidated group working togetherF > > to engineer the best high-end servers.  Combining them should help1 > > make Compaq much more competitive/profitable.- >  > Yup.  Stay tuned...4 >9 >2 >  >m >a >o >u >e   ------------------------------  % Date: Tue, 24 Jul 2001 10:51:40 -0400f. From: "Jerry Alan Braga" <jabraga@flanagan.ca>( Subject: Re: SMTP and distribution lists4 Message-ID: <LYf77.267687$Z2.3257969@nnrp1.uunet.ca>  ) I tried your solution but it did not work   I I created a logical called jerry.braga "tcpip$smtp_common:jerrybraga.dis"n  E But when I send mail to jerry.braga@flanagan.ca it bounces with error, invalid user jerrybraga.disrB So I tried the logical without the .dis but bounce is invalid user
 jerrybragaF So I tried without the tcpip$smtp_common but still invalid user errors   What I did do that worked is:tK $define/sys jerry.braga jerryb@flanagan.ca ! where jerryb@flanagan.ca is mye true address $! orAI $define/sys jerry.braga jerryb@flanagan.ca ! where jerryb is my user name7+ and let tcpip replace in the hidden domain.p  > What did you mean that 7.2 supports it but TCPIP is not ods5 ?  K I am currently running 7.1-1h2 and am looking to upgrade to either 7.2-1 orrK even 7.3 if possible?  Do you now if Pathworks 6.1 is available soon and if K it will support 7.3?  We have a cost issue with upgrading all the lic.  AndrF will 6.1 have the features of the 7.2/7.3. I am mainly looking for the member server support.  ? "Hoff Hoffman" <hoffman@xdelta.zko.dec.nospam> wrote in messagem- news:0O077.1129$rc5.73715@news.cpqcorp.net...sI > In article <oE%67.267463$Z2.3250513@nnrp1.uunet.ca>, "Jerry Alan Braga"i <jabraga@flanagan.ca> writes:  >sJ > :Is it possible to somehow use the first.last@domain.com using the aboveG > :construct.  I have tried this but of course OpenVMS does not allow ar# > :filename called FIRST.LAST.DIS .u >eK >   OpenVMS does support this ability (V7.2 and later), but TCP/IP Servicesa2 >   has not been updated to full support of ODS-5. >y- > :Can you somehow substitute using a logicalaK > :or something a character in the filename that would translate to anothers forn > :the filename. >p >   Try: >i >     $ def foo.bar foo/system >tJ >   Where the target distribution file is named tcpip$smtp_common:foo.dis.G >   (You could use another logical name table, but you need to keep the H >   logical in a name table where it is visible to the SMTP processing.) >gJ >   I do not know if this is documented and supported, but it does seem to	 >   work.  >,( >  ---------------------------- #include' <rtfaq.h> -----------------------------VL >       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com, >  --------------------------- pure personal# opinion ---------------------------r1 >    Hoff (Stephen) Hoffman   OpenVMS Engineering- hoffman#xdelta.zko.dec.com >    ------------------------------    Date: 24 Jul 2001 11:22:39 -05003 From: malmberg@encompasserve.org (John E. Malmberg)e( Subject: Re: SMTP and distribution lists3 Message-ID: <MMHv1ioyFHPa@eisner.encompasserve.org>w  4 In article <LYf77.267687$Z2.3257969@nnrp1.uunet.ca>,1  "Jerry Alan Braga" <jabraga@flanagan.ca> writes:e+ > I tried your solution but it did not worke >iK > I created a logical called jerry.braga "tcpip$smtp_common:jerrybraga.dis"    Tryn  > $define/system jerry.braga "@tcpip$smtp_common:jerrybraga.dis"  L Where jerrybraga.dis contains a record(s) for the address(s) you really want the E-mail to go to.   > What I did do that worked is:iM > $define/sys jerry.braga jerryb@flanagan.ca ! where jerryb@flanagan.ca is mye > true address > $! orhK > $define/sys jerry.braga jerryb@flanagan.ca ! where jerryb is my user name - > and let tcpip replace in the hidden domain.   G I missed the first part of this thread, so I am not really sure of whatt you really want to do.  J >> In article <oE%67.267463$Z2.3250513@nnrp1.uunet.ca>, "Jerry Alan Braga" > <jabraga@flanagan.ca> writes:y >>K >> :Is it possible to somehow use the first.last@domain.com using the abovecH >> :construct.  I have tried this but of course OpenVMS does not allow a$ >> :filename called FIRST.LAST.DIS .  E The .DIS file type is typically used for sending mail to the multipleaH recipients contained in the list.  The OpenVMS mail utility expects thatE file specifications for mailing lists be preceded by a "@" character.l   -Johnp wb8tyw@qsl.network Personal Opinion Onlyh   ------------------------------  % Date: Tue, 24 Jul 2001 12:58:38 -0400 ; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>t( Subject: Re: SMTP and distribution lists$ Message-ID: <3b5da993$1@news.si.com>  H >Is it possible to somehow use the first.last@domain.com using the aboveE >construct.  I have tried this but of course OpenVMS does not allow a E >filename called FIRST.LAST.DIS .  Can you somehow substitute using a- logical-I >or something a character in the filename that would translate to anothere fora >the filename.   VMS _will_ allow this, however:t   $ mail2 MAIL> set forw/user=first.last smtp%joe@domain.com  , Them, simply mail to FIRST.LAST in VMS mail. --A Brian Tillman                   Internet: tillman_brian at si.com A Smiths Aerospace                          tillman at swdev.si.come= 3290 Patterson Ave. SE, MS      Addresses modified to preventh< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  # Date: Tue, 24 Jul 2001 12:33:52 GMTt& From: "john nixon" <jnixon@cfl.rr.com>" Subject: tcpip routing information< Message-ID: <QWd77.57456$rt.8853610@typhoon.tampabay.rr.com>  L Within my cluster are some VAX 7860s running VMS 7.1 with TCP/IP V4.2  eco4,6 and an Alpha GS140 running VMS 7.2-1 with TCP/IP V 5.0 a eco 3.  H When I have mail forwarded from our Lotus Notes server to the VAX (usingL standard vax mail), everything is fine, but if it is forwarded to the Alpha,J I get two pages of routing/tracking type information.  How can I turn this off?   ------------------------------  % Date: Tue, 24 Jul 2001 15:24:52 +0200i= From: Oswald Knoppers <Oswald.Knoppers@contrastmediagroep.nl>O& Subject: Re: tcpip routing information5 Message-ID: <3B5D7724.6BD3EE76@contrastmediagroep.nl>    john nixon wrote:   J > When I have mail forwarded from our Lotus Notes server to the VAX (usingN > standard vax mail), everything is fine, but if it is forwarded to the Alpha,L > I get two pages of routing/tracking type information.  How can I turn this > off?  ; In UCX> or TCPIP> do a 'set config smtp/options=noheaders'.e  E You'll have to restart the mail service (tcpip start mail, tcpip stop@ mail) to make this active.   Regards,   Oswald   ------------------------------    Date: 24 Jul 2001 10:22:45 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>r- Subject: Re: Terry Shannon Tech Talk on IA-64mH Message-ID: <y4k80y3fe2.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  7 "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:   K > I know in other forums/threads you have argued that IA64 will not replaceoN > the IA32.  I tend to disagree.  I think that Intel and MS will push the IA64N > down into the IA32 market.  Face it - nobody needed or wanted Windows 98, orN > even W2K, or worse WXP, I'm still running W95 (grudgingly from W3.1) because# > I still have win16 apps around.  a  J As long as AMD is around, Intel isn't in a position to just "push" IA32 toN the cemetary. Just as Alpha's presence wasn't able to push VAX to the cemetaryH - the installed base is just too large, and it will take quite some timeL until the low- (desktop) or even medium-end (small-business server) machinesJ _need_ IA64's main differentiating feature, 64-bit addressing. And by thatL time, AMD's alternative likely is around to support those that do need with  a more harmonious growth path.  E And as Bill has noted, in the higher-end systems, any possible _cost_nG advantage an IA64 processor could possibly have over an Alpha processortG is lost in the noise. And as Sun's success shows, processor performanceaE as such is (almost) irrelevant in this segment as well: it is systems H integration, both hard- and software, that counts. EV7 is unique in justH these features - it's a T9000 on steroids. And EV8 would have added even# more transputer features with SMT. h  N Of course, the machinery surrounding the EV6 core in the EV7 chip doesn't careI much about the core's detail - it should be (more or less) "architecture-0I neutral". As such, what's the bet a future IA64 processor receives an EV7a transplant?    	Jan   ------------------------------    Date: 24 Jul 2001 11:10:01 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>i- Subject: Re: Terry Shannon Tech Talk on IA-64pH Message-ID: <y4u202hevq.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  7 "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:   N > Customers on Alpha should not have anything near the problems of moving fromH > the VAX.  First, I would expect that much of the Alpha code *is* stillN > around.  And that much of it will *not* have to be changed in any way.  JustI > recompiled.  We are also looking at translation technology to run Alphaf/ > binaries for stuff that just can't get there.   N That will be an essential requirement, and you must do better than VEST did toJ keep VMS viable, especially with regard to future support (which should beH easier because the architectural changes required to VMS to support IA64M should not be user-visible, or be really major upgrades as the later AlphaVMSe" versions are compared to VAXVMS).   J The essential difference to late PDP-10/early VAX times is that businessesJ no longer write their own software. Heck, I work at a software developmentL company, but 99.9% of the software I use is not written by us. And the wholeM development environment is a third-party product. No way a "simple processor- E architecture transition" can be solved by "just recompiling", becauseiK customers just don't have the source code to their software. And one singleyM required application that runs on AlphaVMS but not IA64VMS opens up the whole 5 decision process on transition to other alternatives.o   	Jan   ------------------------------    Date: 24 Jul 2001 11:31:31 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>r- Subject: Re: Terry Shannon Tech Talk on IA-64cH Message-ID: <y4r8v6hdvw.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  7 "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:e  J > >If you lost trust in your {spouse, child, best friend, ...}, that wouldE > >be a personal issue, no? Why is a business relationship viewed anya > >differently? H > I hope this was just very poor rhetoric.  One is not even close to the8 > other.  Or maybe I just have my priorities screwed up.  I I wouldn't think you, personally, have a problem with your priorities buteG Compaq and before it DEC, as a company, did and do have such a problem.s  N VMS _could_ be sold to "the man in the street", like Windows or Linux are, butK DEC and CPQ have decided not do so but go for the "big accounts". To these, K your customers ultimately, trust in their vendor is the number 1 priority -wM nothing else comes even close (given that a product in question satifies very L basic requirements with regard to functionality). "Nobody was ever fired forN buying IBM" - not because of IBM's technical prowess, or marketing ability, orK some other magic ingredient (although they also played a role), but becauserL they worked at and managed  building a strong trust relationsship with their customers.    K When Digital was still DEC, the situation was similar, and that enabled thetG company to sell technically inferior products (inferior, mainly, from a L performance point-of-view) - just the situation Sun has been in for a numberL of years and doing well. Later, and mostly during Palmer's reign, that trustL relationsship was quickly destroyed, and Compaq was never willing or able toL rebuild it. And the way Compaq handled the 25 June annouced must be the lastF straw. Why didn't they take just a little more time to prepare it moreL thoroughly? Why are answers on the rationale for the decision contradictory?I Why not, for once, publish the financial background in more detail so thecI validity of the decision can be understood by customers? Analyses such astJ Bill's of the claimed financial implications make it quite likely that theL "real" strategic reasons behind the decisions are quite different, and thereI is nothing worse for a relationsship based on trust than not knowing whatdN your "partner"'s real aims and intentions are. Worst, the whole scenario givesN indications that CPQ, as a company, doesn't know what it is doing and where itI is going, so that even the most sincere stated intentions stated now williF likely be overthrown tomorrow or even later today with something quite= different, at the slightest breeze turning up from somewhere.p  N No way a large corporate customer of Compaq's should trust them in the future.   	Jan   ------------------------------  % Date: Tue, 24 Jul 2001 20:08:42 +0010m% From: paddy.o'brien@zzz.tg.nsw.gov.au - Subject: Re: Terry Shannon Tech Talk on IA-64'5 Message-ID: <01K6BL7HWCV60031UD@tgmail.tg.nsw.gov.au>d   Jan Vorbrueggen wrote:  8 >"Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes: >hK >> >If you lost trust in your {spouse, child, best friend, ...}, that would-F >> >be a personal issue, no? Why is a business relationship viewed any >> >differently?I >> I hope this was just very poor rhetoric.  One is not even close to the39 >> other.  Or maybe I just have my priorities screwed up.  >tJ >I wouldn't think you, personally, have a problem with your priorities butH >Compaq and before it DEC, as a company, did and do have such a problem. >eL >VMS _could_ be sold to "the man in the street", like Windows or Linux are,  >butL >DEC and CPQ have decided not do so but go for the "big accounts". To these,L >your customers ultimately, trust in their vendor is the number 1 priority -J >nothing else comes even close (given that a product in question satifies  >very M >basic requirements with regard to functionality). "Nobody was ever fired for M >buying IBM" - not because of IBM's technical prowess, or marketing ability, a >oreL >some other magic ingredient (although they also played a role), but becauseM >they worked at and managed  building a strong trust relationsship with theirC >customers.  >nL >When Digital was still DEC, the situation was similar, and that enabled theH >company to sell technically inferior products (inferior, mainly, from aM >performance point-of-view) - just the situation Sun has been in for a numbertM >of years and doing well. Later, and mostly during Palmer's reign, that trustrM >relationsship was quickly destroyed, and Compaq was never willing or able to M >rebuild it. And the way Compaq handled the 25 June annouced must be the lastcG >straw. Why didn't they take just a little more time to prepare it moreOM >thoroughly? Why are answers on the rationale for the decision contradictory?eJ >Why not, for once, publish the financial background in more detail so theJ >validity of the decision can be understood by customers? Analyses such asK >Bill's of the claimed financial implications make it quite likely that the M >"real" strategic reasons behind the decisions are quite different, and thereAJ >is nothing worse for a relationsship based on trust than not knowing whatJ >your "partner"'s real aims and intentions are. Worst, the whole scenario  >givesM >indications that CPQ, as a company, doesn't know what it is doing and where   >it.J >is going, so that even the most sincere stated intentions stated now willG >likely be overthrown tomorrow or even later today with something quiter> >different, at the slightest breeze turning up from somewhere. >rH >No way a large corporate customer of Compaq's should trust them in the  >future.  * And what a well worded/structured comment.  L Much as I have enjoyed reading the comments from FK, S(H)H and SL, I have a  sense of deja vu.   J In a previous world (at least), for job security, I had to ostensibly wax J lyrical about the wonderful work I had been given.  Show enthusiasm.  Our K team had to produce applications that we knew in our heart of hearts would CI die -- and they did (they even died before their birth).  We bloody well 2L slogged our guts out to produce applications that would never see the light L of day.  We even worked overtime at weekends to meet (artificial) deadlines.  L As "professionals", this was soul destroying to our team.  We were all much L younger than we are today, and several of us had young families.  We needed F the job security and the pay-packet -- so we had to "show enthusiasm".  K The other end of the scale, close to retirement and superannuation, "gotta g+ hang in till then" -- so "show enthusiasm".i  L Not trying to speak for the aforementioned engineers, just a sorry/sad part  of my personal experience.   Regards, Paddy   ------------------------------  # Date: Tue, 24 Jul 2001 23:03:28 PDTj From: ts1@its.com.sg Subject: tre* Message-ID: <3b5d8e87@news.starhub.net.sg>   gu jg jkgo yio ypouo [pio[ op[l ]m   ------------------------------  % Date: Tue, 24 Jul 2001 12:30:19 -04007; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>iT Subject: Re: Triggering tasks from network file arrival - Was Re: Basic VMS  Questio$ Message-ID: <3b5da2ef$1@news.si.com>  L >Actually, what would be nice for the FTP server on VMS is if a logical name >such as# >$define TCPIP$FTP_SUBMIT  my_queue/ >.L >is set, then FTP would submit each received file to "my_queue" upon closing >the file succesfully. >oL >"my_queue" could then be a "server" queue which would process in the coming7 >file. That would be a very esthetic and efficient way.a  H Actually, this should be doable using a spooled device.  In fact, I justD tried it and it worked.  Here's what I did.  On a node named AGVAX I entered:   $ mcr latcpd LATCP> create port lta7000 LATCP> exitT" $ set dev/spool=sys$batch lta7000:   Then, from another system:   $ ftp agvax/1 benzie.si.com MultiNet FTP user process V4.3(119)o. Connection opened (Assuming 8-bit connections)E <agvax.si.com MultiNet FTP Server Process V4.3(16) at Tue 24-Jul-2001d 12:06PM-EDT  Username [tillman]:e* <User name (tillman) ok. Password, please.	 Password:y@ <User TILLMAN logged into A305_DISK:[TILLMAN] at Tue 24-Jul-2001 12:06PM-EDT, job 204060c2.* AGVAX.SI.COM>put test.com lta7000:test.com3 <ASCII Store of LTA7000:[TILLMAN]TEST.COM; started.r2 <Transfer completed.  10800 (8) bytes transferred.& 10800 bytes transferred at 320000 bps.) Run time = 0. ms, Elapsed time = 270. ms., AGVAX.SI.COM> quit  <QUIT command received. Goodbye.  J The job on AGVAX executed.  Of course, you can't pass parameters, but that might not be a drawback. --A Brian Tillman                   Internet: tillman_brian at si.com-A Smiths Aerospace                          tillman at swdev.si.com-= 3290 Patterson Ave. SE, MS      Addresses modified to prevent-< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  % Date: Tue, 24 Jul 2001 10:25:24 -0500a6 From: Gunther Schadow <gunther@aurora.regenstrief.org>& Subject: VAX 11/785 cabinet needed ...6 Message-ID: <3B5D9364.A0BAA9E4@aurora.regenstrief.org>   Hi,   G I'm a VAX collector and have a full set of 11/785 boards in my basementnG seeking a shell so they can come to life. Does anyone have an 11/780 orrH 11/785 cabinet with PSUs and backplanes in his basement, barn, or officeE and can spare it now or in a little while? Or do you know of a place  E that has one standing around? I don't need it right away, but knowingeF where someone might want to part with them in the near future would be a good help.  K Do you know if the 11/785 backplane has the same electrical characteristicstI as the 11/780? In other words, could one take an 11/780 and just swap thedH boards with an 11/785 to turn the 780 into a 785? I know you couldn't do> that with a 6000-400 and a 6000-600 but don't know for 11/78x.  
 Thank you, -Gunther     -- mH Gunther Schadow, M.D., Ph.D.                    gschadow@regenstrief.orgH Medical Information Scientist      Regenstrief Institute for Health CareH Adjunct Assistant Professor        Indiana University School of MedicineH tel:1(317)630-7960                         http://aurora.regenstrief.org   ------------------------------    Date: 24 Jul 2001 09:05:19 +0100/ From: Peter Hancock <peter@premise.demon.co.uk>-! Subject: VM: checking some myths.e3 Message-ID: <oqae1uycow.fsf_-_@premise.demon.co.uk>m  6 Since there are people here who know a lot about these@ things, can I take the opportunity to check a couple of possible myths? p  = 1. Nobody asked for VM. It was some kind of moonlight project <    by a scientific computing group at IBM.  However IBM were*    smart enough to realise what they had.   @ 2. One of the main reasons that customers liked VM was that theyG    could test-run new or trial versions of buggy systems alongside the mH    current versions.  So the attraction was in large part one of dealing    with software faults.    ? Is it possible to say in a sentence or two, or point to a short D high-level description of what kind of communication interface thereE is/was between the virtual machines?  How do they look to each other?E  
 Peter Hancocke   ------------------------------  # Date: Tue, 24 Jul 2001 17:47:58 GMTt2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)% Subject: Re: VM: checking some myths.-/ Message-ID: <ixi77.30$Yx2.399@news.cpqcorp.net>t  e In article <oqae1uycow.fsf_-_@premise.demon.co.uk>, Peter Hancock <peter@premise.demon.co.uk> writes:.7 :Since there are people here who know a lot about these A :things, can I take the opportunity to check a couple of possiblea :myths?   C   You have made a central myth-stake :-), as you are asking IBM VM dC   questions in the Compaq OpenVMS (VMS) operating system newsgroup.v  @ :Is it possible to say in a sentence or two, or point to a shortE :high-level description of what kind of communication interface there F :is/was between the virtual machines?  How do they look to each other?  E   The typical virtual machine implementation provides virtualized I/O:I   devices, meaning that guest operating systems -- potentially including aB   a virtual machine itself operating as a guest of another virtualD   machine -- all see themselves as running on what appears to be the
   hardware.     D   One of the key to good virtual machine performance is interceptingG   as few instructions and as few I/O calls as is possible, as the more oE   intercepts and the more emulation that is required, the slower the m   overall operation.  C   I would encourage most any operating system text book for details 9   on virtual memory and virtualizing an operating system.:  D   As for discussions of any IBM VM mythos and/or pathos (if any, of 1   course), please visit an IBM-related newsgroup.   N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Tue, 24 Jul 2001 10:36:19 -0400r2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: vms backupaL Message-ID: <rdeininger-2407011036190001@user-2ive6ha.dialup.mindspring.com>  A In article <23JUL01.15131902@feda01.fed.ornl.gov>, Dave Greenwood' <greenwoodde@ornl.gov> wrote:a  G > In a previous article, Massimiliano.Mauceri@tlc.semagroup.it (Maucerie Massimiliano) wrote: > > Hi( > > About cd rom device another question. > > If I have this situation on my VMS system: > > $1$DQA0: > > $1$DQA1: > > $1$DQB0: > > $1$DQB1:M > > which is the cd rom device if the all devices have device status online ?w > L > Use  SHOW DEVICE/FULL DQ.  The actual cdrom (DQB0 on my systems) will have; > it's device type displayed (at least on the host system).h  F On our systems, the device type doesn't seem to be known after booting until the first CD is mounted.   -- e Robert Deininger rdeininger@mindspring.com    ------------------------------   Date: 24 JUL 2001 15:12:53 GMT+ From: Dave Greenwood <greenwoodde@ornl.gov>d Subject: Re: vms backupe2 Message-ID: <24JUL01.15125348@feda01.fed.ornl.gov>  J In a previous article, rdeininger@mindspring.com (Robert Deininger) wrote:C > In article <23JUL01.15131902@feda01.fed.ornl.gov>, Dave Greenwoode > <greenwoodde@ornl.gov> wrote:  >   I > > In a previous article, Massimiliano.Mauceri@tlc.semagroup.it (Mauceri- > Massimiliano) wrote: > > > Hi* > > > About cd rom device another question0 > > > If I have this situation on my VMS system: > > > $1$DQA0: > > > $1$DQA1: > > > $1$DQB0: > > > $1$DQB1:O > > > which is the cd rom device if the all devices have device status online ?k > > N > > Use  SHOW DEVICE/FULL DQ.  The actual cdrom (DQB0 on my systems) will have= > > it's device type displayed (at least on the host system).p >  hH > On our systems, the device type doesn't seem to be known after booting  > until the first CD is mounted.  I Hmmm.  What version of VMS are you using?  Mine is 7.2-1.  I just checked C 2 systems on which I'm quite sure no CD has been mounted (both show < "operations completed" = 1) and they both give device types.  I Or perhaps there's a difference in system and/or CDROM type?  The systemsl I looked at are:  +   PWS500au with a "TOSHIBA CD-ROM XM-6302B" #   XP1000 with a "Compaq  CRD-8322B"b  5 Again, I only get the device type on the host system.e   Dave --------------9 Dave Greenwood                Email: Greenwoodde@ORNL.GOVAH Oak Ridge National Lab        %STD-W-DISCLAIMER, I only speak for myself   ------------------------------  % Date: Tue, 24 Jul 2001 11:46:19 -0400o2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: vms backupuL Message-ID: <rdeininger-2407011146200001@user-2ive6ha.dialup.mindspring.com>  A In article <24JUL01.15125348@feda01.fed.ornl.gov>, Dave Greenwood  <greenwoodde@ornl.gov> wrote:l     > >  dJ > > On our systems, the device type doesn't seem to be known after booting" > > until the first CD is mounted. > K > Hmmm.  What version of VMS are you using?  Mine is 7.2-1.  I just checked3E > 2 systems on which I'm quite sure no CD has been mounted (both showi> > "operations completed" = 1) and they both give device types.  G Well, now it's working as you say.  VMS 7.1-2. TOSHIBA CD-ROM XM-6302B.F  J It used to not work, but we've done a lot of ECOing recently.  I must have missed the change.  ,7 > Again, I only get the device type on the host system.o  G Yes, that's still true here.  Remote systems can't see the device name.i   -- u Robert Deininger rdeininger@mindspring.com    ------------------------------  # Date: Tue, 24 Jul 2001 17:53:25 GMTl2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: vms backupa/ Message-ID: <pCi77.32$Yx2.498@news.cpqcorp.net>u   In article <rdeininger-2407011036190001@user-2ive6ha.dialup.mindspring.com>, rdeininger@mindspring.com (Robert Deininger) writes:bB :In article <23JUL01.15131902@feda01.fed.ornl.gov>, Dave Greenwood :<greenwoodde@ornl.gov> wrote: :rH :> In a previous article, Massimiliano.Mauceri@tlc.semagroup.it (Mauceri :Massimiliano) wrote:a :> > Hir) :> > About cd rom device another questiond/ :> > If I have this situation on my VMS system:f
 :> > $1$DQA0:l
 :> > $1$DQA1:r
 :> > $1$DQB0: 
 :> > $1$DQB1:mN :> > which is the cd rom device if the all devices have device status online ? :> mM :> Use  SHOW DEVICE/FULL DQ.  The actual cdrom (DQB0 on my systems) will haveD< :> it's device type displayed (at least on the host system). : G :On our systems, the device type doesn't seem to be known after bootingo :until the first CD is mounted.-  D   OpenVMS platform, version, and controller details?  Served device?  F   AFAIK, OpenVMS V6.2 and later acquire the (directly-connected) SCSI F   device information (directly from the device) as part of the device    (auto)configuration process.  N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  # Date: Tue, 24 Jul 2001 17:47:12 GMTeB From: Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP>& Subject: Re: VS3100 & (dead?) ST51080N5 Message-ID: <Awi77.5396$ar1.15014@www.newsranger.com>g  O On Mon, 23 Jul 2001 10:20:11 -0400, in article <9jhbpm$1mj$1@bob.news.rcn.net>,v Mike Duffy wrote:t >Q- >Someone gave me a Seagate ST51080N disk withn= >the caveat "It's been on a shelf for a couple years.  Nobodyn >knows if it works." >i8 >I plugged it into a VS3100 M76/SPX, V5.5-2H4.  It spins/ >up, and all looks normal with >>> SHOW DEV andr >>>> TEST 6 and  >>> TEST 0. >y7 >However, when the system is running, any MOUNT or INIT 9 >command fails with "Fatal drive error" and the following @ >entry appears in the error log.  Note the geometry information. >w  	 [deleted]j    >       PAGE DESC 1.    FFFF0A81  >                       00000000  >                       000000FF9 >                                       PAGE CODE = 01(X).A >                                       ERROR RECOVERY PARAMETERSiA >                                       _DISABLE ERROR CORRECTIONyB >                                       _DISABLE TRANSFER ON ERROR3 >                                       _POST ERRORo@ >                                       _ENABLE EARLY CORRECTION8 >                                       _READ CONTINUOUSB >                                       _TRANSFER FAILING DATA BLKF >                                       _ENABLE AUTOMATIC READ REALLOCG >                                       _ENABLE AUTOMATIC WRITE REALLOCe9 >                                       _RETRY CNT = 255. = >                                       _CORRECTION SPAN = 0.o= >                                       _HEAD OFFSET CNT = 0. D >                                       _DATA STROBE OFFSET CNT = 0.F >                                       _RECOVERY TIME LIMIT = 0. MSEC >e  G If I am reading this portion of this entry correctly, it seems that thetI drive has automatic bad block re-vectoring enabled, which your version ofe5 VMS does not like as it wishes to handle this itself.c  F I have never had to do this with the third party drives on my hobbyistB machines, so I am unfamiliar with the procedure, but if you searchF groups.google.com, you should find instructions on disabling automaticG bad block re-vectoring using an unsupported VMS supplied tool. I do nots1 know if this tool is part of your version of VMS.h  M I would also echo another poster's comments and point out that later versionsA5 of VMS seem to behave better with third party drives.t   Hope this helps,   Simon.  N PS: What is the size of this drive ? I also seem to recall a 8GB limit in your3 version of VMS that got fixed in the 6.x timeframe.W   --  ; Simon Clubley, simon_clubley@remove_me.excite.com-Earth.UFPtK In the task of removing Microsoft from the marketplace, I have discovered asE truly remarkable plan, but this signature is too small to contain it.a   ------------------------------    Date: 23 Jul 2001 23:57:02 -0700( From: rob@denbraber.org (Rob den Braber)I Subject: What is the maximum number of mirrorsets on a HSG80 controller ?a= Message-ID: <9fa0ae66.0107232257.70c2fe3a@posting.google.com>d  B I've got a question about the maximum number of mirrorsets that isE allowed on the HSG80 controller. When I read the configuration manuals. , it confused me, cause it said the following:   - max 20 RAID-5 Storagesetsn& - max 30 RAID-5 and RAID-1 storagesets. - max 45 RAID-5, RAID-1 and RAID-0 storagesets  @ Somewhere else in the manual it says "You can configure op to 20@ mirrorsets per controller or pair of dual-redundant controllers"  E At this moment we've got 31 mirrorsets on a dual-redundant controllerfD pair running without any problems. What I would like to know is what# is the maximum supported by Compaq.    Regards,   Rob den Braber   ------------------------------    Date: 24 Jul 2001 12:30:02 +0200G From: Jan Vorbrueggen <jan@mailhost.neuroinformatik.ruhr-uni-bochum.de>e4 Subject: Re: Why Compaq won't succeed on IA64 eitherH Message-ID: <y44rs21uxh.fsf@mailhost.neuroinformatik.ruhr-uni-bochum.de>  ) "Bill Todd" <billtodd@foo.mv.com> writes:i  J > I.e., extrapolating IA32 performance to IA64 may be inadvisable not onlyK > because IA64 uses a complex, in-order approach to performance (vs. IA32'sfM > internal OOO approach) but also simply because of the bit-width differences G > between the architectures.  But as I said I'm no hardware engineer...a  I There are two ways, I'd say, a 32-bit architecture might be better than ag? 64-bit version on a task not requiring >32 bits for addressing:   K - If pointers and integers are of natural size, the 32-bit version requires-J   less memory bandwidth, which would impact bandwidth-limited applications   most.   I   Clearly, this is a small matter of programming (the compiler and OS and G   run-time support). One way to check is to look at the Alpha SPEC CPU  5   submissions and look for any one of the taso flags.c  H - A larger datapath might impact the processor's critical path and thus H   reduce cycle times and/or and pipeline stage(s). This would impact all   applications.h  J   From what I seem to remember from John Mashey's posting on the R4k, thisJ   is not very likely. In any case, the trade-offs are so complex and high-E   dimensional that one is unlikely to be able to perform a controlled    experiment.    	Jan   ------------------------------    Date: 24 Jul 2001 07:58:54 -0500 From: briggs@encompasserve.org$ Subject: Re: Zero Quadword Time Poll3 Message-ID: <A32dz+LRNmCO@eisner.encompasserve.org>   N In article <VA.00000402.2d0a9ff3@sture.ch>, Paul Sture <paul@sture.ch> writes:E > In article <tloiaaq4daeo67@news.supernews.com>, John Vottero wrote:mH >> This is all getting a little gray.  Doing things like subtracting theK >> absolute time zero from the current time should return a delta time but,tM >> that violates the 10,000 day rule.  Was the 10,000 day rule eliminated fori9 >> the Unix time fix?  Or was the 10,000 value increased?o >>A > IIRC the 10,000 day bug was limited to things like Motif - i.e. & > stuff originating from Unix systems.  I My recollection differs.  LIB$ADD_TIMES and LIB$SUB_TIMES were performingaB a gratuitous error check on delta times to make sure that they met the 10,000 day rule.  I I can't imagine what they were thinking when they put that test in there.II But then I can't imagine why anyone would use either routine in the firstc place.   	John Briggs   ------------------------------  % Date: Tue, 24 Jul 2001 09:02:31 -0400n% From: "John Vottero" <John@mvpsi.com>r$ Subject: Re: Zero Quadword Time Poll/ Message-ID: <tlqsegctu0kn48@news.supernews.com>   + <briggs@encompasserve.org> wrote in message - news:A32dz+LRNmCO@eisner.encompasserve.org... H > In article <VA.00000402.2d0a9ff3@sture.ch>, Paul Sture <paul@sture.ch> writes:-G > > In article <tloiaaq4daeo67@news.supernews.com>, John Vottero wrote:gJ > >> This is all getting a little gray.  Doing things like subtracting theH > >> absolute time zero from the current time should return a delta time but,K > >> that violates the 10,000 day rule.  Was the 10,000 day rule eliminatede for ; > >> the Unix time fix?  Or was the 10,000 value increased?w > >>C > > IIRC the 10,000 day bug was limited to things like Motif - i.e.n( > > stuff originating from Unix systems. >pK > My recollection differs.  LIB$ADD_TIMES and LIB$SUB_TIMES were performingeD > a gratuitous error check on delta times to make sure that they met > the 10,000 day rule. >kK > I can't imagine what they were thinking when they put that test in there.1K > But then I can't imagine why anyone would use either routine in the firstt > place. >o  E LIB$ADD_TIMES and LIB$SUB_TIMES treat the signs properly.  If you usedH LIB$ADDX and LIB$SUBX you have to understand what the sign of a quadwordI date/time signifies.  With LIB$SUB_TIMES, 100 - 90 = -10.  With LIB$SUBX,e 100 - 90 = 10.   ------------------------------  % Date: Tue, 24 Jul 2001 12:19:16 -0400r5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>e$ Subject: Re: Zero Quadword Time Poll/ Message-ID: <Bdh77.21$Yx2.477@news.cpqcorp.net>-  I The stated reason is to reduce special case logic needed when subtractingt) two absolute times that result in a zero.k  ? Dean Woodward wrote in message <3B585527.57B7482C@rdrop.com>...k >Hoff Hoffman wrote: >>I >>   One of the local engineers has suggested changing the interpretationhH >>   of a OpenVMS quadword time containing a zero from its existing to aG >>   new interpretation; from an absolute time (17-Nov-1858) to a deltao >>   time ("now", basically).  >rC >I find it useful as-is, since "17-NOV-1858" popping up as a resultiC >somewhere makes it immediately obvious All Is Not As It Should Be.y >sD >That said, what benefit was the engineer expecting to gain from the5 >new behavior that [s]he felt it'd be worth changing?    ------------------------------  # Date: Tue, 24 Jul 2001 17:39:21 GMTv2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)$ Subject: Re: Zero Quadword Time Poll/ Message-ID: <dpi77.27$Yx2.533@news.cpqcorp.net>e  v In article <a1777.9452$Px1.1089341@newsread2.prod.itd.earthlink.net>, "mulp" <michaelpettengill@earthlink.net> writes:6 :I'm not sure that I understand what the change is....  9 :What value would be used to represent no time specified?e  8   There is not now and the proposal does not offer such.  I :In the context of scheduling a timer event, 0 meaning 1858, has the same  :effect as NOW.i  C   No, that's layered behaviour based on the this-time-or-later that $   is inherent in certain scheduling.  L :I seem to recall that a zero is converted to -1 when queuing a timer entry;K :as I recall this was done so that when a driver queued a timer with a zerooD :value inside a timer  callback it didn't result in a loop since theI :interface promised that the callback wouldn't occur until the next tick.o  D   You're thinking about timer events, not about the quadword itself.  0 :As noted, its used to indicate "not specified".  =   The absolute time 17-Nov-1858, and not the "not specified".f  I :For such a minor change, why even think about changing the behavior?  ItrK :can't be to improve any code.  Is this to make $FAO time conversion calledvA :with a null pointer and a pointer to zero return the same thing?n  B   This proposal involved a discussion of time, and particularly ofA   time calculations using knowledge of the quadword format.  WhentC   you subtract two absolute times to produce a delta time, you willeC   sometimes get and thus must special-case an absolute time (zero).     N  ---------------------------- #include <rtfaq.h> -----------------------------N       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com    N  --------------------------- pure personal opinion ---------------------------L    Hoff (Stephen) Hoffman   OpenVMS Engineering   hoffman#xdelta.zko.dec.com   ------------------------------  % Date: Tue, 24 Jul 2001 09:41:12 -0400M2 From: rdeininger@mindspring.com (Robert Deininger)> Subject: Re: [HSJ40] Bad Cache Battery hangs OpenVMS Cluster ?L Message-ID: <rdeininger-2407010941120001@user-2ive6ha.dialup.mindspring.com>  B In article <3b5c5ea3$1@news.kapsch.co.at>, eplan@kapsch.net wrote:   > So, my current plan is:U > M > 1) run with the currently good 2nd HSJ with WRITEBACK_CACHE units (4x RAID,  >         4x MIRROR) as before > K > 2) Look for used/new good cache batteries for HSJ40 on the retail market.uI >         (this is likely difficult, because the batteries dies much mores? >         often than the HSJ - we have now the 4th set of them)   J Does the end of your service contract mean you can't buy parts direct fromG Compaq?  Was this a voluntary ending of the contract, or did Compaq end J support for these widgets?   Ending a contract doesn't mean you expect theG hardware to run forever without service, it means you expect paying forhD per-call service will be cheaper than paying for the contract.  WithG batteries having a limited service life, buying a bunch of spares mightT have been a good idea...   -- d Robert Deininger rdeininger@mindspring.comg   ------------------------------   End of INFO-VAX 2001.408 ************************