1 INFO-VAX	Fri, 20 Jul 2001	Volume 2001 : Issue 400       Contents:, Re: ??== DCPS: Locking trays on a HP4100DTN., Re: ??== DCPS: Locking trays on a HP4100DTN., Re: ??== DCPS: Locking trays on a HP4100DTN. Re: A Primrose Path.../ Re: Access port information from an FTP session 0 Re: Adding an Alpha processor - any VMS changes?( 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:  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: Basic quesitons from a newbie ! Re: Basic questions from a newbie  Re: Blast From the Past  Re: Blast From the Past  Re: Blast From the Past  Re: Blast From the Past  Re: Blast From the Past  Britannica.com and DECompaQ ! Re: Compaq have committed suicide  Re: Creating TK50 images Re: Creating TK50 images Re: Creating TK50 images Re: Creating TK50 images Re: Creating TK50 images Re: Creating TK50 images GS240 systems??? Re: GS240 systems??? Re: GS240 systems??? Re: No chance for OpenVMS  Re: Oracle dead on VMS? ' Oracle Resource monitoring for OpenVMS? + Re: Oracle Resource monitoring for OpenVMS?  Process adopts Itanium Re: Process adopts Itanium Re: Process adopts Itanium Re: Process adopts Itanium Re: Process adopts Itanium Re: Process adopts Itanium Re: Process adopts Itanium Re: Process adopts Itanium Re: Process adopts Itanium Re: Process adopts Itanium Re: Process adopts Itanium Re: Process adopts Itanium Re: Process adopts Itanium RE: Process adopts Itanium$ Re: Terry Shannon Tech Talk on IA-64$ Re: Terry Shannon Tech Talk on IA-64$ Re: Terry Shannon Tech Talk on IA-64$ RE: Terry Shannon Tech Talk on IA-64$ Re: Terry Shannon Tech Talk on IA-64$ Re: Terry Shannon Tech Talk on IA-64$ Re: Terry Shannon Tech Talk on IA-641 Re: The death of VMS has been greatly exaggerated 1 RE: The death of VMS has been greatly exaggerated  Re: VAX qbus problemP Re: VMS declared Cool and Unhackable at DE FCON9 hackers convention i nLas Vegas( VMS remains secure at DEFCON hacker fest, Re: VMS remains secure at DEFCON hacker fest Re: VMS Trivia Question  VMS Trivia Question  Re: VMS Trivia Question  Re: VMS Trivia Question  Re: VMS Trivia Question  RE: VMS Trivia Question 
 Re: XAW/XMU ? 
 Re: XAW/XMU ?  Re: Your reply on GSDFULL  Re: Zero Quadword Time Poll  Re: Zero Quadword Time Poll  Re: Zero Quadword Time Poll  Re: Zero Quadword Time Poll  Re: Zero Quadword Time Poll  Re: Zero Quadword Time Poll  Re: Zero Quadword Time Poll  Re: Zero Quadword Time Poll  Re: Zero Quadword Time Poll  Re: Zero Quadword Time Poll  Re: Zero Quadword Time Poll  [FS] Symmetrix EMC2 5200- [VMS PIR] More phases in startup phase file ? 1 Re: [VMS PIR] More phases in startup phase file ?   F ----------------------------------------------------------------------  % Date: Fri, 20 Jul 2001 11:41:41 +0200 , From: aus@vim.uni-wuerzburg.de (Hans M. Aus)5 Subject: Re: ??== DCPS: Locking trays on a HP4100DTN. D Message-ID: <aus-2007011141410001@wvia48.virologie.uni-wuerzburg.de>  ; In article <190720011126494004%paul.r.anderson@compaq.com>, ! paul.r.anderson@compaq.com wrote:   F > In article <aus-1907010857120001@wvia48.virologie.uni-wuerzburg.de>,/ > Hans M. Aus <aus@vim.uni-wuerzburg.de> wrote:  > N > > In the HP printer utility program, we can lock a tray by selecting a paperL > > type (form) other than "plain"; for example, "recycled". Now, however, aM > > DCPS job won't print because of a HP form mismatch. How do I set the DCPS   > > queue form to HP "recycled"? > G > You can't.  DCPS currently does not specify or select media types.  A G > job sent to a specific tray should print from there regardless of the 3 > media type selected in the printer configuration.  > E > I went to the front panel of my HP LaserJet 4050 and changed tray 4 F > from PLAIN to RECYCLED.  My DCPS job printed from tray 4 just fine. B > Perhaps the HP utility program is doing something more than justG > setting the media type on the tray.  However, the HP LaserJet Utility D > on my Mac reflected that I had changed the media type and does not- > imply that any other settings were changed.  > N > > This, it seems to me, can get very complicated very fast. IMO, it would beD > > much easier to turn off automatic tray switching on the printer. > F > I agree, although I don't think HP has such a concept on this model. > G > Perhaps there is some combination of printer settings that is causing  > this behavior. >  > Paul  6 We tried printing again this morning with the HP4100.   3 1) Tray 2 was set to PLAIN and tray 3 to RECYCLED.    @ 2) From the DCPS queue, we could not print to tray 3 (RECYCLED).  I 3) When we printed to tray 2 (PLAIN), the HP4100 did not switch to tray 3 " (RECYCLED) after tray 2 was empty.  F 4) We use the HP4050 device control library modifications to DCPS 1.8.   --  B Cheers, Hans M. Aus, Wuerzburg, Germany,  aus@vim.uni-wuerzburg.de   ------------------------------  % Date: Fri, 20 Jul 2001 12:35:54 +0200 , From: aus@vim.uni-wuerzburg.de (Hans M. Aus)5 Subject: Re: ??== DCPS: Locking trays on a HP4100DTN. D Message-ID: <aus-2007011235540001@wvia48.virologie.uni-wuerzburg.de>   One more observation:   D The input tray option does not show up when I use the HP4050 Printer Utility on the HP4100.   --  B Cheers, Hans M. Aus, Wuerzburg, Germany,  aus@vim.uni-wuerzburg.de   ------------------------------  % Date: Fri, 20 Jul 2001 09:30:53 -0400 0 From: Paul Anderson <paul.r.anderson@compaq.com>5 Subject: Re: ??== DCPS: Locking trays on a HP4100DTN. ; Message-ID: <200720010930530958%paul.r.anderson@compaq.com>   D In article <aus-2007011141410001@wvia48.virologie.uni-wuerzburg.de>,- Hans M. Aus <aus@vim.uni-wuerzburg.de> wrote:   ? > From the DCPS queue, we could not print to tray 3 (RECYCLED).   % What error messages appear and where?   E > We use the HP4050 device control library modifications to DCPS 1.8.   E I was going to suggest you use the HP LaserJet 4000 modules from DCPS F V2.0, but I don't believe we made any changes to the 4000 code to makeG the 4050 work.  There are certainly no changes to SETINPUTTRAY module.  F However, you'd probably be better off making any site-specific changesF again to the latest code rather than continuing to use changes made on older modules.  D In article <aus-2007011235540001@wvia48.virologie.uni-wuerzburg.de>,- Hans M. Aus <aus@vim.uni-wuerzburg.de> wrote:   F > The input tray option does not show up when I use the HP4050 Printer > Utility on the HP4100.  G What input tray option?  The one that lets you specify media type?  And @ do you have a separate Printer Utility program for each printer?  ? Maybe there's a new feature in the 4100 that's making it behave G differently than the 4050, although I understood that the 4050 and 4100  are nearly identical.    Paul   --    Paul Anderson   OpenVMS Engineering    Compaq Computer Corporation    ------------------------------  % Date: Fri, 20 Jul 2001 11:41:28 -0400 2 From: rdeininger@mindspring.com (Robert Deininger) Subject: Re: A Primrose Path... L Message-ID: <rdeininger-2007011141280001@user-2ive7e0.dialup.mindspring.com>  F In article <0ulb04Bj0j0v@malvm5.mala.bc.ca>, nothome@spammers.are.scum (Malcolm Dunnett) wrote:  8 > In article <13JUL01.16435261@thuria.waisman.wisc.edu>,6 karcher@thuria.waisman.wisc.edu (Carl Karcher) writes:H > > -> No, the ONLY thing DEC EVER produced that EVER became an industry standard > > -> was the VT-100.   > > G > > There's lots more. How about ethernet (jointly with Xerox and Intel 	 was it?)?  >  >   What about DLT?   E I dunno if that counts as "industry standard".  There are still a few + silly folks using other kinds of tape.  :-)   H It is an excellent design with amazing longevity.  I think we should add it to the list.    --   Robert Deininger rdeininger@mindspring.com    ------------------------------   Date: 20 JUL 2001 03:21:33 GMT4 From: karcher@vranix.waisman.wisc.edu (Carl Karcher)8 Subject: Re: Access port information from an FTP session6 Message-ID: <20JUL01.03213379@vranix.waisman.wisc.edu>  J In a previous article, "Ren  Schelbaum" <rene.schelbaum@datakom.at> wrote:  B ->The logical name SYS$REM_ID consists of "FTP_" followed by a hex* ->representation of the source ip Address.M ->You can check it in the login.com of the relevant account, which is, as far G ->as I can see, executed at each establishment of a control-connection.   K Be aware that this logical is NOT defined in TCPIP V5.0/5.0a. It IS defined  in V5.1 (thank you).     ------------------------------  # Date: Fri, 20 Jul 2001 16:43:05 GMT   From: jlsue <jlsuexxxz@home.com>9 Subject: Re: Adding an Alpha processor - any VMS changes? 8 Message-ID: <r7nglts4qr3cpb9v5a5fqu1aqsdp7sb521@4ax.com>    Um... even if it's MicroVMS 4.6? ;-) C On Fri, 13 Jul 2001 16:22:44 +0100, Alan Greig <a.greig@virgin.net>  wrote:  D >On Fri, 13 Jul 2001 09:49:48 -0400, "Tom Steuver" <steuver@nku.edu> >wrote:  > L >>If I have the license, is that all I need?  Will OpenVMS automatically seeL >>the new processor and adjust accordingly?  The reason why I ask is becauseN >>on other platforms (NT and Linux), the kernel needs to be recompiled for theD >>other processor.  Do I need to do something like this for OpenVMS? >  >Hey, this is VMS :-)  > C >With VMS you can take a system image from any old single processor C >Alphastation and boot  a 32 processor GS320 with it. A MicroVAX II > >image can boot a VAX 9000. Great for simple single boot image" >clustering and Disaster Recovery.   ------------------------------  % Date: Fri, 20 Jul 2001 03:24:46 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 1 Subject: Re: Alpha:  an invitation to communicate , Message-ID: <3B57DCBA.FE5328C1@videotron.ca>   Dennis O'Connor wrote:G > I agree.  But apparantly, Bill Todd doesn't let a lack of information ? > slow him down.  He just makes up whatever he needs.  And that  > was my point.   M Whether Bill Todd makes up information or uses actual facts doesn't make much J difference. The fact is that Compaq has set the scene to encourage FUD andH speculation and is doing nothing to address this problem in the "generalO public" and only cares about informing a porportion of the remaining customers.   K It can only be concluded that the FUD and speculation have been expected by L Compaq and Compaq calculated that it can live with it. My conclusion is thatH Compaq has calculated it can live without those customers who will leave# because they were left in the dark.   L The few Compaq apologists here probably work for some of those key customersK that Compaq has bothered informing so they don't quite understand where all  the FUD is coming from.    ------------------------------  % Date: Fri, 20 Jul 2001 10:55:44 +0200  From: "Magnus M" <mmad@tips.se> 1 Subject: Re: Alpha:  an invitation to communicate 3 Message-ID: <smS57.748$Ta.2006@news3.global-ip.net>   : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B5760EB.8F62C0C2@videotron.ca...   <... snip >   K > Lets face it, Compaq allowed the 8086 to almost catch up, and surpass for  someE > stuff the Alpha chip. Keeping Alpha would mean constant competition  against  > Intel to keep Alpha faster.   H "Allowed" the x86 to almost catch up? You do make it sound as if someone pressed C  a button labeled "Halt innovation, wait at barrier where Intel X86  performance will  threaten Alpha, then proceed"...  E  The fact is that with enough resources even a very ugly architecture F like the x86 can be improved speed-wise... From that point of view theG  Pentium III/IV are actually impressive _engineering_ feats speed-wise,   even if the ISAis still ugly.I I avoid coding x86 assembly like the plague, but then coding native Alpha K  assembly isn't too inspiring either, especially if the goal is to beat the  GEM backend in performance..  D Modern compiler technology has come a long way, and it might even beA advanced enough to make VLIW fly on IA64 given a couple of years, B the historical write-offs notwithstanding. Or perhaps the VLIWismsG of IA64 will be phased out in favour of OOO but I wouldn't bet on that.     H While it would be nice for someone who _really_ has a big picture of theJ  _technical_ (I repeat, technical, not financial or emotional) chip issues?  involved  (someone like the DEC Fellow Fred K hinted at) would @ demonstrate their  reasoning in detail to the comp.os.vms crowd,8  I'm afraid that in  the current climate of paranoia andE Usenet-rant-mode-on it wouldn't make much of a difference either way, , the current debate seems to have reached theD  "opinions set in stone, must  defend Honor at all costs" stage :-)|    B While many valid historical points are being made over and over byG different people (oh wait, perhaps comp.os.vms can start another thread > showing new, as yet unseen aspects on how DEC/CPQ marketing is?  incompetent and how in an ideal world VMS would become totally < mainstream!!) it tends to make the group look like more of a=  "Team OS/2" (remember that jolly bunch?) advocacy crowd than  a technical forum.   /magnus    ------------------------------  % Date: Fri, 20 Jul 2001 11:19:32 +0200  From: "Magnus M" <mmad@tips.se> 1 Subject: Re: Alpha:  an invitation to communicate 3 Message-ID: <NIS57.749$Ta.1921@news3.global-ip.net>   : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B57DCBA.FE5328C1@videotron.ca... > Dennis O'Connor wrote:I > > I agree.  But apparantly, Bill Todd doesn't let a lack of information A > > slow him down.  He just makes up whatever he needs.  And that  > > was my point.  > J > Whether Bill Todd makes up information or uses actual facts doesn't make muchL > difference. The fact is that Compaq has set the scene to encourage FUD andJ > speculation and is doing nothing to address this problem in the "generalF > public" and only cares about informing a porportion of the remaining
 customers.  H While I agree that Compaq created a brilliant opportunity for FUD in its handling of H the announcement (vs announcing the port first etc etc, all these points	 have been H made again and again on c.o.v by this time) I do think it's important to
 note that,# by induction we may find that since   3 Usenet != General public,   it may well follow that   , comp.os.vms  !=  General_VMS_public  (gasp!)  J On the whole, I feel that c.o.v has generated more competitor-friendly FUD withK its deliberate misreading  of the few facts available, than has Compaq with  its I admittedly poor tactics and/or incompetent  planning the of announcement.   J I personally think the "IPF-VMS" port is a good thing (although I do share someI of Brian S' concerns that some compromises may be bad for the exec, based J on my own readings of the IPF architecture docs which is not yet complete)G represents a good opportunity for the folks in Nashua to do some needed F changes to the current exec, filesystem and concurrency areas, just as Wildfire was with its NUMAisms.    /magnus    ------------------------------  % Date: Fri, 20 Jul 2001 06:34:09 -0400 ' From: "Bill Todd" <billtodd@foo.mv.com> 1 Subject: Re: Alpha:  an invitation to communicate ( Message-ID: <9j916q$i2n$1@pyrite.mv.net>  * "Magnus M" <mmad@tips.se> wrote in message- news:NIS57.749$Ta.1921@news3.global-ip.net...    ...   L > On the whole, I feel that c.o.v has generated more competitor-friendly FUD > withH > its deliberate misreading  of the few facts available, than has Compaq with > its K > admittedly poor tactics and/or incompetent  planning the of announcement.   I I'm going to ask you to provide examples of such 'deliberate misreading', H and then to provide data to support your contention that they constituteL 'misreading' (let alone deliberate).  I'll admit that a few contentions I'veB seen seem far from adequately supported, but that's a far cry from7 suggesting that all, or even the majority, of them are.2  8 Some of the 'few facts available' include the following:  G 1.  Compaq stated that its Alpha engineers told it that they would haveDK difficulty keeping Alpha's performance superior to IA64's.  Those engineersnG are stating (mostly privately, for obvious reasons) that this is, quiteh simply, a lie.  J 2.  Compaq and its apologists have been asserting that Alpha's developmentL was too costly to justify but have provided no quantitative support for thisG assertion (aside from Winkler's $300 million annual development figure,oD which without comparison to revenue, profit, and future potential isK meaningless).  I went to some effort to back up, with Compaq's own figures,hL my assertion that this claim is complete bullshit, and while plowing throughK such details is admittedly a pain in the ass I expect anyone who would likeaG to argue otherwise to make that effort and respond with data supportingn their own position.s  I In passing, you'll note that the diatribe Dennis provided in response did F nothing of the kind.  In fact, it can be fully summarized in 4 words -I "THAT'S NOT GOOD ENOUGH!!!" - since he provided absolutely nothing in theaI way of data to refute *any* of it.  This is exactly what I suggested he'drH say (he's not only unpleasant but boringly predictable) and why I didn'tF bother responding to his own earlier post:  he's here to argue, not to unearth facts.  G 3.  Compaq demonstrated absolutely no indication that it feels that itscD 'commitments' to customers are in the least way binding.  Instead ofI consulting with its customers about changing them, it did so unilaterally H (and hardly for the first time).  And instead of offering even a hint ofF apology for this, it attempted to bullshit them into accepting it as a positive step.  G Those facts speak to Compaq's competence, credibility, and honesty as adL vendor, and are relevant to at least some people.  I'd suggest that they areI *very* relevant to evaluating the likelihood that Compaq will continue to4J support VMS (which certainly shares a lot of the characteristics that seemF to have caused Compaq to drop Alpha) at all, let alone in any improved manner.    - bill   ------------------------------  % Date: Fri, 20 Jul 2001 12:56:42 +0200 * From: Alexis Cousein <al@brussels.sgi.com>1 Subject: Re: Alpha:  an invitation to communicaten/ Message-ID: <3B580E6A.8080700@brussels.sgi.com>N   JF Mezei wrote:M  = > I.E., the yields on IA64 would be much lower than on Alpha.     E Given identical design styles (and tools used to layout transistors),eA probably. But in this case, I'd say it's probably anyone's guess,e- as design methodologies are really different.e   -- w? <these messages express my own views, not those of my employer>i) Alexis Cousein				Senior Systems Engineer . SGI Belgium and Luxemburg		al@brussels.sgi.com   ------------------------------  % Date: Fri, 20 Jul 2001 13:07:55 +0200o* From: Alexis Cousein <al@brussels.sgi.com>1 Subject: Re: Alpha:  an invitation to communicatex/ Message-ID: <3B58110B.3090506@brussels.sgi.com>e   Alan Greig wrote:R   > G > And you work for Intel I see from your home page. Should have guessed-D > really. By calling Bill "another ignorant, conceited, hate-filled,? > crackpot USENET poser" you say more about yourself than Bill.? > L Now let's not demonise Intel here -- I think Dennis O'Connor's communication  E "style" is entirely personal, and not company-driven (and the fact heeG posts from a private e-mail account tells me that's the way he's seeingu	 it, too).7   -- w? <these messages express my own views, not those of my employer>e) Alexis Cousein				Senior Systems Engineere. SGI Belgium and Luxemburg		al@brussels.sgi.com   ------------------------------  % Date: Fri, 20 Jul 2001 14:00:37 +0200w From: "Magnus M" <mmad@tips.se>p1 Subject: Re: Alpha:  an invitation to communicatee3 Message-ID: <O3V57.750$Ta.1929@news3.global-ip.net>a  2 "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:9j916q$i2n$1@pyrite.mv.net... >a, > "Magnus M" <mmad@tips.se> wrote in message/ > news:NIS57.749$Ta.1921@news3.global-ip.net...n >  > ...  >tJ > > On the whole, I feel that c.o.v has generated more competitor-friendly FUDE > > withJ > > its deliberate misreading  of the few facts available, than has Compaq > with > > itsn? > > admittedly poor tactics and/or incompetent  planning the of 
 announcement.  >lK > I'm going to ask you to provide examples of such 'deliberate misreading', J > and then to provide data to support your contention that they constituteI > 'misreading' (let alone deliberate).  I'll admit that a few contentionsr I'veD > seen seem far from adequately supported, but that's a far cry from9 > suggesting that all, or even the majority, of them are.p  E I may have been harsh in characterizing it as misreading, I feel thatb? it boils down to diagnosing with lack of detailed data. Just as B that\s a bad idea in medical areas it can be dangerous in the tech arena.  : > Some of the 'few facts available' include the following: >)I > 1.  Compaq stated that its Alpha engineers told it that they would haveRC > difficulty keeping Alpha's performance superior to IA64's.  Thoseo	 engineersoI > are stating (mostly privately, for obvious reasons) that this is, quite  > simply, a lie.  E "Those engineers", are you referring to Brannons post on comp.arch? I5D don\t know him or what his position is within Alpha engineering, andL that is my whole point... His is the only public entry I've seen from anyoneH actively working on Alpha, and he didn\t get too specific. That's not toK say I distrust him in any way, I just don't consider that enough iformation0 to concludeh that either L 1) EV8 would not have been delayed several years, if one takes a statistical'     view based on EV6 speedups and EV7. 6 2) IA 64 arch rev 3 would not have been as fast anyway   _or_  G 1) EV8 would have shipped on time, would have been cheap to realize and5,    suffered no engineering issues whatsoeverL 2) IA 64 is forever doomed and no mount of engineering can save it from ever<     becoming a performance leader, no matter the investment.  I You may have truly excellent sources within Alpha engineering but if they G are private it\s also "just hearsay".. They could be anything from 100%  rightaC to upset that their projects got cancelled without me being able to2 distinguish.K Therefore I try not to buy into either side of the whole argument and "wait  it
 out" for now.a  L > 2.  Compaq and its apologists have been asserting that Alpha's developmentI > was too costly to justify but have provided no quantitative support foru thisI > assertion (aside from Winkler's $300 million annual development figure,oF > which without comparison to revenue, profit, and future potential isD > meaningless).  I went to some effort to back up, with Compaq's own figures,F > my assertion that this claim is complete bullshit, and while plowing throughdH > such details is admittedly a pain in the ass I expect anyone who would likeI > to argue otherwise to make that effort and respond with data supportingr > their own position.t  D I agree, but those are mostly figures based on history, and the chip businessI is complex enough that I don't see what it says about the economy of EV8, H and post-EV8 development. EV9 wasn\t even in/house yet was it, with work done with some university?  K > In passing, you'll note that the diatribe Dennis provided in response dideH > nothing of the kind.  In fact, it can be fully summarized in 4 words -K > "THAT'S NOT GOOD ENOUGH!!!" - since he provided absolutely nothing in thetK > way of data to refute *any* of it.  This is exactly what I suggested he'daJ > say (he's not only unpleasant but boringly predictable) and why I didn'tH > bother responding to his own earlier post:  he's here to argue, not to > unearth facts.  I As I said, don't assume that I agree with Dennis' diatribe just because I > thik we lack estimating data to paint a full picture. I don't.    I > 3.  Compaq demonstrated absolutely no indication that it feels that its F > 'commitments' to customers are in the least way binding.  Instead ofK > consulting with its customers about changing them, it did so unilaterally J > (and hardly for the first time).  And instead of offering even a hint ofH > apology for this, it attempted to bullshit them into accepting it as a > positive step.  I I agree with this but then I can't say I  find many big corporations thati  are much better in this respect.G I do feel that there is paranoia in c.o.v, often "Compaq management" isoC given vast powers for creating conspiracies to shaft its users when.E cluelessness and lack of understanding the value of unique technology,$ is a much more likely explanation...  I > Those facts speak to Compaq's competence, credibility, and honesty as a J > vendor, and are relevant to at least some people.  I'd suggest that they are-K > *very* relevant to evaluating the likelihood that Compaq will continue tojL > support VMS (which certainly shares a lot of the characteristics that seemH > to have caused Compaq to drop Alpha) at all, let alone in any improved	 > manner.o  H ... And yet one finds  people in this group cry "I'll switch to Sun!!!", would you rateJ Sun higher in ANY of those areas? Competence in marketing, yes ok they areC much better at that..Competence in building dependable systems? :-)SE (I'm sure I will attract an Andrew attack here, *must remember not toaF  spill even a drop of blood into water when there are marketing sharks nearby...*)   7 Credibility, well yes in stubbornly supporting an aginge architecture...oB Honesty? Give me a break... Just look at their homepage, more full7 of FUD than any other big player....  ECC, say no more.o  F IMHO, Sun will probably end up on IA64 as well, and while I think it's better strategy J and corporate tactics to string the users along until it becomes much more evident-K  that the Borg is about to assimilate and that the others can't keep up fore whateverI reason, save possibly POWER with IBMs muscle, as an engineer I appreciate- being5  told now instead of them.  L  And no, I can\t prove the validity of this  future Bill, as much as I can't prove EV8 wouldoG have been cheaper/better/faster than post-Madison designs...  Do I wisha someone likeD Gordon Bell was still around around to "guide" the MBAs? Of course..  Then Alpha might have had theL momentum to justify much higher R/D expenditures, which in return might have1 meant fewer delays and a more aggressive roadmap.   G That fact is that Gordon B isn't, the roadmap post-EV56 has allowed thee competitors to gaine; on Alpha way before any of the current controversy started.   G  I'm typing this from a "Billybox" PC which has better memory bandwidthhJ than the EV6 DS10 next to it.  You may be perfectly convinced that EV8 and	 followonshL would have forever remained superior to any IA64 generation in the timeframe but  I'm not so sure..e  + Unprovable, simplistic historical argument:dJ   If Intel can make the x86 ISA fly like they have, a cleaner IA64 ISA can be made to flyL   much higher if you throw enough money on it. It ain't pretty, but elegance loses:*   more often than not even in engineering.  1 The above argument is enough for me to think that L  1) IA64 movemakes sense from 20000ft, and 56 years out. It is good for VMS.  ANDI  2) Alpha is the more elgeant, beautiful architecture which with _proper_  nursing       could have "won"...  I I believe the two views can be held at once, without resorting to quoting 3 F. Scott Fitzgerald's definition of an "artist" :-)d   /magnuso   ------------------------------  % Date: Fri, 20 Jul 2001 07:07:20 -0700a+ From: "Dennis O'Connor" <dmoc@primenet.com> 1 Subject: Re: Alpha:  an invitation to communicatep- Message-ID: <9j9dvm$3kk$1@nnrp1.phx.gblx.net>o  3 "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote ...b > Dennis O'Connor wrote:I > > I agree.  But apparantly, Bill Todd doesn't let a lack of informationeA > > slow him down.  He just makes up whatever he needs.  And thato > > was my point.i >t= > Whether Bill Todd makes up information or uses actual factsn > doesn't make much difference.   = With regard to the Compaq-Alpha issue, you're probably right.i: Bill Todd is just another foam-at-the-mouth USENET whiner,@ and will make little difference in the overall scheme of things.  ? However, I think it's just a bad thing for people to run around C spouting irrational, fabrication-based arguments about such things,t= especially when they demonize anyone who disagrees with them.iB Truth matters; people who think they can stack lie on lie and thenF attempt to cover it up using personal attacks should not be tolerated.  : So when a particularly egregious case of that pops up on a9 newsgroup I read, I do what I can to make it clear to theiA general readership that that is the case, and with the faint hopea? that the resulting embarrassment of the perpetrator of will getdB cause him or her to get a clue.  Sometimes that last even happens,  though not as often as I'd like.  D [ The only time I can't usually do that is when Intel is the target.=   As a non-employee of Compaq, for example, I can call people B   on it when they lie about Compaq.  But I can't for Intel becauseF   that's too close to "speaking for my employer", which I do not do. ]  = Some people think me doing this kind of stuff  is a "waste ofo? bandwidth", but opinions vary, of course: this _is_ USENET. :-)   ' It's been nice conversing with you, JF.r --3 Dennis O'Connor                   dmoc@primenet.comp. Vanity Web Page http://www.primenet.com/~dmoc/   ------------------------------  % Date: Fri, 20 Jul 2001 09:44:50 -0500e+ From: Christopher Smith <csmith@amdocs.com>s1 Subject: RE: Alpha:  an invitation to communicatenL Message-ID: <3B55D7F383B0D31197D9009027541CBF1170DA43@cmiexch1.cmi.itds.com>   > -----Original Message-----3 > From: Alexis Cousein [mailto:al@brussels.sgi.com]   6 > Now let's not demonise Intel here -- I think Dennis  > O'Connor's communication  L No need.  Intel does a pretty good job on its own.  Unfortunately it doesn't do as well as Compaq, though.    Regards,   Christ  ! Christopher Smith, Perl Developerl Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");a 'r  e   ------------------------------  % Date: Fri, 20 Jul 2001 11:02:05 -0400s' From: "Bill Todd" <billtodd@foo.mv.com>h1 Subject: Re: Alpha:  an invitation to communicate.( Message-ID: <9j9gt8$t5q$1@pyrite.mv.net>  * "Magnus M" <mmad@tips.se> wrote in message- news:O3V57.750$Ta.1929@news3.global-ip.net...l   ...w  G > I may have been harsh in characterizing it as misreading, I feel thateA > it boils down to diagnosing with lack of detailed data. Just as D > that\s a bad idea in medical areas it can be dangerous in the tech > arena.  I That depends.  If you have the luxury of being able just to wait and find H out how things play out, I absolutely agree that that's the thing to do,( since *nothing* is as good as hindsight.  C People who have to make decisions today, OTOH, have to use whatever  information they can get.n   >t< > > Some of the 'few facts available' include the following: > >oK > > 1.  Compaq stated that its Alpha engineers told it that they would haveaE > > difficulty keeping Alpha's performance superior to IA64's.  Those- > engineers-K > > are stating (mostly privately, for obvious reasons) that this is, quiteo > > simply, a lie. >:E > "Those engineers", are you referring to Brannons post on comp.arch?e  K That's one of three sources I know of.  Bob Kaplow's statement (the post tonL which Brannon responded) about what Alpha engineers told him is a second (ifJ he feels free to expand on it, that could be illuminating).  And a privateL communication expressing the same sentiments in more detail and in even moreI unequivocal terms than Brannon's (a somewhat impressive feat) is a third.u    IF > don\t know him or what his position is within Alpha engineering, and > that is my whole point...   K If you're only going to obtain information from people you know personally,eL then your ability to garner knowledge is going to be severely circumscribed.  F If Brannon states he is in Alpha engineering, then in the absence of aI statement from someone else claiming they know he is not I'm not sure whyhL you're inclined to doubt it.  From other posts of his I've seen in comp.arch: it's clear he's a technical rather than a management type.  3  His is the only public entry I've seen from anyone  > actively working on Alpha,  L That his is the only public entry from a Compaq employee stating that CompaqB lied through its teeth is hardly surprising.  What you should findI surprising is the lack of any public entries from Alpha engineers statingeB that Compaq told the truth:  if indeed that's the case, there's no! job-related reason not to air it.   ! > and he didn\t get too specific.f   Exactly what part of  K "This is a complete and total FABRICATION on the part of Compaq management. I Anyone who believes these cowardly words probably deserves to be lied to"r  '  do you feel requires more specificity?a   ...o  B > > 2.  Compaq and its apologists have been asserting that Alpha's developmentoK > > was too costly to justify but have provided no quantitative support fori > thisK > > assertion (aside from Winkler's $300 million annual development figure,iH > > which without comparison to revenue, profit, and future potential isF > > meaningless).  I went to some effort to back up, with Compaq's own
 > figures,H > > my assertion that this claim is complete bullshit, and while plowing	 > through.J > > such details is admittedly a pain in the ass I expect anyone who would > likeK > > to argue otherwise to make that effort and respond with data supportingt > > their own position.n >gF > I agree, but those are mostly figures based on history, and the chip
 > businessK > is complex enough that I don't see what it says about the economy of EV8,cJ > and post-EV8 development. EV9 wasn\t even in/house yet was it, with work > done with some university?  J Then ask Compaq.  So far, all they've presented is a superficial assertion+ which their own figures call into question.d   ...o  K > > 3.  Compaq demonstrated absolutely no indication that it feels that itstH > > 'commitments' to customers are in the least way binding.  Instead of@ > > consulting with its customers about changing them, it did so unilaterallyL > > (and hardly for the first time).  And instead of offering even a hint ofJ > > apology for this, it attempted to bullshit them into accepting it as a > > positive step. >NK > I agree with this but then I can't say I  find many big corporations thatn" > are much better in this respect.  L I'm not really familiar with how IBM operates, but my distinct impression isG that it differs markedly from Compaq in the respects I mentioned above.dJ Information from someone better-acquainted with such details would be nice0 (Terry has thrown some bouquets their way IIRC).  I > I do feel that there is paranoia in c.o.v, often "Compaq management" is-E > given vast powers for creating conspiracies to shaft its users when<G > cluelessness and lack of understanding the value of unique technology & > is a much more likely explanation...  L I agree at least partly with that assessment - but will point out that thereK *were* active attempts to kill VMS under Palmer's management and that therecI *was* an actual plan about 2 years ago (i.e., under Compaq management) tof 'freeze' VMS by (IIRC) 2003.   >oK > > Those facts speak to Compaq's competence, credibility, and honesty as arL > > vendor, and are relevant to at least some people.  I'd suggest that they > arecJ > > *very* relevant to evaluating the likelihood that Compaq will continue toI > > support VMS (which certainly shares a lot of the characteristics thatS seemJ > > to have caused Compaq to drop Alpha) at all, let alone in any improved > > manner.- > J > ... And yet one finds  people in this group cry "I'll switch to Sun!!!", > would you rate# > Sun higher in ANY of those areas?s  K As I've suggested before, I tend to look to IBM as a good model in a lot ofvL areas these days.  Sun I'm not well acquainted with, but I think they are atB least committed to their own technology (very much unlike Compaq).  )  Competence in marketing, yes ok they aree > much better at that..e  K I don't know if they're much better at marketing their products than Compaq K is at marketing PC products.  Which is a particularly galling aspect of itsy neglect of Alpha.r  . Competence in building dependable systems? :-)G > (I'm sure I will attract an Andrew attack here, *must remember not tonH >  spill even a drop of blood into water when there are marketing sharks
 > nearby...*)e >n9 > Credibility, well yes in stubbornly supporting an agingn > architecture...e  K The point is, it works for them.  And if US can work for them, just imaginel, how well Alpha could have worked for Compaq.  D > Honesty? Give me a break... Just look at their homepage, more full9 > of FUD than any other big player....  ECC, say no more.   D I don't like FUD regardless of the source.  I don't know of an AlphaK hardware fiasco comparable to cachegate - and the NDA muzzling leaves about J as bad a taste on my mouth as some of Compaq's lies.  So I guess one wouldK have to evaluate the two companies quantitatively rather than qualitatively % in this area to come to a conclusion.o   >aH > IMHO, Sun will probably end up on IA64 as well, and while I think it's > better strategyoL > and corporate tactics to string the users along until it becomes much more	 > evident,I >  that the Borg is about to assimilate and that the others can't keep up  fore
 > whateverK > reason, save possibly POWER with IBMs muscle, as an engineer I appreciatet > beingn >  told now instead of them.  K That argument is inconsistent with the reluctance you expressed above aboutd) making assumptions without adequate data.t  I IA64 right now has zero market share, and far more cost-effective (not to I mention product-mature) competitors across the entire range of systems todH which it can be applied.  Current predictions for McKinley do not changeK this basic situation:  while its performance should be better than Merced's I (about double is still the conventional wisdom), this still won't make itaL the performance leader, let alone the most cost-effective solution, in *any* market segment.s  K With vigorous competition (especially from Alpha and POWER), there's a realjD possibility that IA64 could go the way of iAPX-432 - another complexG architecture that Intel plowed a lot of money into that went absolutelyuJ nowhere.  That possibility would have given Compaq profits beyond anythingJ it can remotely look forward to today - and could well be the reason Intel3 was willing to pay Compaq for getting rid of Alpha.e  G A more likely scenario would be that IA64 would make enough headway for J Intel not to kill it, but that this headway would be about as slow as NT'sF headway into the enterprise has been (since establishing mature systemH architectures in the mid-range and up takes time).  That could well meanK that IA64 would be the dominant architecture towards the end of the decade.rH In the meantime, Compaq could have had sufficient Alpha sales to justify= continued development costs far larger than the current ones.o  E About the worst scenario that seems at all likely would be that, withyH continued development through EV8 and decent marketing, Alpha could haveK returned substantial profits to Compaq for at least the next 5 years, while'K IA64 reached maturity.  During that time, ports of VMS and Tru64 could havekJ been accomplished to avoid the kind of situation we have today.  After EV8I was shipping, there would have been a far better understanding of Alpha'srL longer-term potential than exists today - and if that future looked limited,L an orderly transition could take place (the *customers* would then likely beB leading that transition, since they'd have a choice of platforms).  I Just the difference in Alpha profitability between announcing its funeral I today and holding off to see what the situation was like when EV8 was out.L the door could well have funded completion of EV8:  just look at last year'sL figures (though for comparison we'll have to wait to see how much effect the cancellation appears to have).   - bill   ------------------------------  % Date: Fri, 20 Jul 2001 12:08:45 -0400o- From: JF Mezei <jfmezei.spamnot@videotron.ca>a1 Subject: Re: Alpha:  an invitation to communicate , Message-ID: <3B58578C.F364FA90@videotron.ca>   Magnus M wrote:m5 > Usenet != General public,   it may well follow thatp > . > comp.os.vms  !=  General_VMS_public  (gasp!)  C When Richard Marcello came to Montreal this past February to make a H presentation on VMS, he asked how many had been receiving documents fromL Compaq, posters and the flashing balls. In a room of about 60 people, 4 or 5G raised their hands. He seemed quite surprised that so few were aware ofnL Compaq's efforts to reach customers. (In all fairness, most had come for the: tru64 presentation so they wouldn't know that VMS exists).  L Of those who raised their hands, I would be willing to bet that the majorityL got on Sue's list because they follow the newsgroup. (remember that there is* no longer an active user group in Canada).  N So while you may be right about comp.os.vms != general public, I would contendM that the "general public" is in fact in a much darker FUD than the folks hereC> because they only heard "Compaq is killing Alpha" in the news.   So you have in order: E 	-the "real" customers who are big enough to get a visit from Compaq.e: 	-the comp.os.vms crowd who get tidbits from the engineersL 	-the general public (remainder of VMS customers) who are in total darkness.   ------------------------------  % Date: Fri, 20 Jul 2001 12:34:54 -0400i- From: JF Mezei <jfmezei.spamnot@videotron.ca>i1 Subject: Re: Alpha:  an invitation to communicaten, Message-ID: <3B585DAC.A60874BE@videotron.ca>   Magnus M wrote:rG > I may have been harsh in characterizing it as misreading, I feel thataA > it boils down to diagnosing with lack of detailed data. Just as D > that\s a bad idea in medical areas it can be dangerous in the tech > arena.    M Your wife acts strangely but won't tell you what is going on. Are you telling I me that because you have no facts, you will not try to understand what ispJ going on with the wife and just let her act strangely until she decides to give you information ?  C Compaq has announced a major change in direction. Compaq has broken I commitments it made recently to customers. Yet, there is very little hardsL information on what Compaq's tru intents are. And its stated intents are notG quite beleiveable because of conflicting stories. (eg: claim that Alpha ! wouldn't be able to keep up etc).t  L It is the customer who doesn't wonder what the hell is going on and tries toD understand where Compaq is truly going who is the stupid one here.    M Are you so loyal to VMS that even if Compaq were to announce it is giving VMSnM patents and engineers to Microsoft, that you would find the silver lining andr5 beleive that Compaq has good intentions towards VMS ?   E Compaq has not yet shown that it really cares about VMS. The previouseK administration has admitted it wanted to get rid of VMS.  Why should anyoneo; have confidence that Compaq intends to make VMS succesful ?   G The only credible statement from Compaq is that Compaq will continue to N support VMS for existing customers. And this is backed up by Compaq willing to; spend enough money to port VMS to IA64 since Alpha is dead.e  G Do you want an athlete in a hospital on life-support, or do you want anS8 athlete on the track competeing against other athletes ?  M Compaq has credibility when it says it doesn't intend to pull the plug on therN life support for VMS. But there are no indications that I can see that lead meN to beleive that Compaq intends to put VMS back on its feet and make it competeL agressively. If Compaq starts to put some money towards that, then perhaps IM will beleive it. If Capellas starts to mention VMS when/if he appears on CNN,w# then I might start to believe this.s  L But until then, I see absolutely no indication that Compaq intends to do any& more than to keep VMS on life support.  F > "Those engineers", are you referring to Brannons post on comp.arch?   M Even in the Digital days, engineers and documents produced about Alpha showed L a long term superiority of Alpha versus IA64 because of Alpha's architectureI which allows more versatility on making all sorts of fancy optimisations.b  L And what do you make of a company which one week has documents posted on itsM web site touting the superiority of Alpha and its bright future, and the nextnI week states that Alpha couldn't keep up and is therefore being ditched ineL favour of the architecture which the week before was being called "inferior" by the same company ?o  P Do you not agree that a company which does that tends to lose much credibility ?  I > I do feel that there is paranoia in c.o.v, often "Compaq management" issE > given vast powers for creating conspiracies to shaft its users whennG > cluelessness and lack of understanding the value of unique technologye& > is a much more likely explanation...  J Please remember that those that have been with VMS for a long time learnedN their lesson to distruss a vendor which acts like Compaq is acting because the- previous owner (Digital) shafted us big time.n  L We were fooled once and now we have our eyes wide open to detect if the sameJ thing is about to happen. And Compaq is aware that long time customers are weary of broken promises.     J > ... And yet one finds  people in this group cry "I'll switch to Sun!!!", > would you rateL > Sun higher in ANY of those areas? Competence in marketing, yes ok they areE > much better at that..Competence in building dependable systems? :-)c  L But very few if any would question Sun's commitments to its own products. IfG you switch to Sun, you won't have to worry about Sun trying to make yousJ convert to NT down the road. If you switch to Sun, you know you are buyingI into Sun's core products. If you stay with VMS, you wonder if Compaq evenwM knows it has VMS because it rarely talks about it and takes decisions such asiI killing Alpha before getting a full evaluation from VMS engineers of whatn# would be involved in going to Ia64.u   ------------------------------  % Date: Fri, 20 Jul 2001 18:58:21 +0200- From: "Magnus M" <mmad@tips.se>:1 Subject: Re: Alpha:  an invitation to communicatem3 Message-ID: <XqZ57.755$Ta.2043@news3.global-ip.net>.  2 "Bill Todd" <billtodd@foo.mv.com> wrote in message" news:9j9gt8$t5q$1@pyrite.mv.net... >s, > "Magnus M" <mmad@tips.se> wrote in message/ > news:O3V57.750$Ta.1929@news3.global-ip.net...  >a > ...aG > That his is the only public entry from a Compaq employee stating thata CompaqD > lied through its teeth is hardly surprising.  What you should findK > surprising is the lack of any public entries from Alpha engineers stating D > that Compaq told the truth:  if indeed that's the case, there's no# > job-related reason not to air it.s > # > > and he didn\t get too specific.  >m > Exactly what part of >hA > "This is a complete and total FABRICATION on the part of Compaq  management.sK > Anyone who believes these cowardly words probably deserves to be lied to"a >g) >  do you feel requires more specificity?i  K I meant technically specific, that was upset and felt that lies were spread  is obvious.nJ I would have been interested in figures for EV8 based on simulations, more detail.:   > >oH > > I agree with this but then I can't say I  find many big corporations that$ > > are much better in this respect. >sK > I'm not really familiar with how IBM operates, but my distinct impressiono isI > that it differs markedly from Compaq in the respects I mentioned above.nL > Information from someone better-acquainted with such details would be nice2 > (Terry has thrown some bouquets their way IIRC).  D On the other hand IBM is infamous for killing off excellent internal projectsI in favour of bloated replacements... I remember Jim Gray stating (in  theyG System R reunion notes) that someone had had an excellent product idea,  "WhichI of course at IBM meant was a perfect guarantee that the project would getB cancelled"). >iK > > I do feel that there is paranoia in c.o.v, often "Compaq management" is G > > given vast powers for creating conspiracies to shaft its users wheniI > > cluelessness and lack of understanding the value of unique technologyi( > > is a much more likely explanation... > H > I agree at least partly with that assessment - but will point out that theretG > *were* active attempts to kill VMS under Palmer's management and that  thererK > *was* an actual plan about 2 years ago (i.e., under Compaq management) to  > 'freeze' VMS by (IIRC) 2003. >h  H I agree  that Palmer wanted to kill off VMS desperately but that doesn't makeL the current paranoia less tiresome when it takes on "X files"-proportions... :-)    > > K > > > Those facts speak to Compaq's competence, credibility, and honesty asa aaI > > > vendor, and are relevant to at least some people.  I'd suggest thate they > > aredL > > > *very* relevant to evaluating the likelihood that Compaq will continue > toK > > > support VMS (which certainly shares a lot of the characteristics that  > seemL > > > to have caused Compaq to drop Alpha) at all, let alone in any improved
 > > > manner.i > >nL > > ... And yet one finds  people in this group cry "I'll switch to Sun!!!", > > would you rate% > > Sun higher in ANY of those areas?o >tJ > As I've suggested before, I tend to look to IBM as a good model in a lot ofK > areas these days.  Sun I'm not well acquainted with, but I think they arey atD > least committed to their own technology (very much unlike Compaq). >t  G In strictly technical terms I'd agree, solid hardware, solid OS in AIX,n	 "serious"  engineering.  0 > Competence in building dependable systems? :-)I > > (I'm sure I will attract an Andrew attack here, *must remember not tocJ > >  spill even a drop of blood into water when there are marketing sharks > > nearby...*)  > >w; > > Credibility, well yes in stubbornly supporting an aging  > > architecture...i >lE > The point is, it works for them.  And if US can work for them, just  imagineq. > how well Alpha could have worked for Compaq. >sF > > Honesty? Give me a break... Just look at their homepage, more full; > > of FUD than any other big player....  ECC, say no more.g >e, > I don't like FUD regardless of the source. <...>i  J Agreed, but the very same reason that makes me respect IBM as a technologyH company makes me distrust Sun... Too much positioning, too much politicsJ and religion and too little "solid tech", appearance-wise. And appearancesG are important, just as we've seen fmr the way Compaq management handledI the Alpha/IPF announcement.i   > >oJ > > IMHO, Sun will probably end up on IA64 as well, and while I think it's > > better strategysI > > and corporate tactics to string the users along until it becomes much  more > > evident K > >  that the Borg is about to assimilate and that the others can't keep upg > fori > > whateverB > > reason, save possibly POWER with IBMs muscle, as an engineer I
 appreciate	 > > beingd > >  told now instead of them. >nG > That argument is inconsistent with the reluctance you expressed above  abouta+ > making assumptions without adequate data.   K But that's why I added IMHO, it's just my gut feeling and I'm not saying itw has anyt  more validity more than that :-)  E < valid points about IA64s current market state removed for brevity >s   >tI > A more likely scenario would be that IA64 would make enough headway for L > Intel not to kill it, but that this headway would be about as slow as NT'sH > headway into the enterprise has been (since establishing mature systemJ > architectures in the mid-range and up takes time).  That could well meanE > that IA64 would be the dominant architecture towards the end of then decade.dJ > In the meantime, Compaq could have had sufficient Alpha sales to justify? > continued development costs far larger than the current ones.e  K I can agree with this, but the question is _how far_ larger would they havea to be,J if we for a moment assume they need to be drastically increased to keep up with post-McKinley designs?o  G > About the worst scenario that seems at all likely would be that, withkJ > continued development through EV8 and decent marketing, Alpha could haveG > returned substantial profits to Compaq for at least the next 5 years,h whileaH > IA64 reached maturity.  During that time, ports of VMS and Tru64 could haveL > been accomplished to avoid the kind of situation we have today.  After EV8K > was shipping, there would have been a far better understanding of Alpha'srE > longer-term potential than exists today - and if that future lookedb limited,K > an orderly transition could take place (the *customers* would then likely  beD > leading that transition, since they'd have a choice of platforms).  K If your assumption about the economics involved is correct, then I agree itu: would have been a much better strategy on Compaq's behalf.  K > Just the difference in Alpha profitability between announcing its funeraldK > today and holding off to see what the situation was like when EV8 was outbG > the door could well have funded completion of EV8:  just look at lasta year'sJ > figures (though for comparison we'll have to wait to see how much effect thet  > cancellation appears to have).  J Sadly, with the way the announcement was handled, you might be right about that,t& if the sales slump really is that big.   > - bill   /magnust   ------------------------------  % Date: Fri, 20 Jul 2001 13:36:17 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>r1 Subject: Re: Alpha:  an invitation to communicates, Message-ID: <3B586C0A.A0A86CC1@videotron.ca>   Bill Todd wrote:M > With vigorous competition (especially from Alpha and POWER), there's a reald5 > possibility that IA64 could go the way of iAPX-432 g  H I don't think so because there are already too many commitments from box$ makers to use IA64. HP for instance.  K >> architectures in the mid-range and up takes time).  That could well mean M > that IA64 would be the dominant architecture towards the end of the decade.bJ > In the meantime, Compaq could have had sufficient Alpha sales to justify? > continued development costs far larger than the current ones.c  I Had Compaq announced a port of VMS to IA64 a few weeks ago, but continuedoF commitment to Alpha, I think that many would not have trusted Compaq'sM commitment to Alpha and decided that Compaq was out to kill Alpha. The resultwN may have been the same because Compaq has so little credibility to begin with.  J Besides, remember that the goal of killing alpha was to get a wad of moneyI from Intel to buy the stuff that will allow Compaq to implement that "180nJ days" stuff. Had Compaq announced a port of VMS to IA64 without killing ofE Alpha, where would the money to pay for the VMS port have come from ?a  J I think that the only way for Compaq to gain credibility would have been aI full commitment to Alpha as well a deploying low end Alpha servers, and auK return of NT to alpha. But that would have been considered a big risk which + the shareholders probably would not accept.a  J So in the end, Compaq's decision was probably the best one for Compaq. GetK tons of money killing alpha, work to keep the few VMS customers that matterlH (profits)  and hang the rest to dry. Quick and dirty, but it then allowsI Compaq to move quickly to establish its new core business of software and T services. And this action makes Compaq even better buddies with Intel and Microsoft.   ------------------------------  % Date: Fri, 20 Jul 2001 09:19:18 +0200t< From: "Martin Vorlaender" <martin.vorlaender@pdv-systeme.de>* Subject: Re: Basic quesitons from a newbie4 Message-ID: <9j8m24$mgfik$1@ID-56200.news.dfncis.de>  E David J. Dachtera schrieb in Nachricht <3B579D80.7A2AFC70@fsi.net>...  >Nick Paszty wrote:nB >> question 1.  in unix if i want to delete a directory continaingG >> subdirectories and files, i can force the delete command to do that.oG >> can this be done in vms.  from looking at help delete, i don't see a 9 >> similar option is there another command used for this?o >tJ > I've got rather a "dirty" DELTREE.COM proc. I thought I had posted it onG > the web, but apparently not because I don't really consider it "ready-F > for prime time", even though I find it useful. So, I've pasted it in% > after my sig. Use at your own risk.j  J I put the rather sophisticated DELTREE.COM (by Rob Young and others) I useG on my website under http://www.pdv-systeme.de/users/martinv/deltree.comwI As the included "read me" says: "I assume no responsibility for misuse ofn this COM file."    cu,    Martin -- aJ One OS to rule them all       | Martin Vorlaender  |  VMS & WNT programmer7 One OS to find them           | work: mv@pdv-systeme.delJ One OS to bring them all      |   http://www.pdv-systeme.de/users/martinv/> And in the Darkness bind them.| home: martin@radiogaga.harz.de   ------------------------------  % Date: Fri, 20 Jul 2001 10:30:51 -0400 - From: "Richard D. Piccard" <piccard@ohio.edu>e* Subject: Re: Basic questions from a newbie( Message-ID: <3B584097.7CBB4475@ohio.edu>  H If this is a single-user system, OK.  But for a multi-user platform, theI system manager should be aware that ANALYZE/REPAIR will block all pending J I/O to the disk, a behavior that is more user-friendly than corrupting the disk, but not by much!  #                                 RDP      Didier Morandi wrote:n   > "Richard D. Piccard" wrote:r > >- > ../.."I > > There are probably more elegant ways, but I don't do it so often thatm > > it has been a problem. >e& > More elegant, I dunno, but faster... > ( > $ set file/nodir disk:[000000]fred.dir" > $ delete disk:[000000]fred.dir;*! > $ analyze/disk/repair/noconfirm  > $ set def disk:[syslost] > $ delete *.*.* >.= > There is also a DECUS TREEDEL.COM procedure lurking around.g >D > D. > (pure personal opinion :-)   --B ==================================================================B Dick Piccard                           Academic Technology ManagerB piccard@ohio.edu                                 Computer ServicesB http://oak.cats.ohiou.edu/~piccard/                Ohio University   ------------------------------  % Date: Fri, 20 Jul 2001 14:36:04 +0200  From: "Magnus M" <mmad@tips.se>t  Subject: Re: Blast From the Past3 Message-ID: <1BV57.752$Ta.2079@news3.global-ip.net>o  5 "Hamlyn Mootoo" <univms@bigfoot.com> wrote in messagec$ news:3B57AB3B.5909F50@bigfoot.com...( > Anybody remember reading this article? > By Stephanie Miles > Staff Writer, CNET News.coma  > January 26, 1998, 1:00 p.m. PT <...>d >tH > "This will definitely accelerate the demise of Alpha," Linley Gwennap,I > vice president of publications for market researchers MicroDesign, saiddA > today. "While it's possible that Alpha could have some superioreJ > performance, it's about how many R&D dollars Compaq wants to invest in a& > technology that's not the standard." >i  J Gwennap has seldom said  good  things about the Alpha. Look at the currentE Microprocessor Watch, issue 81 for more of the same and references to $ Gwennap speaking about Alpha in '96.   /magnuse   ------------------------------  % Date: Fri, 20 Jul 2001 09:25:28 -0400d( From: Hamlyn Mootoo <univms@bigfoot.com>  Subject: Re: Blast From the Past+ Message-ID: <3B583148.5C05620D@bigfoot.com>    Magnus M wrote:  > 7 > "Hamlyn Mootoo" <univms@bigfoot.com> wrote in message & > news:3B57AB3B.5909F50@bigfoot.com...* > > Anybody remember reading this article? > > By Stephanie Miles > > Staff Writer, CNET News.comt" > > January 26, 1998, 1:00 p.m. PT > <...>t > >tJ > > "This will definitely accelerate the demise of Alpha," Linley Gwennap,K > > vice president of publications for market researchers MicroDesign, said C > > today. "While it's possible that Alpha could have some superior L > > performance, it's about how many R&D dollars Compaq wants to invest in a( > > technology that's not the standard." > >  > L > Gwennap has seldom said  good  things about the Alpha. Look at the currentG > Microprocessor Watch, issue 81 for more of the same and references toe& > Gwennap speaking about Alpha in '96. > 	 > /magnusy  G If you have a point in here somewhere, please make it plain, because itfF escapes me.  If I attempt to infer any conclusion from your statement,B it would be that "It doesn't matter if someone was dead right on aH prediction from 2 1/2 years ago; if they say "bad" things, they are meanF ogres and it offends my genteel sensibilties, so I'm going to stick my= fingers in my ears and go la la la la la and say that I'm notn listening."eG Since I know you couldn't POSSIBLY mean that, please clarify what it iseE you do mean.  I say bad things about people sticking metal forks intoeH toasters to retrieve their lodged bagels, but this doesn't mean that I'm wrong.   HM   ------------------------------  % Date: Fri, 20 Jul 2001 15:53:06 +0200l From: "Magnus M" <mmad@tips.se>f  Subject: Re: Blast From the Past3 Message-ID: <gJW57.753$Ta.2074@news3.global-ip.net>   5 "Hamlyn Mootoo" <univms@bigfoot.com> wrote in messagee% news:3B583148.5C05620D@bigfoot.com...v >e >  > Magnus M wrote:  > >a9 > > "Hamlyn Mootoo" <univms@bigfoot.com> wrote in messageo( > > news:3B57AB3B.5909F50@bigfoot.com..., > > > Anybody remember reading this article? > > > By Stephanie Miles! > > > Staff Writer, CNET News.comi$ > > > January 26, 1998, 1:00 p.m. PT	 > > <...>c > > >oL > > > "This will definitely accelerate the demise of Alpha," Linley Gwennap,H > > > vice president of publications for market researchers MicroDesign, saidE > > > today. "While it's possible that Alpha could have some superior!L > > > performance, it's about how many R&D dollars Compaq wants to invest in an* > > > technology that's not the standard." > > >c > >bF > > Gwennap has seldom said  good  things about the Alpha. Look at the currentiI > > Microprocessor Watch, issue 81 for more of the same and references toa( > > Gwennap speaking about Alpha in '96. > >n > > /magnus  > I > If you have a point in here somewhere, please make it plain, because itaH > escapes me.  If I attempt to infer any conclusion from your statement,D > it would be that "It doesn't matter if someone was dead right on aJ > prediction from 2 1/2 years ago; if they say "bad" things, they are meanH > ogres and it offends my genteel sensibilties, so I'm going to stick my? > fingers in my ears and go la la la la la and say that I'm notp
 > listening."iI > Since I know you couldn't POSSIBLY mean that, please clarify what it is G > you do mean.  I say bad things about people sticking metal forks intoiJ > toasters to retrieve their lodged bagels, but this doesn't mean that I'm > wrong.  @ My point was simply that Gwennap has been biased against Alpha'sC chances a long time now, so seeing him say something to that effectiJ is hardly a revelation if one has read his writings for a couple of years.  B A more general point is perhaps that if you go back 2 1/2 years inB this industry you  will always find someone who was "right", aboutH a wide variety of predictions.  At the time, so little of IA64 was knownG technically that it has little relevance to the current state of thingstB other than the more general truth that architectures with a lot of= muscle behind them have a good chance of becoming dominant...r  @  I didn't imply he is a moron or a mean ogre, and I did read the8 article at the time... What was the point of posting it?   /magnuse   ------------------------------  % Date: Fri, 20 Jul 2001 10:59:32 -0400o( From: Hamlyn Mootoo <univms@bigfoot.com>  Subject: Re: Blast From the Past+ Message-ID: <3B584754.1C98B9B7@bigfoot.com>s   Magnus M wrote:f > 7 > "Hamlyn Mootoo" <univms@bigfoot.com> wrote in messages' > news:3B583148.5C05620D@bigfoot.com...i > >  > >c > > Magnus M wrote:n > > >o; > > > "Hamlyn Mootoo" <univms@bigfoot.com> wrote in messaged* > > > news:3B57AB3B.5909F50@bigfoot.com.... > > > > Anybody remember reading this article? > > > > By Stephanie Miles# > > > > Staff Writer, CNET News.comb& > > > > January 26, 1998, 1:00 p.m. PT > > > <...>n > > > >yN > > > > "This will definitely accelerate the demise of Alpha," Linley Gwennap,J > > > > vice president of publications for market researchers MicroDesign, > saidG > > > > today. "While it's possible that Alpha could have some superiornN > > > > performance, it's about how many R&D dollars Compaq wants to invest in > ai, > > > > technology that's not the standard." > > > >o > > >eH > > > Gwennap has seldom said  good  things about the Alpha. Look at the	 > current K > > > Microprocessor Watch, issue 81 for more of the same and references top* > > > Gwennap speaking about Alpha in '96. > > > 
 > > > /magnus  > >tK > > If you have a point in here somewhere, please make it plain, because itSJ > > escapes me.  If I attempt to infer any conclusion from your statement,F > > it would be that "It doesn't matter if someone was dead right on aL > > prediction from 2 1/2 years ago; if they say "bad" things, they are meanJ > > ogres and it offends my genteel sensibilties, so I'm going to stick myA > > fingers in my ears and go la la la la la and say that I'm not  > > listening."vK > > Since I know you couldn't POSSIBLY mean that, please clarify what it isrI > > you do mean.  I say bad things about people sticking metal forks into L > > toasters to retrieve their lodged bagels, but this doesn't mean that I'm
 > > wrong. > B > My point was simply that Gwennap has been biased against Alpha'sE > chances a long time now, so seeing him say something to that effectoL > is hardly a revelation if one has read his writings for a couple of years. > D > A more general point is perhaps that if you go back 2 1/2 years inD > this industry you  will always find someone who was "right", aboutJ > a wide variety of predictions.  At the time, so little of IA64 was knownI > technically that it has little relevance to the current state of thingspD > other than the more general truth that architectures with a lot of? > muscle behind them have a good chance of becoming dominant...w > B >  I didn't imply he is a moron or a mean ogre, and I did read the: > article at the time... What was the point of posting it? > 	 > /magnusl  H The point of posting it is pretty obvious (to most people with a pulse).  G Incidentally, I suppose you think the analyst Nathan Woodhead is on parvD with the ORACLE, and should be consulted before all future corporateG moves are made.  Or perhaps you think a combination of tea leaves, deadgH memory chips, and goat entrails might provide some clue as to the actualH future plans of Compaq? How about trying common sense, and following theH money trail.  I've found that apparent bonehead moves of corporate execs? are usually not due to stupidity, but due to personal financiale
 incentive.  H In the article, Ashok Kumar also correctly predicted Alpha's demise.  IsE he a biased crackpot too, or just lucky.  Before you write him off as D just another 7-Eleven store clerk from the Simpsons, suppose you digH deeper into why he formulated his (CORRECT) conclusions.  And while yourG at it, you could do the same with Gwennap.  A manager I had a long time C ago told me something that sticks with me today: "Even if you don'tp? respect someones decisions, respect their position - until theyaH consistently prove themselves unworthy (like Mr. Woodhead).  As a matterG of fact, Nathan can probably be used as an extremely reliable indicatorHH of Compaq's future intentions - just take the exact opposite of whatever< he says - much like smiling Bob, previously of Digital fame.     HM   ------------------------------  % Date: Fri, 20 Jul 2001 18:34:05 +0200  From: "Magnus M" <mmad@tips.se>   Subject: Re: Blast From the Past3 Message-ID: <b4Z57.754$Ta.1995@news3.global-ip.net>n  5 "Hamlyn Mootoo" <univms@bigfoot.com> wrote in messaget% news:3B584754.1C98B9B7@bigfoot.com...d > J > The point of posting it is pretty obvious (to most people with a pulse). >uI > Incidentally, I suppose you think the analyst Nathan Woodhead is on parhF > with the ORACLE, and should be consulted before all future corporateI > moves are made.  Or perhaps you think a combination of tea leaves, deadsJ > memory chips, and goat entrails might provide some clue as to the actualJ > future plans of Compaq? How about trying common sense, and following theJ > money trail.  I've found that apparent bonehead moves of corporate execsA > are usually not due to stupidity, but due to personal financial  > incentive.  B I do not share your quest to know the workings in the inner circleI of upper management at Compaq, so your suggestion has little value to me,dD and nowhere did I indicate whether I thought Gwennap was incompetentI or not I merely stated that he had been consistent in his opinions on then: topic of Alpha (and on IA64's prospects, for that matter).  G I do find Paul DeMone's articles more interesting as an example, mostlyp0  because they are more technical than Gwennap's.  J > In the article, Ashok Kumar also correctly predicted Alpha's demise.  IsG > he a biased crackpot too, or just lucky.  Before you write him off as F > just another 7-Eleven store clerk from the Simpsons, suppose you dig: > deeper into why he formulated his (CORRECT) conclusions.  D Again you're putting words in my mouth..  You assume that I disagreeD with the analysis in the article, rather than with the usefulness ofJ posting an old article that offers no new information and will most likelyD only serve to spawn yet another "Compaq's management are evil/bozos/4 in the pocket of Bill Gates" whiner-thread in c.o.v.   >  And while your I > at it, you could do the same with Gwennap.  A manager I had a long time-E > ago told me something that sticks with me today: "Even if you don'tFA > respect someones decisions, respect their position - until theyiJ > consistently prove themselves unworthy (like Mr. Woodhead).  As a matterI > of fact, Nathan can probably be used as an extremely reliable indicator,J > of Compaq's future intentions - just take the exact opposite of whatever> > he says - much like smiling Bob, previously of Digital fame. >m  C I don't even know who mr Woodhead is, I'm not a manager and I don'tiE spend much time reading analysts reports, I am too busy writing code.e  ' And yes, that requires a pulse, Hamlyn.o   /magnuse   ------------------------------  % Date: Fri, 20 Jul 2001 13:02:28 -0300i) From: fabio_compaq@ep-bc.petrobras.com.brr$ Subject: Britannica.com and DECompaQL Message-ID: <OF2D00D2D9.DA6894B2-ON03256A8F.0057D746@ep-bc.petrobras.com.br>   Just for curiousitya   DECd  6 http://www.britannica.com/eb/article?eu=138383&tocid=0     andm   Compaq  6 http://www.britannica.com/eb/article?eu=138381&tocid=0     Regards    FC   ------------------------------   Date: 20 Jul 2001 14:21:39 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)l* Subject: Re: Compaq have committed suicide+ Message-ID: <9j9epj$ncd$2@info.cs.uofs.edu>   ' In article <3B579B8E.9A58D19B@fsi.net>,l4  "David J. Dachtera" <djesys.nospam@fsi.net> writes:- |> fabio_compaq@ep-bc.petrobras.com.br wrote:l |> > oC |> > I am not worried about the name of VMS, OpenVMS, iVMS, etc ...p |> > eL |> > I am worried about the lack of jobs ... I made investments in my careerN |> > in OpenVMS, but searching in brazilian jobs sites with almost 50.000 jobs- |> > there is no reference about "VMS" jobs !w |> oH |> I've found it useful to search for VMS or OpenVMS or VAX. You can addG |> DEC to that, but it can produce some unexpected results, just as VMSrE |> sometimes does. Many of the few job postings I find still refer tolH |> "DEC/VAX", even though the VAX processor line has been EOL'd for some
 |> years now.e  F Maybe, but a search of monster.com turns up a number of PDP-11/RSX-11M8 jobs so a handfull of DEC/VAX jobs wouldn't surprise me.   bill   -- iJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   n   ------------------------------   Date: 20 Jul 2001 13:54:18 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)t! Subject: Re: Creating TK50 imageso+ Message-ID: <9j9d6a$ncd$1@info.cs.uofs.edu>s  ( In article <9j7fpc$8op$1@news.IAEhv.nl>,%  "Hans Vlems" <hvlems@iae.nl> writes:rH |> Aren't you asking whether a copy of a save set from tape is possible?K |> If that is the case then the answer is yes. I'm somewhat confised by theh |> term "generate an image". |> tM |> If the TK50 contains the saveset MYFILE.BCK , then I'd mount the TK50 witht
 |> OVER=ID+ |> (not foreign) and copy the file to disk:s |>  $ copy MUA0:*.* []/log6 |> The save set may be copied to another tape or disk. |>  A Let me jump in here before this gets a lot more confusing than it  probably has to be.a   Simple problem.e  E I have MicroVMS 4.4 and Decnet (ENDNODE) for it, both on the originaltD TK50 distribution tape.  How do I move these tapes to something thatB can be FTPed or Emailed as an attachment in a form that will allow1 the tapes to be recreated on the destination end.-  B Ideally, someone will provide a command for the task on both ends.F Remembering that this MicroVMS 4.4 so there is no VMStar or C compilerI or TCPIP suite or any of the usual tools people are used to working with.s  D This is for a hobbyist licensed MicroVAX-II, but then I think people( probably had that part figured out.  :-)   bill   -- dJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   b   ------------------------------  % Date: Fri, 20 Jul 2001 11:34:13 -0400 ; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com> ! Subject: Re: Creating TK50 imagesr$ Message-ID: <3b584fc8$1@news.si.com>   >Is the command: >/3 >    $ BACKUP MUA0:[000000]*.* MYFILE.BCK /SAVE_SET* > G >the right way to generate an image of a TK50 (wich I suppose is called F >MUA0:), being able to restore it stright onto another TK50 elsewhere?  H Sorry, you can't generate a backup saveset _from_ a tape device.  If theI tape is ANSI-labeled, mount it and COPY it to somewhere on a disk.  If it I contains a backup saveset already, MOUNT it and COPY the saveset to disk. . Then COPY the saveset to the new TK cartridge. --A Brian Tillman                   Internet: tillman_brian at si.comtA Smiths Aerospace                          tillman at swdev.si.comn= 3290 Patterson Ave. SE, MS      Addresses modified to prevento< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  # Date: Fri, 20 Jul 2001 15:59:30 GMTt0 From: "P. Thompson" <thompson-nospam@new.rr.com>! Subject: Re: Creating TK50 imageseI Message-ID: <Pine.LNX.4.33.0107201058290.6479-100000@malacandra.localnet>"  I If you have access to Ultrix and a TK50 (or a TZ30? the scsi version) you J can use the itc.c program supplied with the examples subset for image tape copy.    On 19 Jul 2001, Cthulhu wrote:   > Is the command:  >u4 >     $ BACKUP MUA0:[000000]*.* MYFILE.BCK /SAVE_SET >sH > the right way to generate an image of a TK50 (wich I suppose is calledG > MUA0:), being able to restore it stright onto another TK50 elsewhere?  >  > 	duplicatingly,d
 > 	   CthulhuM >o >u   -- i* Leave the nospam in, correct email address   ------------------------------  % Date: Fri, 20 Jul 2001 18:49:50 +0200H  From: Paul Sture <paul@sture.ch>! Subject: Re: Creating TK50 images.+ Message-ID: <VA.00000400.1ae29487@sture.ch>r  B In article <9j9d6a$ncd$1@info.cs.uofs.edu>, Bill Gunshannon wrote:* > In article <9j7fpc$8op$1@news.IAEhv.nl>,' >  "Hans Vlems" <hvlems@iae.nl> writes:lJ > |> Aren't you asking whether a copy of a save set from tape is possible?M > |> If that is the case then the answer is yes. I'm somewhat confised by thes > |> term "generate an image". > |> oO > |> If the TK50 contains the saveset MYFILE.BCK , then I'd mount the TK50 with  > |> OVER=ID- > |> (not foreign) and copy the file to disk:  > |>  $ copy MUA0:*.* []/log8 > |> The save set may be copied to another tape or disk. > |> > C > Let me jump in here before this gets a lot more confusing than itA > probably has to be.g >  > Simple problem.o > G > I have MicroVMS 4.4 and Decnet (ENDNODE) for it, both on the originaltF > TK50 distribution tape.  How do I move these tapes to something thatD > can be FTPed or Emailed as an attachment in a form that will allow3 > the tapes to be recreated on the destination end.g > D > Ideally, someone will provide a command for the task on both ends.H > Remembering that this MicroVMS 4.4 so there is no VMStar or C compilerK > or TCPIP suite or any of the usual tools people are used to working with.  > F > This is for a hobbyist licensed MicroVAX-II, but then I think people* > probably had that part figured out.  :-) > C I didn't come across TK50s until after V5.0. Am I right in thinkinga3 that the tape contains S/A backup at the beginning?"  4 If so, then I'd expect something like the following:   $ mount mua0: /over=id( $ dir mua0: /output = tape.lis /column=1 $ copy /log mua0:*.* disk:[dir]s  8 (If doing this on a V4.n system, you may have to specify> a larger blocksize on the mount command (e.g. /BLOCKSIZE=8192) to get the copy to work.  ; Then ftp or DECnet those files across to the target system.t  = On the target system, initialize a tape and mount it as aboveN (_not_ /FOREIGN).u  E Then copy the files to the new tape in the same order as displayed inl< the directory listing. I'd copy the tape.lis file across and( edit it into a command procedure myself.  A (Strictly speaking, since VMS tape kits of that era were producedp? using the backup /INTERCHANGE qualifier, you may need to unpacka@ and repack the savesets as part of the initial read operation. IA only found I needed to do this if the copy from the original tapeg@ produced read errors. This unpack/pack functionality appeared inB VMSINSTAL at some stage, although I forget whether before or after V4.4.p   ___a
 Paul Sture Switzerland    ------------------------------  % Date: Fri, 20 Jul 2001 11:39:20 -0400l2 From: rdeininger@mindspring.com (Robert Deininger)! Subject: Re: Creating TK50 imagesnL Message-ID: <rdeininger-2007011139200001@user-2ive7e0.dialup.mindspring.com>  @ In article <3B573127.65B9109A@iee.org>, arcarlini@iee.org wrote:  % > There was a product that could copys' > savesets from one tape to another, itg+ > was called something like Saveset Managert+ > or something equally imaginative. I don'ty* > know whether it could cope with tapes in- > general or just tapes with backup savesets s
 > on them.  E Compaq still sells and supports Save Set Manager.  It was on the most C recent CONDIST CDs. Alas, it's not included in the hobbyist licenseG program.  J It it can recompute the error correction stuff, change the block size of aG saveset, and make up to 5 output copies of an input tape at once, among  other features.e  8 It only deals with backup savesets, not arbitrary tapes.  D SSM is a nice product; it ought to be advertised more aggressively. I Another such product is the defragmenter, Disk File Optimizer.  I've seenwG Compaq folks recommending Diskeeper from Executive Software, apparentlyfI not aware than VMS has it's own offering.  DFO is cheaper, more reliable,fJ and less quirky than Diskeeper, though the latter does have a few features
 DFO lacks.   -- o Robert Deininger rdeininger@mindspring.com    ------------------------------  % Date: Fri, 20 Jul 2001 13:17:14 -0400-- From: JF Mezei <jfmezei.spamnot@videotron.ca>:! Subject: Re: Creating TK50 imagesu+ Message-ID: <3B586795.A6C53AD@videotron.ca>h   Bill Gunshannon wrote:G > I have MicroVMS 4.4 and Decnet (ENDNODE) for it, both on the originaliF > TK50 distribution tape.  How do I move these tapes to something thatD > can be FTPed or Emailed as an attachment in a form that will allow3 > the tapes to be recreated on the destination end.5  I As I recall, these tapes are bootable this means that the first few files N contain what is needed for standalone backup. So the order of the files on the tape is probably important.   # I would therefore do the following:d $CREATE/DIR [TEMP] $SET DIR [TEMP]/VERSIONS=0 $SET DEF [TEMP]   $MOUNT/FOREIGN MUA0:/OVERRIDE=ID$ $DEFINE/USER SYS$OUTPUT FILELIST.LIS; $COPY/LOG MUA0:*.* []			! this will take a LONG LONG time !v $!  N You can replace the COPY command with an equivalent BACKUP and send the log toA a file (remember that the order of the files might be important).   F Then, you can package the files in [TEMP] into a single file by doing:V $BACKUP [TEMP]*.*;* [other_dir]MYSAVESET.SAV/SAVE	! this will include the FILELIST.LIS  > you then transfer that single large file to the target system.   on the target system:   ( $BACKUP MYSAVESET.SAV/SAVE $DISKx:[TEMP]  K you then edit FILELIST.LIS and turn it into a command procedure that copiesl the files in the right order.   M (I tried to get an example file from an old TK50 with VMS 5.4 but the processnF got stuck mounting the tape and is now in the dreaded RWAST which will- probably require a reboot - ALL YOUR FAULT !)m    K If you don't have a link betwene the two machines, consider using KERMIT to  transfer the files.v  N Also, you may wish to get the "FILE" utility from the decus stuff which allowsG you to output the complete file structrure/attribute to a file and then E re-apply it to that file. This way, if the files change format duringtT transport, you can reset the file structure. (equivalent of today's SET FILE/ATTRIB)   ------------------------------  % Date: Fri, 20 Jul 2001 09:43:13 -0400 . From: "Kenneth Randell" <kenr@datametrics.com> Subject: GS240 systems???.+ Message-ID: <9j9cgj$3ag$1@bob.news.rcn.net>i   The following came from:  L http://ftp.support.compaq.com/patches/public/Readmes/vms/dec-axpvms-vms721_s0 hadowing-v0600--4.README, which showed up today.  C   o  Fibrechannel devices cannot execute write logging Phase I.   ArC      benchmark  on  GS240  systems  was  consuming  needless cyclese(      issuing TQEs that serve no purpose.  I Is this a new system that I have not heard about, or someone's very largeo typo?a   Ken Randell    ------------------------------  % Date: Fri, 20 Jul 2001 10:58:25 -0300 ) From: fabio_compaq@ep-bc.petrobras.com.brs Subject: Re: GS240 systems??? L Message-ID: <OF21E161B2.B9599FD3-ON03256A8F.004CAF02@ep-bc.petrobras.com.br>  = It is a GS80+GS160 configuration. Or 3 x GS80 ... I believe !    Regc   FC        ? "Kenneth Randell" <kenr@datametrics.com> em 20/07/2001 10:43:13a  : Favor responder a "Kenneth Randell" <kenr@datametrics.com>             Info-VAX@Mvb.Saic.Comp       Assunto: GS240 systems???,     The following came from:  L http://ftp.support.compaq.com/patches/public/Readmes/vms/dec-axpvms-vms721_s  0 hadowing-v0600--4.README, which showed up today.  C   o  Fibrechannel devices cannot execute write logging Phase I.   AsC      benchmark  on  GS240  systems  was  consuming  needless cyclesi(      issuing TQEs that serve no purpose.  I Is this a new system that I have not heard about, or someone's very large  typo?T   Ken Randell    ------------------------------  # Date: Fri, 20 Jul 2001 15:20:33 GMTa2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) Subject: Re: GS240 systems???p3 Message-ID: <5%X57.1051$rc5.70150@news.cpqcorp.net>-  \ In article <9j9cgj$3ag$1@bob.news.rcn.net>, "Kenneth Randell" <kenr@datametrics.com> writes: ..D :  o  Fibrechannel devices cannot execute write logging Phase I.   AD :     benchmark  on  GS240  systems  was  consuming  needless cycles) :     issuing TQEs that serve no purpose.D :tJ :Is this a new system that I have not heard about, or someone's very large :typo?  (   Single bit displacement: GS140, AFAIK.    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: Fri, 20 Jul 2001 12:05:16 -0500l: From: "Scandora, Anthony \(35048\)" <scandora@cmt.anl.gov>" Subject: Re: No chance for OpenVMS+ Message-ID: <9j9ocg$2sk$1@milo.mcs.anl.gov>d  4 "David Mathog" <mathog@caltech.edu> wrote in message% news:3B55AA36.123E1878@caltech.edu...o > JF Mezei wrote:r >. > > Rudolf Wingert wrote:bK > > > today I red, that Andrew Butler of the Gardner Group gives OpenVMS no  > > > chance to be alive.nL > Unfortunately I agree with him - and Tru64 is even less likely to survive.  H The Gartner Group's predictions are often good reading, but one would be# foolish to take them too seriously.I   > <snip>  L > The thing that most amazes me about Compaq management is that they seem to thinks > thatD > by screwing their customer base over and over that they'll somehow convince these > same folks to migratenL > to Q hardware running Windows XP.   But it makes no sense on any level for thesee > customers to do so.lJ > If the vendor has failed to provide product, and in my opinion, outright lied to.H > us, why would we go back for more, especially once the sole reason for	 remaining,. > with them (VMS technology) is off the table?  K VMS technology looks to me like it's still on the table.  Compaq appears tosH be living up to its promise to deliver competitive Alpha systems for theK full lifespan of EV6 and EV7.  How many of us are making tactical decisionsiF today for what will happen at the end of EV7's life?  As for strategicI plans, I am happy to know that the VMS gang will have some say about whatdJ architectural features will be in Itanium by the time VMS is ready for it,L and that the compiler gang will have plenty of time to learn how to generateI EPIC code.  I think anyone who doubts Compaq's engineers' ability to make @ VMS, Tru64, NSK and their layered products work well on a futureD architecture that they can influence underestimates their talent and motivation.,  F As for marketing, there is no way to retract the misdeeds of the past.J Don't forget that the Pentium 60 and 66 were slower than DX2s of the time.L Merced is slow and years behind its absurdly optimistic schedule.  Does thatJ mean Intel, HP and Compaq do not have the collective talent and motivationH to make a future version of Itanium substantially better than the first?L Would you rather make strategic plans for an architecture whose development,K fab, and marketing can be amortized over EV8's projected volume or a future4& version of Itanium's projected volume?  L Alpha always had what it takes to run VMS.  Pentium never will.  Merced doesK not.  A future Itanium will.  Is it EV8 that you want or is it VMS?  I faileK to see how announcing full support for EV7 and future plans to move to whateJ will be a viable architecture with a greater market presence than EV8's is "screwing their customer base."i  1 Tony Scandora, Argonne National Lab, 630-252-7541e scandora@cmt.anl.gov   ------------------------------  % Date: Fri, 20 Jul 2001 11:51:51 +0100i0 From: andrew harrison <andrew.nospam@uk.sun.com>  Subject: Re: Oracle dead on VMS?* Message-ID: <3B580D47.FF91A584@uk.sun.com>   Christian Bauer wrote: >  > Well, just to be honet,I > J > an Alpha (with True64 :-( and Oracle) is the fastest TCP-C non clustered	 > system.  >   7 Not quite. The Compaq result exploits a loophole in the 8 TPC-C rules that allows a Clustered database running on 2 a single system to be clasified as a non-clustered2 result. In that respect it is not comparable with 1 the single instance results from Fujitsu, IBM, HPs and Sun.    K > 1 Compaq AlphaServer GS320 Model 6/1001 (32-way) 230,533.00 tpmC Oracle9i>* > v9.0.1 Enterprise Edition for Tru64 UNIX > = > http://www.ideasinternational.com/benchmark/tpc/tpccnc.htmlE > 6 > and NO Microsoft Product in the first 10 Top ten.... >   6 Dangerous territory, the MS based results use the same3 warehouse partitioning scheme used by Compaq, they  4 just didn't do it on 8 nodes in a single OS instance7 instead multiple nodes each with their own OS instance.   7 Same performance tuning trick, different clasification 3# due the loophole mentioned earlier.f   Regards  Andrew Harrisonj Enterprise IT Architecta   ------------------------------  % Date: Fri, 20 Jul 2001 15:30:15 +0800p5 From: Netsurfer <netsurfer@sentosa.singaporemail.com>s0 Subject: Oracle Resource monitoring for OpenVMS?8 Message-ID: <q8nfltcmbrsks2sitoqsl6sfhgk1htdo64@4ax.com>  6 Is there any experience non-GUI DBA in this newsgroup?7 Is there any Oracle resource monitor scripts available?e  @ My Alpha server which running on OpenVMS 7.1 was having frequent( application outages regarding TNS error.  F Since most of them are batch jobs, I believe it's something to do withF SGA. And unfortunately the recent DBA my company employed are NT-basedB and GUI users with weak Oracle fundamentals. I, myself is not very% competent in both OpenVMS and Oracle.n     Anyone can help?      t Regards,  	 Netsurfere        ====R For any personal email replies, please remove " sentosa. " from my E-mail address.   ------------------------------  % Date: Fri, 20 Jul 2001 10:04:24 -0400l. From: "Kenneth Randell" <kenr@datametrics.com>4 Subject: Re: Oracle Resource monitoring for OpenVMS?+ Message-ID: <9j9do9$7nu$1@bob.news.rcn.net>e  " What are you trying to accomplish?  J Oracle has built-in monitoring (timed statistics) that you have to enable.L There are a number of internal tables (v$.....) that have lots of metrics asK well.  All of these are documented in the Oracle documentation -- I believee, in the DBAs guide in one of the appendicies.  4 The Oracle documentation is (was) available on line.  L You did not say what version of Oracle you have; there are small differencesJ in these internal tables between Oracle 7 and Oracle 8.  Oracle 7 also hasL some VMS-specific metrics as well which appear to do with $IO_PERFORM usage.  K There are numerous books on this subject which have scripts in them; I likeMC the "Oracle Performance Tuning' by Mark Gurry + Peter Corrigan from5	 O'Reilly.u  : A simple one for SGA stats would be (logged in as SYSTEM):   select * from v$sgastat;   Ken Randelln  @ Netsurfer <netsurfer@sentosa.singaporemail.com> wrote in message2 news:q8nfltcmbrsks2sitoqsl6sfhgk1htdo64@4ax.com...8 > Is there any experience non-GUI DBA in this newsgroup?9 > Is there any Oracle resource monitor scripts available?t >nB > My Alpha server which running on OpenVMS 7.1 was having frequent* > application outages regarding TNS error. > H > Since most of them are batch jobs, I believe it's something to do withH > SGA. And unfortunately the recent DBA my company employed are NT-basedD > and GUI users with weak Oracle fundamentals. I, myself is not very' > competent in both OpenVMS and Oracle.  >a >  > Anyone can help? >3
 > Regards, >P > Netsurfert >p >- > ====K > For any personal email replies, please remove " sentosa. " from my E-mail0 address.   ------------------------------  % Date: Fri, 20 Jul 2001 09:13:21 -03005) From: fabio_compaq@ep-bc.petrobras.com.brs Subject: Process adopts Itanium L Message-ID: <OF7462A3CB.459E5E7C-ON03256A8F.00419D09@ep-bc.petrobras.com.br>   Process adopts Itanium  C http://www.process.com/about/process-compaq-intelrelease071901.htmla   Regardst   F=E1bio dos Santos Cardoso=p   ------------------------------  % Date: Fri, 20 Jul 2001 08:56:31 -04000( From: Hamlyn Mootoo <univms@bigfoot.com># Subject: Re: Process adopts Itanium + Message-ID: <3B582A7F.FCA01839@bigfoot.com>-  F Translation: Platinum Equity wants to sell Process Software as quicklyH as it can while it still has value.  And press releases such as this oneE do what Compaq can't figure out how to:  Placate your customers while.H actively executing your exit strategy, therefore maximizing your revenue  on the disposition of the asset.   HM  * fabio_compaq@ep-bc.petrobras.com.br wrote: >  > Process adopts Itanium > E > http://www.process.com/about/process-compaq-intelrelease071901.html  > 	 > Regards  >  > Fbio dos Santos Cardoso   ------------------------------    Date: 20 Jul 2001 09:14:57 -0500- From: koehler@encompasserve.org (Bob Koehler)c# Subject: Re: Process adopts ItaniumM3 Message-ID: <iqU2SUUdSKOf@eisner.encompasserve.org>o  x In article <OF7462A3CB.459E5E7C-ON03256A8F.00419D09@ep-bc.petrobras.com.br>, fabio_compaq@ep-bc.petrobras.com.br writes: > Process adopts Itanium > E > http://www.process.com/about/process-compaq-intelrelease071901.html  >   D "Compaq's AlphaServer Intel processor"?  I hope Compaq's not calling
 them that.  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporationv= NASA GSFC Flight Software       | Federal Sector, Civil GroupiE                                 | please remove ".aspm" when replying    ------------------------------  # Date: Fri, 20 Jul 2001 14:01:00 GMTo= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)r# Subject: Re: Process adopts Itanium)0 Message-ID: <009FF48B.57D2346E@SendSpamHere.ORG>  V In article <3B582A7F.FCA01839@bigfoot.com>, Hamlyn Mootoo <univms@bigfoot.com> writes:G >Translation: Platinum Equity wants to sell Process Software as quickly I >as it can while it still has value.  And press releases such as this one F >do what Compaq can't figure out how to:  Placate your customers whileI >actively executing your exit strategy, therefore maximizing your revenue ! >on the disposition of the asset.r  I I doubt much that their statement was intended to indicate anything othernH than, "Hey, foolhearty Compaq is shit-canning the Alpha and planning to I migrate VMS to IPF (Intel Processor Faulted) so, we'll have to do anothereI port of all of our software, and we will, if we intend to stay in biz and & reek revenues from the VMS community".  G While I do agree that it will placate customers, it doesn't read (to meu3 anyhow) that Platinum wants to discard the company.l  H I value Process's words 10E+6 times more than anything that comes out ofI Compaq.  I am simply tired of being lied to by Compaq and wandering aboutnH like a placid sheep awaiting the final knife weilding cut to the OpenVMSH jugler.  VMS is the only significant d|i|g|i|t|a|l technology left to be* slaughtered in the Compaq slaughter house. --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMe            eJ   "And of course, I'm a genius, so people are naturally drawn to my fiery I   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbesc   ------------------------------  % Date: Fri, 20 Jul 2001 10:45:16 -0400s) From: "Neil Rieck" <n.rieck@sympatico.ca>i# Subject: Re: Process adopts Itaniumn9 Message-ID: <LrX57.4608$jo4.645651@news20.bellglobal.com>a  9 I love their stack (TCPware) so this is good news for me.a  
 Neil Rieck Kitchener/Waterloo/Cambridge,m Ontario, Canada.! http://www3.sympatico.ca/n.rieck/t  : "Bob Koehler" <koehler@encompasserve.org> wrote in message- news:iqU2SUUdSKOf@eisner.encompasserve.org...  > In articleA <OF7462A3CB.459E5E7C-ON03256A8F.00419D09@ep-bc.petrobras.com.br>,e+ fabio_compaq@ep-bc.petrobras.com.br writes:s > > Process adopts Itanium > >aG > > http://www.process.com/about/process-compaq-intelrelease071901.htmlh > >u >iF > "Compaq's AlphaServer Intel processor"?  I hope Compaq's not calling > them that. > H > ----------------------------------------------------------------------A > Bob Koehler                     | Computer Sciences Corporationp? > NASA GSFC Flight Software       | Federal Sector, Civil GroupoG >                                 | please remove ".aspm" when replying-   ------------------------------  % Date: Fri, 20 Jul 2001 11:11:15 -0400p( From: Hamlyn Mootoo <univms@bigfoot.com># Subject: Re: Process adopts Itanium.+ Message-ID: <3B584A13.2AFCE971@bigfoot.com>t  G I actually do prefer Process Software's product, over the others. And IiF have found their support to be quite good.  I think the company itselfD is well run.  However, it is the timing of this statement of support? that makes me suspicious.  I'm guessing this was initiated fromcD Platinum, not necessarily from Process itself.  Why not wait and seeF what shakes out? Why the rush?  What if they commit resources to startG their port, and Compaq kill the VMS to Titanic port (as I firmly belived they will)?    HM  & "Brian Schenkenberger, VAXman-" wrote: > X > In article <3B582A7F.FCA01839@bigfoot.com>, Hamlyn Mootoo <univms@bigfoot.com> writes:I > >Translation: Platinum Equity wants to sell Process Software as quicklyYK > >as it can while it still has value.  And press releases such as this one H > >do what Compaq can't figure out how to:  Placate your customers whileK > >actively executing your exit strategy, therefore maximizing your revenueM# > >on the disposition of the asset.  > K > I doubt much that their statement was intended to indicate anything other.I > than, "Hey, foolhearty Compaq is shit-canning the Alpha and planning tooK > migrate VMS to IPF (Intel Processor Faulted) so, we'll have to do anotherhK > port of all of our software, and we will, if we intend to stay in biz andK( > reek revenues from the VMS community". > I > While I do agree that it will placate customers, it doesn't read (to mee5 > anyhow) that Platinum wants to discard the company.  > J > I value Process's words 10E+6 times more than anything that comes out ofK > Compaq.  I am simply tired of being lied to by Compaq and wandering aboutoJ > like a placid sheep awaiting the final knife weilding cut to the OpenVMSJ > jugler.  VMS is the only significant d|i|g|i|t|a|l technology left to be, > slaughtered in the Compaq slaughter house. > --Q > VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMu > K >   "And of course, I'm a genius, so people are naturally drawn to my fieryGK >   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbesn   ------------------------------  % Date: Fri, 20 Jul 2001 12:26:05 -0300c) From: fabio_compaq@ep-bc.petrobras.com.br # Subject: Re: Process adopts ItaniumhL Message-ID: <OF04FC7A02.46CA6692-ON03256A8F.0054AB34@ep-bc.petrobras.com.br>  I LEt's suggest Process to buy OpenVMS and name it ProcessVMS, what about ?eK I really believe OpenVMS must be in hands of a consortium of companies ....s* Joining Process, Raxco, Execsoft, etc ....   Regards-   FC          9 Hamlyn Mootoo <univms@bigfoot.com> em 20/07/2001 12:11:15q  4 Favor responder a Hamlyn Mootoo <univms@bigfoot.com>             Info-VAX@Mvb.Saic.ComO      # Assunto: Re: Process adopts Itanium     G I actually do prefer Process Software's product, over the others. And ICF have found their support to be quite good.  I think the company itselfD is well run.  However, it is the timing of this statement of support? that makes me suspicious.  I'm guessing this was initiated from D Platinum, not necessarily from Process itself.  Why not wait and seeF what shakes out? Why the rush?  What if they commit resources to startG their port, and Compaq kill the VMS to Titanic port (as I firmly belivei they will)?    HM  & "Brian Schenkenberger, VAXman-" wrote: >i; > In article <3B582A7F.FCA01839@bigfoot.com>, Hamlyn Mootoo. <univms@bigfoot.com> writes:I > >Translation: Platinum Equity wants to sell Process Software as quickly K > >as it can while it still has value.  And press releases such as this one H > >do what Compaq can't figure out how to:  Placate your customers whileK > >actively executing your exit strategy, therefore maximizing your revenuej# > >on the disposition of the asset.n >lK > I doubt much that their statement was intended to indicate anything othertI > than, "Hey, foolhearty Compaq is shit-canning the Alpha and planning tosK > migrate VMS to IPF (Intel Processor Faulted) so, we'll have to do anotherhK > port of all of our software, and we will, if we intend to stay in biz and ( > reek revenues from the VMS community". > I > While I do agree that it will placate customers, it doesn't read (to me-5 > anyhow) that Platinum wants to discard the company.- >wJ > I value Process's words 10E+6 times more than anything that comes out ofK > Compaq.  I am simply tired of being lied to by Compaq and wandering about J > like a placid sheep awaiting the final knife weilding cut to the OpenVMSJ > jugler.  VMS is the only significant d|i|g|i|t|a|l technology left to be, > slaughtered in the Compaq slaughter house. > --4 > VAXman- OpenVMS APE certification number: AAA-0001 VAXman(at)TMESIS(dot)COM >rK >   "And of course, I'm a genius, so people are naturally drawn to my fiery.K >   intellect.  Their admiration overwhelms their envy!" -- Calvin & Hobbesr   ------------------------------  # Date: Fri, 20 Jul 2001 15:42:36 GMT - From: goathunter@goatley.com (Hunter Goatley)y# Subject: Re: Process adopts Itaniumr1 Message-ID: <3b5850dd.238743825@news.process.com>   M On Fri, 20 Jul 2001 08:56:31 -0400, Hamlyn Mootoo <univms@bigfoot.com> wrote:m  G >Translation: Platinum Equity wants to sell Process Software as quicklynI >as it can while it still has value.  And press releases such as this one F >do what Compaq can't figure out how to:  Placate your customers whileI >actively executing your exit strategy, therefore maximizing your revenueo! >on the disposition of the asset.d > F Not at all.  It means exactly what it says, and what Brian summarized:C we're a VMS company, and we intend to port our products to whateverlF platform VMS is ported to, in this case Itanium, as soon as we're able	 to do so.    Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/s9 goathunter@goatley.com     http://www.goatley.com/hunter/u   ------------------------------    Date: 20 Jul 2001 12:22:59 -0400/ From: jordan@lisa.gemair.com (Jordan Henderson)a# Subject: Re: Process adopts Itaniumv* Message-ID: <9j9lt3$8pn$1@lisa.gemair.com>  1 In article <3b5850dd.238743825@news.process.com>,,. Hunter Goatley <goathunter@goatley.com> wrote:N >On Fri, 20 Jul 2001 08:56:31 -0400, Hamlyn Mootoo <univms@bigfoot.com> wrote: >nH >>Translation: Platinum Equity wants to sell Process Software as quicklyJ >>as it can while it still has value.  And press releases such as this oneG >>do what Compaq can't figure out how to:  Placate your customers whileeJ >>actively executing your exit strategy, therefore maximizing your revenue" >>on the disposition of the asset. >>G >Not at all.  It means exactly what it says, and what Brian summarized: D >we're a VMS company, and we intend to port our products to whateverG >platform VMS is ported to, in this case Itanium, as soon as we're able 
 >to do so. >   ? Will we be seeing the Multinet and Process TCP/IP product linesr= consolidated along with the new port?  I seem to recall that 4< consolidation was planned anyway.  Seems like a good time to do it.     >HunterM >------u: >Hunter Goatley, Process Software, http://www.process.com/: >goathunter@goatley.com     http://www.goatley.com/hunter/   -Jordan Hendersonf jordan@greenapple.com    ------------------------------  % Date: Fri, 20 Jul 2001 12:49:26 -0400n- From: JF Mezei <jfmezei.spamnot@videotron.ca>.# Subject: Re: Process adopts Itanium , Message-ID: <3B586112.F254BFDD@videotron.ca>   Hamlyn Mootoo wrote: > H > Translation: Platinum Equity wants to sell Process Software as quicklyJ > as it can while it still has value.  And press releases such as this oneG > do what Compaq can't figure out how to:  Placate your customers whilenJ > actively executing your exit strategy, therefore maximizing your revenue" > on the disposition of the asset.  N I didn't read that press release like that. The way I read it, Compaq realisesJ its got a PR problem and is now going after ISVs to make press releases toJ endorse their move to IA64. (Note that the press releases starts off with:J Process Software, (...) today endorsed Compaqs recently announced move to Intels new Itanium0  N If Platinum Equity had wanted Compaq to spend some of the Intel's money to buyL Process as part of its plan to acquire software/solutions companies, I thinkM that they would have stayed quiet, let Compaq make the PR gains by announcingu< it was buying Process and porting Process' software to IA64.  M To Compaq, Process holds one key product: PMDF. The TCP stacks probably don'tnK mean much to Compaq since Compaq already has its own. But Process engineerseM might be valuable. As a matter of fact, I could see Process used as a vehicleHN to suport/maintain the TCPIP V5 product on VMS and perhaps (finally) merge all the 3 stacks into one.  I I have to admit that if Compaq were to spend some of Intel's money to buylL Process Software and other VMS-specific companies, I would feel less cynical about Compaq's true intentions.p   ------------------------------  % Date: Fri, 20 Jul 2001 13:18:45 -0400r- From: JF Mezei <jfmezei.spamnot@videotron.ca>u# Subject: Re: Process adopts Itaniume, Message-ID: <3B5867EF.F61B64A6@videotron.ca>  & "Brian Schenkenberger, VAXman-" wrote:I > While I do agree that it will placate customers, it doesn't read (to mem5 > anyhow) that Platinum wants to discard the company.c  K Placating the news release feed with VMS related news is good. The more the H merrier (unless they all announce they are dropping support, of course).   ------------------------------  % Date: Fri, 20 Jul 2001 13:44:37 -0400.- From: JF Mezei <jfmezei.spamnot@videotron.ca>,# Subject: Re: Process adopts ItaniumK, Message-ID: <3B586DFE.1587BFCD@videotron.ca>   Hamlyn Mootoo wrote:A > that makes me suspicious.  I'm guessing this was initiated fromeF > Platinum, not necessarily from Process itself.  Why not wait and seeH > what shakes out? Why the rush?  What if they commit resources to startI > their port, and Compaq kill the VMS to Titanic port (as I firmly beliveo
 > they will)?   J What hints do you see that Compaq would not complete the IA64 port ? It is; being funded by Intel (indirectly from the sale of Alpha).    J I am convinced that Compaq is happy with a stable or slighly declining VMSJ customer base as long as they retain the fiew customers that really matterN (the very big ones). So the fact that there will be attrition and no new alphaN sales for the next few years has been accounted for by Compaq when it made itsK decision and I am convinced that Compaq can live without those extra sales.u  L Remember that Compaq expects its new software/solutions branch to grow at anN incredible 40% rate per annum, which should look great to Wall Street and hide' any attrition in the VMS customer base.l  L One tidbit I heard is that the "business critical" group will cease to existM and VMS etc will be handled by the wintel server group. Not sure if this is asN fact or heresay. But assuming it is true, this has interesting implications inM terms of transfer of technologies. The Wintel crowd will benefit from the VMSeL and NSK knowledge and expertise in building systems and the Wintel crowd may> be able to then sell "wildfires" based on IA64 and running NT.  K On the other hand, by having the wintel crowd responsible for VMS, it givescH the slight possibility that Compaq may start to view VMS as a mainstreamK product and market the hell out of it. However, I do not personally beleive-F that the attitudes at Compaq and Microsoft would allow this to happen.   ------------------------------  % Date: Fri, 20 Jul 2001 13:49:02 -0400 - From: JF Mezei <jfmezei.spamnot@videotron.ca>0# Subject: Re: Process adopts Itaniumc, Message-ID: <3B586F07.8E1A204F@videotron.ca>  * fabio_compaq@ep-bc.petrobras.com.br wrote: > K > LEt's suggest Process to buy OpenVMS and name it ProcessVMS, what about ?aM > I really believe OpenVMS must be in hands of a consortium of companies .... , > Joining Process, Raxco, Execsoft, etc .... >   I Looking at how Compaq handled Alpha, I beleive that by the time Compaq islJ ready to get rid of VMS, that it will be far easier for Compaq to sell theN patents and engineers to some other software firm (Microsoft) than to sell theK actual VMS business to some outfit that will have the money to rebuild VMS.n  M The longer Compaq waits to sell VMS, the fewer customers it will have and theo9 more investment will be needed to bring VMS back to life.p   ------------------------------  % Date: Fri, 20 Jul 2001 12:45:18 -0500a+ From: Christopher Smith <csmith@amdocs.com>-# Subject: RE: Process adopts ItaniumJL Message-ID: <3B55D7F383B0D31197D9009027541CBF1170DA46@cmiexch1.cmi.itds.com>   > -----Original Message-----6 > From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]   > Wintel crowd may@ > be able to then sell "wildfires" based on IA64 and running NT.  I Imagine that!  Thirty or more CPUs all running windows NT simultaneously,pE only one of which will actually be in use at any given time, the rest'K waiting until the normally intermittent at best "network" connection to the-L one becomes completely dead, and then arguing amongst themselves about which should take over next :)   Regards,   Chrisp    ! Christopher Smith, Perl Developer  Amdocs - Champaign, IL   /usr/bin/perl -e '? print((~"\x95\xc4\xe3"^"Just Another Perl Hacker.")."\x08!\n");- '-  -   ------------------------------  % Date: Fri, 20 Jul 2001 03:17:46 -0400n- From: JF Mezei <jfmezei.spamnot@videotron.ca> - Subject: Re: Terry Shannon Tech Talk on IA-64D, Message-ID: <3B57DB16.7F47A2FC@videotron.ca>   "David J. Dachtera" wrote:B > I think this comes down to intent vs. outcome. "Screwing the VMSG > customers" (not to mention partners, both official and otherwise) mayi@ > not have been the explicit intent; however, the result remains > inescapable.  K When you compare Compaq's handling of VMS with that under Palmer, Compaq isiL doing far better than Palmer. It may not be good enough to ensure success ofK VMS, but Compaq is not out actively advertising migrations away from VMS ast was the case during Palmer.C  K I think that Compaq is being a good corporate citizen by keeping a non-corecH product on life support because it is still profitable, and perhaps moreN importantly, Compaq hopes to find a way to eventually transplant VMS customers! to an industry standard platform.w  G I have a feeling that Compaq has a pretty well defined VMS strategy and M roadmap. It seems that Compaq is getting to know a certain portion of its VMSiJ customers and will do the basic stuff to keep those happy with VMS. And ifN that group of valuable customers doesn't need Oracle applications, then Compaq5 won't pressure Oracle to put its applications on VMS.i  A > Which makes the other Alpha-related pronouncements all the more E > incomprehensible. As many others have said, it would have been muchaJ > better for the OpenVMS community-at-large (what of it that survives) had6 > this been conducted ala the VAX to Alpha transition.  L Ditching of Alpha had nothing to do with VMS. (since the VMS engineers foundD out about it at the same time as the public did). Ditching Alpha hadI everything to do with Compaq getting a wad of money with which it can add 0 solutions/support/software to its core business.  K Porting of VMS and Tru64 are just necessary side effects due to the sale ofe< Alpha, but it has nothing to do with Compaq's core strategy.   > Preaching to the choir again.k  J But if Compaq only cares about a certain type of VMS customer, then Compaq: only needs to preach to a certain percentage of the choir.  3 > > You can look at this as an opportunity, or not.p > & > A very bittersweet opportunity, yes.  I I certaintly do not see it as an opportunity. Opportunities will start to7L arise when Compaq starts to take real actions and spend real money to expandI the VMS marketplace. As of now, Compaq seems only interested in keeping a-) certain proportion of the installed base.e  J The porting to IA64 is irrelevant to VMS, except for the fact that it onlyK ensures that few new customers will adopt VMS during the transition period.   J > True, in the years to come, we may actually see an OpenVMS platform thatB > is priced competitively with the alternatives of the day. Remote4 > possibility, I grant you, but still a possibility.  M Same possibility that Digital or Compaq could have taken with Alpha. Consider'M that Compaq has only contacted its largest customers with info about the IA64 L thing. It hasn't bothered informing the remainder of its customer base whichJ would be medium/large busineses. There is no reason to beleive that CompaqW would all of a sudden decide to unleash VMS to compete against its Proliant-NT systems.e  M Heck, Digital was a "VMS" company and it prevented VMS from competing againstpM Microsoft products by pricing VMS out of that market. Why should you expect ai= PC company to allow VMS to compete against its core product ?F  E > I can't seem to get the point across to those who still find a goodsH > livelihood in OpenVMS that outside of the "Ivory Palace" niche marketsF > which can actually afford it, and outside the protected walls of theJ > Compaq Castle (crumbling though they may be), the OpenVMS market is dead
 > and buried.t  G I know. Like Fabio has said very well, my skill set is now obsolete andsJ without value. I have to get some sort of formal training either on Sun orK MSCE so that my CV will be taken seriously by current companies who have nohL clue what VMS is and thus do not know what value my VMS experience can bring to them.            :  I don't know what it would take to make that point stick,H > short of inviting all the current OVMS engineers and related people to: > come to Chicago and explore the Job market for yourself. >  > You might start with:i > { > http://jobsearch.monster.com/jobsearch.asp?cy=US&brd=1&lid=417&lid=888&lid=889&lid=890&fn=&q=vms+or+openvms+or+vax+or+deca >  > (Long URL - probably wrapped)m > h > http://www.chicago.computerjobs.com/job_results.asp?s_kw=vms+or+openvms+or+vax+or+dec&s_jcid=&x=24&y=7 > ' > (Another Long URL - probably wrapped)t > J > There are essentially two OpenVMS SysAdmin jobs that remain open. One isH > at a concrete supply company who wants their VMS person to also be theF > help desk, network guru and telecom monkey for well below market payJ > with hours of 05:00 to 15:00 (that's a 9-hour day, folks!). The other isG > Abbott Lab.'s, and they're still holding out for Steve Hoffman (who I1H > doubt they'll get, and I'll doubt they'll find a suitable substitute). >  > -- > David J. Dachterag > dba DJE Systems6 > http://www.djesys.com/ > < > Unofficial Affordable OpenVMS Home Page and Message Board:! > http://www.djesys.com/vms/soho/e > H > This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings > is to be expected. > B > Feel free to exercise your rights of free speech and expression. > H > However, attacks against individual posters, or groups of posters, are > strongly discouraged.    ------------------------------  # Date: Fri, 20 Jul 2001 06:40:26 GMT . From: "mulp" <michaelpettengill@earthlink.net>- Subject: Re: Terry Shannon Tech Talk on IA-64pA Message-ID: <unQ57.340$Xn.28543@newsread1.prod.itd.earthlink.net>o  ? "Terry C. Shannon" <terryshannon@mediaone.net> wrote in message 6 news:Uxu57.4102$N21.1743049@typhoon.ne.mediaone.net...G > > > Hey, Pal... I don't know! But I do know this: Mulpinnh@aol.com noa longer > is > > > on my subscription list. > >eJ > > Are you saying you kick people off your list for disagreeing with you? > >v > > Really?) >  > Of course not. Doh.b  L Not sure who all the mulp's are that prevent me from signing on as mulp, butF Terry probably figures that mulpinnh no longer works for Compaq and noD longer needs to get information about what's going on inside Compaq.  L Of course, Compaq doesn't know what's going on either, since (I assume) theyK subscribe at the corporate level and make it available thru the weblibrary.   L What I really miss is Client Server News.  I'd really like to see the issues" over the past couple of months....   ------------------------------  # Date: Fri, 20 Jul 2001 06:49:10 GMTy. From: "mulp" <michaelpettengill@earthlink.net>- Subject: Re: Terry Shannon Tech Talk on IA-64eB Message-ID: <GvQ57.275$Px1.30573@newsread2.prod.itd.earthlink.net>  ? "Terry C. Shannon" <terryshannon@mediaone.net> wrote in messagee4 news:m8937.123$XT4.278959@typhoon.ne.mediaone.net...  C > And IIRC InfiniBand will serve as the next-generation VMS clustert > interconnect.c  G Only if the resources needed to study it, understand it, map VIA to the K internal SCA architecture, and then implement, are made available.  But thedL past few years have been layoffs or during the good times, merely attrition,K and now there is a major project to consume resources and I'm guessing moreeI layoffs.  But the most important issue is that [nearly] everyone involvednL with the design and implementation of SCA over the past 20 years are outside Compaq.e   ------------------------------    Date: 20 Jul 2001 08:55:52 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)a- Subject: RE: Terry Shannon Tech Talk on IA-64-, Message-ID: <8xdsK8zfwgAv@malvm5.mala.bc.ca>  S In article <BE56C50EA024184DAF48F0B9A47F5CF4AD7F1B@kaoexc01.americas.cpqcorp.net>, g1     "Main, Kerry" <Kerry.Main@compaq.com> writes:F   >  > re: vesting FMS .. > G > Perhaps I have missed something here, but FMS is available on Alpha. t >   $    Yes, you're missing something :-)  L    FMS exists on Alpha as a VESTed VAX image. That concerns me because if itF is to make the transition to IA64 Compaq will either need to provide aG binary translation utility for Alpha/IA64 or re-release FMS as a native K image. I seriously doubt they'll consider the latter as they never bothered K to release a native version of FMS for Alpha. *If* it turns out that binaryoK translation to IA64 is not practical we could have a big problem as many of  our programs rely on FMS.o   ------------------------------    Date: 20 Jul 2001 09:00:14 -07001 From: nothome@spammers.are.scum (Malcolm Dunnett)o- Subject: Re: Terry Shannon Tech Talk on IA-64-, Message-ID: <fTR2q8Pblkxo@malvm5.mala.bc.ca>  - In article <3B579489.955717B2@videotron.ca>, j2    JF Mezei <jfmezei.spamnot@videotron.ca> writes:   > Malcolm Dunnett wrote:R >> > As far as FMS is concerned, are you 100% sure that it was just vested ? SinceQ >> > it is used extensively by ALL-IN-1, I would have though that they would havec9 >> > recompiled it on Alpha as part of the all-in-1 port.l >> eJ >>    I'm 99.9% sure it's vested ( or at least major portions of it are ). > O > FMS isn't that big. Is it possible that the run-time was recompiled, but thatmP > the FMS development (the editor, compiler and library management) was vested ? >   I    The run-time environment is definitely VESTed. There are FDVSHR_TV.EXE K and FDVSHR.IFF files in SYS$SHARE, which indicate a VESTed image. You can'tpJ link a program to FMS without using the /NONATIVE linker switch ( which is5 required to link programs against translated images )e   ------------------------------  % Date: Fri, 20 Jul 2001 13:54:33 -0400w- From: JF Mezei <jfmezei.spamnot@videotron.ca>s- Subject: Re: Terry Shannon Tech Talk on IA-64d, Message-ID: <3B587051.AB0B616B@videotron.ca>   Malcolm Dunnett wrote:K >    The run-time environment is definitely VESTed. There are FDVSHR_TV.EXEcM > and FDVSHR.IFF files in SYS$SHARE, which indicate a VESTed image. You can't-L > link a program to FMS without using the /NONATIVE linker switch ( which is7 > required to link programs against translated images )u   Wow ! N What could have been so hard to just recompile FMS on Alpha ? At least the runE time portion. FMS doesn't do very fancy kernel stuff, so it should bea# recompilable easily, shoudln't it ?s   ------------------------------   Date: 20 JUL 2001 17:50:07 GMT+ From: Dave Greenwood <greenwoodde@ornl.gov>e- Subject: Re: Terry Shannon Tech Talk on IA-64n2 Message-ID: <20JUL01.17500799@feda34.fed.ornl.gov>  2 nothome@spammers.are.scum (Malcolm Dunnett) wrote:/ > In article <3B579489.955717B2@videotron.ca>, a4 >    JF Mezei <jfmezei.spamnot@videotron.ca> writes: >  s > > Malcolm Dunnett wrote:T > >> > As far as FMS is concerned, are you 100% sure that it was just vested ? SinceS > >> > it is used extensively by ALL-IN-1, I would have though that they would have ; > >> > recompiled it on Alpha as part of the all-in-1 port.p > >> iL > >>    I'm 99.9% sure it's vested ( or at least major portions of it are ). > > Q > > FMS isn't that big. Is it possible that the run-time was recompiled, but thattR > > the FMS development (the editor, compiler and library management) was vested ? > >  >  sK >    The run-time environment is definitely VESTed. There are FDVSHR_TV.EXErM > and FDVSHR.IFF files in SYS$SHARE, which indicate a VESTed image. You can'tsL > link a program to FMS without using the /NONATIVE linker switch ( which is7 > required to link programs against translated images )d >  h  F I haven't done anything with FMS in quite a while.  I do have FMS v2.4= installed however.  From the release notes [including typos]:b        1.1  OPENVMS AXP SUPPORT  ..F      As a result of the changes to FMS/VECTOR and FMS/OBJECT  it  willF      be  necessary to rebuild and relink your applications if you wish0      to utilize the native DEC FMS forms driver.    :      1.1.4  Translated VAX VMS V2.4 Forms Driver Available    F      For those applications were relinking is not  feasible,  we  haveF      also  provided  a  translated  version  of the VAX FMS V2.4 formsF      driver on this kit.  The translated form driver is  available  asF      SYS$SHARE:FDVSHRTV.EXE.  The .IIF file is also provided to assist&      in translating user applications.  F      Translated applications are required to use the  translated  formF      driver.   To  obtain  the  best  performance  applications shouldF      migrate to the native OpenVMS AXP environment as  quickly  as  is      feasable.  I In addition, none of the examples in the FMS subdirectory of SYS$EXAMPLES F use /NONATIVE in their link commands.  So it looks to me like FMS *is*F there in native alpha format.  Perhaps you are using /NONATIVE because2 you're still using VAX vector and/or object files?  8 Dave (who also has an interest in continued FMS support) --------------9 Dave Greenwood                Email: Greenwoodde@ORNL.GOVpH Oak Ridge National Lab        %STD-W-DISCLAIMER, I only speak for myself   ------------------------------  # Date: Fri, 20 Jul 2001 15:47:52 GMT.  From: jlsue <jlsuexxxz@home.com>: Subject: Re: The death of VMS has been greatly exaggerated8 Message-ID: <osjglt4jul7a8dusqvqec91dedcaq3oehe@4ax.com>  3 On Fri, 13 Jul 2001 10:52:19 +0100, andrew harrisona! <andrew.nospam@uk.sun.com> wrote:p  
 >jlsue wrote:w   >> uI >> Hey Arne, Andrew's been doing that for years.  He's repeatedly told uskG >> what Compaq Management's plans were, when there was no communication ) >> affect anywhere to back up his claims.c >> a >g= >Wrong go and search deja, I havn't ever made any suggestionsn4 >on what Compaqs management plans are or have been.  >.   Bwahahahahahahahaha!!!!!!!  D You're wrong-o buddy.  I don't have to do a deja search - I wouldn'tF waste my time.  Even when faced with certain facts you weasel and spin your way around them.n  C Anyone who's been reading in here for a year or more will know thataC you will very often "predict" what Compaq (or DEC) will (would) do.n  C It's your reputation man.  Live with it, or do something to improvet it.w   ------------------------------  % Date: Fri, 20 Jul 2001 12:31:37 -0400n+ From: "Main, Kerry" <Kerry.Main@compaq.com> : Subject: RE: The death of VMS has been greatly exaggeratedR Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4AD7F1E@kaoexc01.americas.cpqcorp.net>   Andrew,o  L >> Kerry your choice of words makes it sound as if all the vendors that haveL their own architecture and IA-64 have the IA-64 platform to ensure that they? will have a backup platform if their own architecture fails.<<<u  K Not at all. I stated "or alternate 64 bit plan" very clearly. I did not say.H IBM's Power strategy was a backup for IA64. You chose to misintepret the  words to suit your own purposes.  I An extract from IBM's web page outlines IBM's plans for AIX5L - the first D paragraph outlines the importance they feel IA64 will have, but theyL definately state in the release that Power will also be a strongly supported	 platform.o  
 Reference:( http://www-1.ibm.com/servers/monterey/ (G "Project Monterey has been a development initiative, that includes IBM,eI Intel and SCO (Server Software Division - acquisition by Caldera Systems, H Inc. pending) , whose primary goals have been to enhance AIX with provenI technologies and to deliver the industry's best enterprise-class UNIX forDK Intel's new 64-bit microprocessor based systems (Itanium). The introduction C of AIX 5L (October, 2000) signifies the success of this developmento
 initiative. "l   Regards,  
 Kerry Main Senior Consultantr Compaq Canada Inc. Professional Services  Voice: 613-592-4660o Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----7 From: andrew harrison [mailto:andrew.nospam@uk.sun.com]s Sent: July 18, 2001 6:32 AM- To: Info-VAX@Mvb.Saic.Coma: Subject: Re: The death of VMS has been greatly exaggerated       "Main, Kerry" wrote: > 	 > Andrew,  > + > Just love the way you ready, fire, aim ..p >  > :-)  > J > >>>Bullshit. Power4 isn't IBM's backup plan if IA-64 doesn't deliver the? > goods and if you want to test this post this on comp.arch.<<<u > # > Now, if you re-read my statement:fK > > In addition, with the exception of MS, each OS provider has a backup or  > alternate 64bit HW plan ..>> > @ > What part of "or alternate 64bit plan" did you not understand? >   8 Kerry your choice of words makes it sound as if all the 7 vendors that have their own architecture and IA-64 have 9 the IA-64 platform to ensure that they will have a backup ) platform if their own architecture fails.   8 In the case of IBM this is very far from the truth, IBM 4 have IA-64 because it allows them to address markets6 they might have more difficulty addressing with Power 0 alone. They don't have it as a backup for IA-64.  6 You are applying your own corporate strategy to other 6 vendors which as you should be only to painfully aware
 is a mistake. +                                            o regardsC Andrew Harrisonn Enterprise IT Architectn   ------------------------------  % Date: Fri, 20 Jul 2001 18:15:07 +0200g0 From: Dietmar Hermanns <dietmar.hermanns@rtl.de> Subject: Re: VAX qbus problemC< Message-ID: <3b585903$0$269$4dbef881@businessnews.de.uu.net>   Rick Peters wrote:  F > Move the addresses for the 2nd and 3rd MSCP disk ctlrs to 760354 and > 760360 to fix the problem.? > "Dietmar Hermanns" <dietmar.hermanns@rtl.de> wrote in messagei8 > news:3b4edb4a$0$278$4dbef881@businessnews.de.uu.net...@ > > Pleas is there one with more experience about VAX in a BA23? > > < > > I tried to integrate a KFQSA into my Qbus VAX 3600/3900. > >g > > to power up shows: > >h > > KA655-A V5.3, VMB 2.7l# > > Performing normal system tests.cD > > 40..39..38..37..36..35..34..33..32..31..30..29..28..27..26..25..D > > 24..23..22..21..20..19..18..17..16..15..14..13..12..11..10..09.. > > 08..07..06..05..04..03.. > > Tests completed. > > >>>show qbus > > Scan of Qbus I/O Space, > > -20001910 (774420) = 0000 (000) KFQSA #0 > > -20001912 (774422) = 0AA0 ( > > -20001F40 (777500) = 0020 (004) IPCR > >  > > Scan of Qbus Memory Space ( > > >>>set host /uqssp /maint /service 0 > > UQSSP Controller (774420)c > >a/ > > Enter SET, CLEAR, SHOW, HELP, EXIT, or QUIT  > >n
 > > ? show > > Node   CSR Address   Model > >  0       760334       21 > >  1       760340       21 > >  7     ------ KFQSA ------
 > > ? exit > > Programming the KFQSA... > > >>>n > >r. > > 2: now I switched the KFQSA to normal mode > >a > > KA655-A V5.3, VMB 2.7n# > > Performing normal system tests. D > > 40..39..38..37..36..35..34..33..32..31..30..29..28..27..26..25..D > > 24..23..22..21..20..19..18..17..16..15..14..13..12..11..10..09.. > > 08..07..06..05..04..03.. > > Tests completed. > > >>>show qbus > > Scan of Qbus I/O SpaceF > > -200000DC (760334) = 0000 (300) RQDX3/KDA50/RRD50/RQC25/KFQSA-DISK > > -200000DE (760336) = 0AB0rF > > -200000E0 (760340) = 0000 (304) RQDX3/KDA50/RRD50/RQC25/KFQSA-DISK > > -200000E2 (760342) = 0AB0 ( > > -20001F40 (777500) = 0020 (004) IPCR > >a > > Scan of Qbus Memory Spacet > > >>>  > >. > > result: looks ok!  > >nH > > 3: now I pluged in the EMULEX U07 SCSI Controller at. (Addr: 772150) > >b > > KA655-A V5.3, VMB 2.7n# > > Performing normal system tests. D > > 40..39..38..37..36..35..34..33..32..31..30..29..28..27..26..25..D > > 24..23..22..21..20..19..18..17..16..15..14..13..12..11..10..09.. > > 08..07..06..05..04..03.. > > Tests completed. > > >>>show qbus > > Scan of Qbus I/O SpaceF > > -200000DC (760334) = 0000 (300) RQDX3/KDA50/RRD50/RQC25/KFQSA-DISK > > -200000DE (760336) = 0AB0 F > > -200000E0 (760340) = 0000 (304) RQDX3/KDA50/RRD50/RQC25/KFQSA-DISK > > -200000E2 (760342) = 0AB0 F > > -20001468 (772150) = 0000 (154) RQDX3/KDA50/RRD50/RQC25/KFQSA-DISK > > -2000146A (772152) = 0B00u( > > -20001F40 (777500) = 0020 (004) IPCR > >  > > Scan of Qbus Memory Spacei > > >>>  > >mD > > result : looks good. I need the EMULEX to boot from a SCSI Disks > >s. > > 4: the next is the network adapter (DELQA) > >i > > KA655-A V5.3, VMB 2.7s# > > Performing normal system tests. D > > 40..39..38..37..36..35..34..33..32..31..30..29..28..27..26..25..D > > 24..23..22..21..20..19..18..17..16..15..14..13..12..11..10..09.. > > 08..07..06..05..04..03.. > > Tests completed. > > >>>show qbus > > Scan of Qbus I/O SpaceF > > -200000DC (760334) = 0000 (300) RQDX3/KDA50/RRD50/RQC25/KFQSA-DISK > > -200000DE (760336) = 0AB0 F > > -200000E0 (760340) = 0000 (304) RQDX3/KDA50/RRD50/RQC25/KFQSA-DISK > > -200000E2 (760342) = 0AB0jF > > -20001468 (772150) = 0000 (154) RQDX3/KDA50/RRD50/RQC25/KFQSA-DISK > > -2000146A (772152) = 0B00n5 > > -20001920 (774440) = FF08 (120) DELQA/DEQNA/DESQAm > > -20001922 (774442) = FF00_ > > -20001924 (774444) = FF2B& > > -20001926 (774446) = FF19r > > -20001928 (774450) = FFD1  > > -2000192A (774452) = FFF8  > > -2000192C (774454) = 8400i > > -2000192E (774456) = 0030 ( > > -20001F40 (777500) = 0020 (004) IPCR > >s > > Scan of Qbus Memory Spaceg > > >>>e > > % > > result: everything looks OK!!!!!!h > >s0 > > 5: at last I choose the serial adapter DZQ11 > >t > > KA655-A V5.3, VMB 2.7d# > > Performing normal system tests.HD > > 40..39..38..37..36..35..34..33..32..31..30..29..28..27..26..25..D > > 24..23..22..21..20..19..18..17..16..15..14..13..12..11..10..09.. > > 08..07..06..05..04..03.. > > Tests completed. > > >>>show qbus > > Scan of Qbus I/O Space5 > > -20000040 (760100) = 0000 (300) DZQ11/DZV11/DFA01V > > -20000042 (760102) = 0000t > > -20000044 (760104) = 0000e > > -20000046 (760106) = 0000e > > -200000DC (760334) = 0000e > > -200000DE (760336) = 0AB0e) > > -200000E0 (760340) = 0000 (310) DMV11r > > -200000E2 (760342) = 0AB0yF > > -20001468 (772150) = 0000 (154) RQDX3/KDA50/RRD50/RQC25/KFQSA-DISK > > -2000146A (772152) = 0B00<5 > > -20001920 (774440) = FF08 (120) DELQA/DEQNA/DESQAa > > -20001922 (774442) = FF00g > > -20001924 (774444) = FF2Be > > -20001926 (774446) = FF19  > > -20001928 (774450) = FFD1n > > -2000192A (774452) = FFF8  > > -2000192C (774454) = 8400y > > -2000192E (774456) = 0030 ( > > -20001F40 (777500) = 0020 (004) IPCR > >u > > Scan of Qbus Memory Spaces > > ! > > Now I lost the KFQSA at Addr:  > > F > > -200000DC (760334) = 0000 (300) RQDX3/KDA50/RRD50/RQC25/KFQSA-DISK > > -200000DE (760336) = 0AB0 F > > -200000E0 (760340) = 0000 (304) RQDX3/KDA50/RRD50/RQC25/KFQSA-DISK > > -200000E2 (760342) = 0AB0b > >gL > > I tried it with different addr. and vector for the DZQ11. The only thingA > > that than happend is that I lost the DZQ11 also ( show qbus)!o > > H > > An other thing that makes me insecure is that the boot countdown (?) > stoppsB > > for a long time at number 14! What s happening at this point? > >e > > What did I wrong?a > >i > > Dietmar Hermanns > >t > > Dietmar.Hermanns@rtl.de  > >- > >- > >- > >- >  >  Thanks for the help!!!!1  I know the KFQSA is integrated but the disk that I connected to it aren t T there.   >>>show dev  UQSSP Controller (770360)7	         ?5 thats all.p  # After booting the PUB0 ist offline.n  4 I connected a HSD10 with 3 configured Devices to it.  " What I have to do next, to fix it?   ------------------------------  % Date: Fri, 20 Jul 2001 11:52:01 -0500l2 From: Patrick Jankowiak <pjankowi@usa.alcatel.com>Y Subject: Re: VMS declared Cool and Unhackable at DE FCON9 hackers convention i nLas Vegasm/ Message-ID: <3B5861B1.6B68A916@usa.alcatel.com>s  , This is a multi-part message in MIME format.& --------------A04230B8C0CDCF54BFD76C30* Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7biti       Larry Kilgallen wrote: >  > In article <5B57189920E7D41190B500606D210686011A6AB0@mailsvr.jfcom.mil>, "Kent, Philip  JW1811" <kent@jwfc.jfcom.mil> writes:-" > >> From:        Wisniewski, John3 > >> Sent:        Wednesday, July 18, 2001 11:08 AMnK > >> Subject:     What I did on my summer vacation....VMS declared Cool andw: > >> Unhackable at DEFCON9 hackers convention in Las Vegas > L > >> "Let me show you my telnet scanner" the youth beamed as he plugged into+ > >> the server hub (my mistake number one)  > >>M > >> "Go ahead and log in, I'll show you how I can capture the whole session"  > >> said the youth. > >>N > >> I logged in across Telnet (my mistake number two) and logged in to one of > >> the privileged accountsJ > >> as the young man scammed my password, even showing me the ease of the
 > >> capture.I > , > Showing the problem of reusable passwords.  C The lack of reusable passwords at defcon could be a problem for thea@ users. Most of the passwords started with the same four letters.& --------------A04230B8C0CDCF54BFD76C30- Content-Type: text/x-vcard; charset=us-ascii;r  name="pjankowi.vcf" Content-Transfer-Encoding: 7bit / Content-Description: Card for Patrick Jankowiak@  Content-Disposition: attachment;  filename="pjankowi.vcf"   begin:vcard  n:Jankowiak;Patrick  tel;cell:214-763-4764l tel;work:972-477-7631< x-mozilla-html:TRUEe url:http://www.alcatel.com1 org:Alcatel Microelectronics;South Central Regionu version:2.1 0 email;internet:patrick.jankowiak@usa.alcatel.com  title:Field Application Engineerd adr;quoted-printable:;;M/S 3001-MICR=0D=0A1000 Coit Road=0D=0A=0D=0A;Richardson;Texas;75075-5802;USA fn:Patrick Jankowiak	 end:vcard   ( --------------A04230B8C0CDCF54BFD76C30--   ------------------------------  % Date: Fri, 20 Jul 2001 11:20:50 -0500i2 From: Patrick Jankowiak <pjankowi@usa.alcatel.com>1 Subject: VMS remains secure at DEFCON hacker fest / Message-ID: <3B585A62.A772C066@usa.alcatel.com>n  , This is a multi-part message in MIME format.& --------------AE3B1D4DC4D9D81E4F862899* Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit    Hi.   H A couple friends and I, on our own and for the drunken fun of it, took aF VMS box configured with apache webserver and telnet and ftp and set upH to automagically generate user accounts and default web pages for anyoneD who telnetted and answered the questionnaire, to defcon9, the yearly" hackers' convention in las vegas.   G It was subjected for 3 days to the attendees, over 5000 hackers. People G you should be afraid of. It stayed on the intranetwork with the hackers A for the whole time and was not hacked, and it was not for lack of H attempts by some very expert and accomplished people, although one LuserC did manage to (ahem) accidentally trip over the power cord. detailsc later. S  # #3||0!, is VMS Marketing listening?i& --------------AE3B1D4DC4D9D81E4F862899- Content-Type: text/x-vcard; charset=us-ascii;d  name="pjankowi.vcf" Content-Transfer-Encoding: 7bit0/ Content-Description: Card for Patrick Jankowiake  Content-Disposition: attachment;  filename="pjankowi.vcf"   begin:vcard  n:Jankowiak;Patrick@ tel;cell:214-763-4764  tel;work:972-477-7631u x-mozilla-html:TRUEr url:http://www.alcatel.com1 org:Alcatel Microelectronics;South Central Regions version:2.1r0 email;internet:patrick.jankowiak@usa.alcatel.com  title:Field Application Engineerd adr;quoted-printable:;;M/S 3001-MICR=0D=0A1000 Coit Road=0D=0A=0D=0A;Richardson;Texas;75075-5802;USA fn:Patrick Jankowiak	 end:vcard   ( --------------AE3B1D4DC4D9D81E4F862899--   ------------------------------  % Date: Fri, 20 Jul 2001 14:07:02 -0300t) From: fabio_compaq@ep-bc.petrobras.com.br 5 Subject: Re: VMS remains secure at DEFCON hacker festcL Message-ID: <OF1B9C1E7C.B36680A5-ON03256A8F.005E0769@ep-bc.petrobras.com.br>  : --0__=03256A8F005E07698f9e8a93df938690918c03256A8F005E0769* Content-type: text/plain; charset=us-ascii  C I allwasy said that Compaq and COE want to militarize OpenVMS .....iF It is soo good to be in the customers hand.... imagine Osama Bin Laden2 running OpenVMS ???? Did DEC sell some for Lybia ?  : Well, with this propaganda in Czech and Poland.... (NATO).   Regards    FC        C Patrick Jankowiak <pjankowi@usa.alcatel.com> em 20/07/2001 13:20:50l  > Favor responder a Patrick Jankowiak <pjankowi@usa.alcatel.com>             Info-VAX@Mvb.Saic.Comn      1 Assunto: VMS remains secure at DEFCON hacker fest      Hi.u  H A couple friends and I, on our own and for the drunken fun of it, took aF VMS box configured with apache webserver and telnet and ftp and set upH to automagically generate user accounts and default web pages for anyoneD who telnetted and answered the questionnaire, to defcon9, the yearly! hackers' convention in las vegas.t  G It was subjected for 3 days to the attendees, over 5000 hackers. PeoplelG you should be afraid of. It stayed on the intranetwork with the hackers A for the whole time and was not hacked, and it was not for lack ofmH attempts by some very expert and accomplished people, although one LuserC did manage to (ahem) accidentally trip over the power cord. detailss later.  # #3||0!, is VMS Marketing listening?a! (See attached file: pjankowi.vcf)S          : --0__=03256A8F005E07698f9e8a93df938690918c03256A8F005E0769( Content-type: application/octet-stream;  	name="pjankowi.vcf"8 Content-Disposition: attachment; filename="pjankowi.vcf"! Content-Transfer-Encoding: base64s  L YmVnaW46dmNhcmQgDQpuOkphbmtvd2lhaztQYXRyaWNrDQp0ZWw7Y2VsbDoyMTQtNzYzLTQ3NjQNL CnRlbDt3b3JrOjk3Mi00NzctNzYzMQ0KeC1tb3ppbGxhLWh0bWw6VFJVRQ0KdXJsOmh0dHA6Ly93L d3cuYWxjYXRlbC5jb20NCm9yZzpBbGNhdGVsIE1pY3JvZWxlY3Ryb25pY3M7U291dGggQ2VudHJhL bCBSZWdpb24NCnZlcnNpb246Mi4xDQplbWFpbDtpbnRlcm5ldDpwYXRyaWNrLmphbmtvd2lha0B1L c2EuYWxjYXRlbC5jb20NCnRpdGxlOkZpZWxkIEFwcGxpY2F0aW9uIEVuZ2luZWVyDQphZHI7cXVvL dGVkLXByaW50YWJsZTo7O00vUyAzMDAxLU1JQ1I9MEQ9MEExMDAwIENvaXQgUm9hZD0wRD0wQT0wL RD0wQTtSaWNoYXJkc29uO1RleGFzOzc1MDc1LTU4MDI7VVNBDQpmbjpQYXRyaWNrIEphbmtvd2lh aw0KZW5kOnZjYXJkDQo=  < --0__=03256A8F005E07698f9e8a93df938690918c03256A8F005E0769--   ------------------------------  % Date: Fri, 20 Jul 2001 12:31:54 -0400k. From: "Kenneth Randell" <kenr@datametrics.com>  Subject: Re: VMS Trivia Question+ Message-ID: <9j9mcr$ao0$1@bob.news.rcn.net>r  F Well, as Louis Armstrong once said when asked "What is Jazz?", he saidE [briefly paraphrased]:  "Man, if you have to ask, you'll never know".w  K INSQTI is an VAX assembler instruction; you can look at today's other postso' and figure out what the 17-Nov-1858 is.o   Ken Randellw  ( Shawn <sfm1115@bjc.org> wrote in message* news:3b5859db.12188986@news.starnet.net...B > We just received software from RAXCO and there was a trivia typeF > poster in it.  On it it asks what happened on 17-Nov-1858, any ideas2 > we are lost here.  Is that the Star Date thingy. >c > Also what does INSQTI mean?n >e > Thanks >t >    ------------------------------  # Date: Fri, 20 Jul 2001 16:21:01 GMTc From: sfm1115@bjc.org (Shawn)y Subject: VMS Trivia Question0 Message-ID: <3b5859db.12188986@news.starnet.net>  @ We just received software from RAXCO and there was a trivia typeD poster in it.  On it it asks what happened on 17-Nov-1858, any ideas0 we are lost here.  Is that the Star Date thingy.   Also what does INSQTI mean?    Thanks   ------------------------------  # Date: Fri, 20 Jul 2001 16:49:44 GMTo= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)'  Subject: Re: VMS Trivia Question0 Message-ID: <009FF4A2.E9E872F8@SendSpamHere.ORG>  P In article <3b5859db.12188986@news.starnet.net>, sfm1115@bjc.org (Shawn) writes:A >We just received software from RAXCO and there was a trivia typemE >poster in it.  On it it asks what happened on 17-Nov-1858, any ideasn1 >we are lost here.  Is that the Star Date thingy.o  G It is the Smithsonian base date which was chosen by VMS engineering to aD be the "dawn of time".  The internal 64 bit clock ticks at a rate of3 100 nsec from this date to account for time in VMS.      >Also what does INSQTI mean?  E INSert in Queue a Tail Interlocked.  It is an instruction in the VAX uD architecture that places an element in a self-relative doubly-linkedC list.  The insertion is at the tail of the "queue" and it is inter-:E lock insuring atomicity of the operation.  A similar construct exists < in PALcode on the now-defunct (Thank you Compaq Mgt.) Alpha.     --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COM:            hJ   "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: Fri, 20 Jul 2001 17:18:27 GMT 2 From: seibel_r@localhost.localdomain (Rich Seibel)  Subject: Re: VMS Trivia Question; Message-ID: <slrn9lgpv3.9cd.seibel_r@localhost.localdomain>,  @ On Fri, 20 Jul 2001 16:21:01 GMT, Shawn <sfm1115@bjc.org> wrote:A >We just received software from RAXCO and there was a trivia type?E >poster in it.  On it it asks what happened on 17-Nov-1858, any ideasr1 >we are lost here.  Is that the Star Date thingy.  > K It is the epoch for VMS times (==0).  It is also the Smithsonian base data.    >Also what does INSQTI mean? >  Don't know.s   >Thanksr >t >t     --  D --------------------------------------------------------------------D Rich Seibel, Software Engineer                 (314)579-0066 ext 220D Object Computing, Inc.                           seibel_r@ociweb.comD Need ACE training?                      See http://www.theaceorb.comD --------------------------------------------------------------------   ------------------------------  % Date: Fri, 20 Jul 2001 14:00:37 -0300 ) From: fabio_compaq@ep-bc.petrobras.com.brr  Subject: Re: VMS Trivia QuestionL Message-ID: <OF51104EF5.7B3DC4A0-ON03256A8F.005D54A4@ep-bc.petrobras.com.br>  C I imagine this date as the building of the Mill (DEC's building) ors! the born of Ken Olsen's grandma !l   Regards4   FC        . sfm1115@bjc.org (Shawn) em 20/07/2001 13:21:01  ) Favor responder a sfm1115@bjc.org (Shawn)s             Info-VAX@Mvb.Saic.Comw       Assunto: VMS Trivia Question    @ We just received software from RAXCO and there was a trivia typeD poster in it.  On it it asks what happened on 17-Nov-1858, any ideas0 we are lost here.  Is that the Star Date thingy.   Also what does INSQTI mean?0   Thanks   ------------------------------  % Date: Fri, 20 Jul 2001 18:48:56 +010005 From: "Steeples, Oliver" <Oliver.Steeples@compaq.com>.  Subject: RE: VMS Trivia QuestionP Message-ID: <F498D199EDB12D468CD2C66680D3080101DDE49A@reoexc04.emea.cpqcorp.net>  L 17-Nov-1858 is VMS' base date and corresponds to a binary date/time value of 0.   Do I get a free T-shirt?   -----Original Message-----) From: fabio_compaq@ep-bc.petrobras.com.bro, [mailto:fabio_compaq@ep-bc.petrobras.com.br]# Sent: Friday, July 20, 2001 6:01 PM  To: Info-VAX@Mvb.Saic.Comd  Subject: Re: VMS Trivia Question    C I imagine this date as the building of the Mill (DEC's building) or ! the born of Ken Olsen's grandma !.   Regardsn   FC        . sfm1115@bjc.org (Shawn) em 20/07/2001 13:21:01  ) Favor responder a sfm1115@bjc.org (Shawn)r             Info-VAX@Mvb.Saic.Com.       Assunto: VMS Trivia Question    @ We just received software from RAXCO and there was a trivia typeD poster in it.  On it it asks what happened on 17-Nov-1858, any ideas0 we are lost here.  Is that the Star Date thingy.   Also what does INSQTI mean?    Thanks   ------------------------------    Date: 20 Jul 2001 10:27:33 +0100K From: pmoreau@ath.cena.fr (Patrick MOREAU, CENA Athis, Tel: 01.69.57.64.40)0 Subject: Re: XAW/XMU ?! Message-ID: <VVAS7bjxObh8@gaelic>a  3 In article <3B56FCE9.7E4294F7@byron.ext.telia.se>, e' "P.Lj" <plj@byron.ext.telia.se> writes:e > E > Anyone knowns if  there's a working/updated (at least OpenVMS Alpha5$ > 7.2*)  XAW/XMU package out there ?    Take a look at the DECW archive:  " http://decwarch.free.fr/xlibs.html  ! You have X11R4 & X11R5 libraries..  < You can also find XAW3D embedded into Ghosview distribution:  " http://decwarch.free.fr/pspdf.html   No VMS IA64 version yet :-)S   Enjoy !!   Patrick0 --O =============================================================================== O pmoreau@cena.dgac.fr  (CENA)     ______      ___   _           (Patrick MOREAU)04 moreau_p@decus.fr (DECUS)       / /   /     / /|  /|J CENA/Athis-Mons FRANCE         / /___/     / / | / |   __   __   __   __  N BP 205                        / /         / /  |/  |  |  | |__| |__  |__| |  |N 94542 ORLY AEROGARE CEDEX    / /   ::    / /       |  |__| | \  |__  |  | |__|N http://www.ath.cena.fr/~pmoreau/            http://www.multimania.com/pmoreau/O ===============================================================================3   ------------------------------  % Date: Fri, 20 Jul 2001 10:42:44 +0200.- From: Jouk Jansen <joukj@hrem.stm.tudelft.nl>5 Subject: Re: XAW/XMU ?3 Message-ID: <3B580B24.314E7253@hrem.stm.tudelft.nl>e   P.Lj wrote:  >  > Hi,0 > E > Anyone knowns if  there's a working/updated (at least OpenVMS Alpha $ > 7.2*)  XAW/XMU package out there ? >  > >>> ^P.Lj/ The one distributed with GVE- http://wwwthep.physik.uni-mainz.de/~plass/gv/09 did compile when I was running VMS7.2 almost 2 years ago.7          Jouk    ------------------------------  % Date: Fri, 20 Jul 2001 07:57:39 +020042 From: "Dr. Otto Titze" <titze@ikp.tu-darmstadt.de>" Subject: Re: Your reply on GSDFULL3 Message-ID: <3B57C853.4609D939@ikp.tu-darmstadt.de>    Hamlyn,    concerning your remark  D > When you increased GBLPAGFIL, did you do a WRITE ACTIVE in sysgen?J > If you did, then it DID increase it.  This parameter (at least on 7.2-1)H > is a dynamic parameter and does not require a reboot.  If you do a USE? > ACTIVE in sysgen, then SHOW GBLPAGFIL, what does it show now?   * Under VMS V6.2 the GBLPFIL is not DYNAMIC.   Regards7   Otto   ------------------------------  % Date: Fri, 20 Jul 2001 09:00:21 -0400   From: jamese@beast.dtsw.army.mil$ Subject: Re: Zero Quadword Time Poll0 Message-ID: <01072009002118@beast.dtsw.army.mil>  5 hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) wrote on0I Thu, 19 Jul 2001 22:47:24 GMT in <0sJ57.1022$rc5.70029@news.cpqcorp.net>:0  D >   The following is a trial balloon, and NOT something that we have >   immediate plans to change. > I >   One of the local engineers has suggested changing the interpretation 5G >   of a OpenVMS quadword time containing a zero from its existing to a)G >   new interpretation; from an absolute time (17-Nov-1858) to a delta 0 >   time ("now", basically). > G >   (Some folks here may remember seeing evidence of an existing tweak 5I >   within OpenVMS, a tweak that will convert a calculated delta of zero  ( >   into a delta of a very small value.) > D >   Anybody here directly using a quadword zero as an absolute time? >   Supporters?  Detracters?  F I have one comment about debugging when a quadword zero is an absoluteI time. On many occasions in the 23 years of working with VMS, I have foundS@ errors in routines that displayed some variant of "17-Nov-1858."  : Ed James                           ed.james@telecomsys.com5 TeleCommunications Systems, Inc.   voice 410-295-1919q; 2024 West Street, Suite 300              800-810-0827 x1919a5 Annapolis, MD 21401-3556           fax   410-280-1094    ------------------------------    Date: 20 Jul 2001 09:09:32 -0500- From: koehler@encompasserve.org (Bob Koehler)i$ Subject: Re: Zero Quadword Time Poll3 Message-ID: <6ptWCzbzLFt6@eisner.encompasserve.org>e  h In article <0sJ57.1022$rc5.70029@news.cpqcorp.net>, hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes: > D >   The following is a trial balloon, and NOT something that we have >   immediate plans to change. > I >   One of the local engineers has suggested changing the interpretation -G >   of a OpenVMS quadword time containing a zero from its existing to acG >   new interpretation; from an absolute time (17-Nov-1858) to a delta d >   time ("now", basically). >    I use a zero time when I do-  / $touch=="set file/expire=17-nov-1858:00:00:00."   F this works for me because we're not actually using expiration times on* our disks.  Would this change mean I'd use  ( $touch=="set file/expire=0000-00:00:00."  H I think in many places there's an assumption that 0 time means "not set"E (such as expiration date in UAF).  Those would all have to be checked  out.  F ----------------------------------------------------------------------? Bob Koehler                     | Computer Sciences Corporationa= NASA GSFC Flight Software       | Federal Sector, Civil GroupeE                                 | please remove ".aspm" when replying"   ------------------------------  # Date: Fri, 20 Jul 2001 13:12:35 GMTb2 From: hoffman@xdelta.zko.dec.nospam (Hoff Hoffman)$ Subject: Re: Zero Quadword Time Poll3 Message-ID: <77W57.1043$rc5.70114@news.cpqcorp.net>r  S In article <01072009002118@beast.dtsw.army.mil>, jamese@beast.dtsw.army.mil writes:sG :I have one comment about debugging when a quadword zero is an absolutetJ :time. On many occasions in the 23 years of working with VMS, I have foundA :errors in routines that displayed some variant of "17-Nov-1858."s  .   Correct.  The zero-as-delta would mask that.  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: Thu, 19 Jul 2001 19:24:58 -0400t* From: "Stanley F. Quayle" <stan@stanq.com>$ Subject: Re: Zero Quadword Time Poll. Message-ID: <3B57340A.2458.14190103@localhost>  D >   Anybody here directly using a quadword zero as an absolute time?  E Well, I'm not in favor of it.  I have lots of code that assumes that oD 0 is the oldest date possible.  If you make it be "now", that would  break quite a few things.   > How about a SYSGEN parameter to enable/disable this alternate  interpretation?e     --Stan  
 ----------G Stanley F. Quayle, P.E.   N8SQ   +1 614-868-1363   Fax: +1 614 868-1671t1 8572 North Spring Ct. NW, Pickerington, OH  43147r= Preferred address:  stan@stanq.com       http://www.stanq.comt   ------------------------------  # Date: Fri, 20 Jul 2001 14:55:13 GMTo= From: system@SendSpamHere.ORG (Brian Schenkenberger, VAXman-)o$ Subject: Re: Zero Quadword Time Poll0 Message-ID: <009FF492.EAB58BC5@SendSpamHere.ORG>  [ In article <3B57340A.2458.14190103@localhost>, "Stanley F. Quayle" <stan@stanq.com> writes:qE >>   Anybody here directly using a quadword zero as an absolute time?  > F >Well, I'm not in favor of it.  I have lots of code that assumes that E >0 is the oldest date possible.  If you make it be "now", that would r >break quite a few things. >n? >How about a SYSGEN parameter to enable/disable this alternate e >interpretation?  A That, I would think, would rather muck things up even more.  Someo@ programs will assume the old behavior and you might install someA new programs assuming the new behavior.  Flipping the SYSGEN par- 8 ameter would likely cause some rather bizarre behaviors.   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMn            :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: Fri, 20 Jul 2001 11:51:11 -0400 % From: "John Vottero" <John@mvpsi.com>n$ Subject: Re: Zero Quadword Time Poll/ Message-ID: <tlgkqgscgoapdb@news.supernews.com>0  L They aren't thinking of making a zero date/time mean "now", they're thinkingB of making it mean delta zero.  A missing date would display as: "0
 00:00:00.00".-  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3B578BC4.A33EC7FE@videotron.ca... > Hoff Hoffman wrote:mJ > >   One of the local engineers has suggested changing the interpretationI > >   of a OpenVMS quadword time containing a zero from its existing to a6H > >   new interpretation; from an absolute time (17-Nov-1858) to a delta > >   time ("now", basically). > G > When debugging a program, having a non initialized quadword makes the. resulktsL > very obvious. If a current time is assumed, the fact that the quadword has nott+ > been initialised would not be so obvious.. > F > This would have interesting effects in case of a file has bad dates. DIR/FULLG > would reveal current time every time one would DIR that file. (so theo dates K > would change all the time without the file actually having been touched).a IrJ > know this doesn't happen often, but I think I have had a few files in my lifeJ > that were dated 17-nov-1858. (perhaps because they had been created at a time1 > where the system clock was wrong or something).l >eH > In programs, I can see it avoiding a $GETTIM() followed by a time math (add, K > subtract) to calculate a delta time. It would make it less obvious. Also,t IaH > would probably still use $GETTIM() to gt the current time and store it becauserK > it is often needed not only to calculate one delta time but poerhaps also  useo/ > as a time stamp for the transactions etc etc.m >sK > Since in almost all time routines one passes a pointer to a quadword, whyh note? > change the time routines to use "NOW" when the pointer is 0 ?  >eK > Also, perhaps $BINTIM could up updated to support the text "NOW" as input6 ?1   ------------------------------  % Date: Fri, 20 Jul 2001 08:58:31 -0700w% From: Dean Woodward <deanw@rdrop.com>;$ Subject: Re: Zero Quadword Time Poll) Message-ID: <3B585527.57B7482C@rdrop.com>Q   Hoff Hoffman wrote:W > H >   One of the local engineers has suggested changing the interpretationG >   of a OpenVMS quadword time containing a zero from its existing to aEF >   new interpretation; from an absolute time (17-Nov-1858) to a delta >   time ("now", basically).  B I find it useful as-is, since "17-NOV-1858" popping up as a resultB somewhere makes it immediately obvious All Is Not As It Should Be.  C That said, what benefit was the engineer expecting to gain from theT4 new behavior that [s]he felt it'd be worth changing?   ------------------------------  % Date: Fri, 20 Jul 2001 09:43:09 -0700-+ From: "xenman" <xenman@sprynet.nospaam.com> $ Subject: Re: Zero Quadword Time Poll3 Message-ID: <9j9nj4$2u4$1@nntp9.atl.mindspring.net>T  = Hoff Hoffman <hoffman@xdelta.zko.dec.nospam> wrote in messagee- news:0sJ57.1022$rc5.70029@news.cpqcorp.net...a >sD >   The following is a trial balloon, and NOT something that we have >   immediate plans to change. >VH >   One of the local engineers has suggested changing the interpretationG >   of a OpenVMS quadword time containing a zero from its existing to a F >   new interpretation; from an absolute time (17-Nov-1858) to a delta >   time ("now", basically). >tF >   (Some folks here may remember seeing evidence of an existing tweakH >   within OpenVMS, a tweak that will convert a calculated delta of zero( >   into a delta of a very small value.) >hD >   Anybody here directly using a quadword zero as an absolute time? >   Supporters?  Detracters? >j( >  ---------------------------- #include' <rtfaq.h> -----------------------------tL >       For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com, >  --------------------------- pure personal# opinion --------------------------- 1 >    Hoff (Stephen) Hoffman   OpenVMS Engineeringo hoffman#xdelta.zko.dec.com >-  8 I have software that uses zero date as a 'null date'.  A& date that has not been written to yet.   ------------------------------  % Date: Fri, 20 Jul 2001 11:48:02 -0400-2 From: rdeininger@mindspring.com (Robert Deininger)$ Subject: Re: Zero Quadword Time PollL Message-ID: <rdeininger-2007011148030001@user-2ive7e0.dialup.mindspring.com>  3 In article <0sJ57.1022$rc5.70029@news.cpqcorp.net>, $ hoffman@xdelta.zko.dec.nospam wrote:  D >   The following is a trial balloon, and NOT something that we have >   immediate plans to change. > I >   One of the local engineers has suggested changing the interpretation iG >   of a OpenVMS quadword time containing a zero from its existing to a G >   new interpretation; from an absolute time (17-Nov-1858) to a delta   >   time ("now", basically). > G >   (Some folks here may remember seeing evidence of an existing tweak  I >   within OpenVMS, a tweak that will convert a calculated delta of zero n( >   into a delta of a very small value.) > D >   Anybody here directly using a quadword zero as an absolute time? >   Supporters?  Detracters?  G I can't think of a specific case, but I suspect there a more than a few B programs out there that use quadword 0 as a special marker, and do3 comparisons against the absolute time in text form.   G Would it be practical to provide per-process logical name that controls F the interpretation, so the old behavior would still be available where needed?)  J Too bad the IPF isn't ones-complement, so you'd have positive and negativeG zeros to play with.  Though I suppose that might break one or two othercE things during the port.  Have you considered porting VMS to the Cyberv7 architecture?  60 bits ought to be enough for anyone...1   ;-)8   --   Robert Deininger rdeininger@mindspring.comD   ------------------------------  % Date: Fri, 20 Jul 2001 18:49:51 +0200h  From: Paul Sture <paul@sture.ch>$ Subject: Re: Zero Quadword Time Poll+ Message-ID: <VA.00000401.1ae2974e@sture.ch>-  J In article <zoP1Gb+Wy3qL@eisner.encompasserve.org>, Larry Kilgallen wrote:j > In article <0sJ57.1022$rc5.70029@news.cpqcorp.net>, hoffman@xdelta.zko.dec.nospam (Hoff Hoffman) writes: > > F > >   The following is a trial balloon, and NOT something that we have  > >   immediate plans to change. > > K > >   One of the local engineers has suggested changing the interpretation  I > >   of a OpenVMS quadword time containing a zero from its existing to acI > >   new interpretation; from an absolute time (17-Nov-1858) to a delta D > >   time ("now", basically). > < > That might break programs that depend on a zero time field: > to mean that "this record has not been initialized yet",; > possibly doing a character substitution for "17-NOV-1858" 3 > after conversion.  That is ugly, but not illegal.o >X< FWIW I've seen order processing systems which used zero date; fields to mean "Not done yet" - e.g. Despatch date, Invoiceo< date, with reporting and programs actively using or ignoring those zero values. ___I
 Paul Sture Switzerlandg   ------------------------------  % Date: Fri, 20 Jul 2001 13:51:24 -0400-- From: JF Mezei <jfmezei.spamnot@videotron.ca>r$ Subject: Re: Zero Quadword Time Poll, Message-ID: <3B586F95.4AC62118@videotron.ca>   John Vottero wrote:9 > N > They aren't thinking of making a zero date/time mean "now", they're thinkingD > of making it mean delta zero.  A missing date would display as: "0 > 00:00:00.00".?  J In that case, wouldn't there be instances where some system services wouldP fail because they are being supplied a delta time instead of a date/time value ?   ------------------------------  % Date: Fri, 20 Jul 2001 07:52:45 -0400 - From: Britt Turnbull <britt.tmg@sympatico.ca>i! Subject: [FS] Symmetrix EMC2 5200 , Message-ID: <3B581B8D.3D6D0783@sympatico.ca>  	 Hi/2 All,n  , we have the following disk array for sale :-                         ( Symmetrix EMC2 Model 5200 sn # 181500782 Single bay unit 2                                                   = Includes            48   ST15150N          Seagate 4GB drivesa)                      4   SCSI 200-881-903s0                      4   UFD1 200-811-921  256MB$                      3   200-827-944$                      1   100-811-063$                      3   071-000-077  3 Please contact me direct for serious enquiries.....7   Regardsu   -- R BrittX   eCs + SMP OS/2 v4.51, eComstation.....the best just got better..../ OS2 the more you use it, the better it gets.....   ------------------------------    Date: 20 Jul 2001 12:15:06 +0200* From: eplan@kapsch.net (Peter LANGSTOEGER)6 Subject: [VMS PIR] More phases in startup phase file ?* Message-ID: <3b5804aa$1@news.kapsch.co.at>  C May I again suggest, that VMS gets another couple of startup phases E entered in SYS$STARTUP:VMS$PHASES.DAT in addition to the current onesIK especially in the LP phases (like LPBEGIN1-LPBEGIN9, LPMAIN1-LPMAIN9, ...).=  F I know I can do it for my systems personally, but I think, this is notB a big hassle for VMS engineering, won't break compatibility and if: engineering does it, every customer could benefit from it.   Many TIA   -- /< Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651; Network and OpenVMS system manager  Fax.    +43 1 81111-888 < <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netH A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------  % Date: Fri, 20 Jul 2001 14:30:19 +0200=> From: "Jean-Francois Marchal" <jean-francois.marchal@x9000.fr>: Subject: Re: [VMS PIR] More phases in startup phase file ?. Message-ID: <9j9876$7pu$1@reader1.imaginet.fr>  < I'm using the following extra phases in my startup process :  @ NETENVIRON after BASEENVIRON, where I start DECnet UCX & LAT ...8 USERENVIRON after LPBETA, where I start my applications, my$QUEUES_STARTUP.COM, ....    Jean-Franois MarchalG X9000 - Lyon (FR)p  D "Peter LANGSTOEGER" <eplan@kapsch.net> a crit dans le message news: 3b5804aa$1@news.kapsch.co.at... E > May I again suggest, that VMS gets another couple of startup phases0G > entered in SYS$STARTUP:VMS$PHASES.DAT in addition to the current onesuG > especially in the LP phases (like LPBEGIN1-LPBEGIN9, LPMAIN1-LPMAIN9,  ...).n > H > I know I can do it for my systems personally, but I think, this is notD > a big hassle for VMS engineering, won't break compatibility and if< > engineering does it, every customer could benefit from it. >o
 > Many TIA >o > --> > Peter "EPLAN" LANGSTOEGER           Tel.    +43 1 81111-2651= > Network and OpenVMS system manager  Fax.    +43 1 81111-888 > > <<< KAPSCH AG  Wagenseilgasse 1     E-mail  eplan@kapsch.netJ > A-1121 VIENNA  AUSTRIA              "I'm not a pessimist, I'm a realist"   ------------------------------   End of INFO-VAX 2001.400 ************************