1 INFO-VAX	Fri, 01 Mar 2002	Volume 2002 : Issue 117       Contents:% Affirm Your Opposition to the Merger? ) Re: Affirm Your Opposition to the Merger? ) Re: Affirm Your Opposition to the Merger? ) Re: Affirm Your Opposition to the Merger? ) Re: Affirm Your Opposition to the Merger?  After the merger vote strategy" Re: After the merger vote strategy API Networks Closing Its Doors& Re: Command line length limit and LINK+ Re: Compaq adopts microsoft approach to VMS + Re: Compaq adopts microsoft approach to VMS + Re: Compaq adopts microsoft approach to VMS 
 compaq c++ Re: copying system disks RE: decnet phase IV -> phase V Re: decnet phase IV -> phase V Re: decnet phase IV -> phase V RE: decnet phase IV -> phase V Re: decnet phase IV -> phase V Re: decnet phase IV -> phase V Re: decnet phase IV -> phase V Re: decnet phase IV -> phase V. Re: define "group-logicals" at system startup.
 Re: DFO Issue  Re: DTE Unsynchronised Re: expensive procedure calls  Re: expensive procedure calls 0 FYI - PHP holes leave Web servers open to attack7 HP & Compaq high-end systems to "stay around for years" ; Re: HP & Compaq high-end systems to "stay around for years" 6 Re: HP Sees Charges Up To $1.4 bln After Compaq Merger, Re: HSD30 licensing with mirroring and Cache Re: I: PAKGEN Software for ISVs  Re: Itanium troubles Re: Itanium troublesC Lock queues, how can granted queue be emply if waiting queue is not G Re: Lock queues, how can granted queue be emply if waiting queue is not + Re: Microsoft Curries Favor With Undergrads - Re: Need help on Alpha:  Calling C from MACRO  proliant 1600 not booting F Re: Q: Why is XP-1000 RAM so expensive from Compaq vis-a-vis Kingston?F Re: Q: Why is XP-1000 RAM so expensive from Compaq vis-a-vis Kingston?F Re: Q: Why is XP-1000 RAM so expensive from Compaq vis-a-vis Kingston?N Re: Question on a Deskpro EP`s motherbaord and possibily of changing it out :)N Re: Question on a Deskpro EP`s motherbaord and possibily of changing it out :)N Re: Question on a Deskpro EP`s motherbaord and possibily of changing it out :) Re: restricting access to ports  Re: restricting access to ports ! Re[2]: decnet phase IV -> phase V  Re: Solution for the merger  Re: Solution for the merger  Timing is everything Re: Timing is everything# Re: What return codes mean success? # Re: What return codes mean success?  Re: [Q] internet and VMS Re: [Q] internet and VMS  F ----------------------------------------------------------------------  # Date: Thu, 28 Feb 2002 19:42:30 GMT ' From: Don Sykes <anonymous@pacbell.net> . Subject: Affirm Your Opposition to the Merger?* Message-ID: <3C7E883E.15DC9A0@pacbell.net>  I I'm thinking of creating a web site where we could all go to register our N opposition to the merger. Not an anonymous one, but where you state your name,M email and job title. Then, after collecting sufficient valid "signatures", we O could issue the results as a press release. I think we as a group we could have M some clout, due in part to the authority, positions and background of the COV F community. We could also encourage the Tru64 community to participate.  I It would take me a day or so to set it up and test it (on VMS of course).  What say ye. --     Have VMS. Will Travel. Wire Paladin @alphase.com 
 San Francisco    ------------------------------  % Date: Thu, 28 Feb 2002 15:33:43 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 2 Subject: Re: Affirm Your Opposition to the Merger?, Message-ID: <3C7E941D.525F33E7@videotron.ca>   Don Sykes wrote:K > I'm thinking of creating a web site where we could all go to register our  > opposition to the merger.   L Until you know what Compaq's plan B is in case the merger fails, it might be* very dangerous to call for merger to fail.  G HP shareholders have every reason not to want to be burdened by Compaq.   D But I really do not know which side would best serve Compaq's legacy (Tandem/Digital) customers.   L Compaq jumped off the burning bridge hoping HP would catch it. If HP doesn'tJ catch Compaq, will Compaq be able to stop its fall and climb back onto theM burning bridge and not only extinguish the fire but also rebuild it ?  Compaq I has already favoured a slow ferry service (wintel) over the big , serious  bridge anyways.   N And perhaps Compaq hopes someone else will save it and catch it before it hits the frozen river.     I Having said that, I think that such a petition would be great if it could I outline to the media the fact that Compaq's most lucrative customers feel I abandonned because the product they use are either going to be abandonned T totally (Tru64) or never mentioned by HP as part of their plans to integrate Compaq.  F If the merger is going to be defeated, what your effort/website shouldK accomplish is sensitize the media to the fact that the high yield customers P are unhappy with the way Compaq ignores them, prefering to focus only on wintel.   ------------------------------  # Date: Thu, 28 Feb 2002 21:23:24 GMT ' From: Don Sykes <anonymous@pacbell.net> 2 Subject: Re: Affirm Your Opposition to the Merger?* Message-ID: <3C7E9FE5.FBC723A@pacbell.net>   JF Mezei wrote:  >  > Don Sykes wrote:M > > I'm thinking of creating a web site where we could all go to register our  > > opposition to the merger.  > N > Until you know what Compaq's plan B is in case the merger fails, it might be, > very dangerous to call for merger to fail. > I > HP shareholders have every reason not to want to be burdened by Compaq.  > F > But I really do not know which side would best serve Compaq's legacy > (Tandem/Digital) customers.  > N > Compaq jumped off the burning bridge hoping HP would catch it. If HP doesn'tL > catch Compaq, will Compaq be able to stop its fall and climb back onto theO > burning bridge and not only extinguish the fire but also rebuild it ?  Compaq K > has already favoured a slow ferry service (wintel) over the big , serious  > bridge anyways.  > P > And perhaps Compaq hopes someone else will save it and catch it before it hits > the frozen river.  > K > Having said that, I think that such a petition would be great if it could K > outline to the media the fact that Compaq's most lucrative customers feel K > abandonned because the product they use are either going to be abandonned V > totally (Tru64) or never mentioned by HP as part of their plans to integrate Compaq. > H > If the merger is going to be defeated, what your effort/website shouldM > accomplish is sensitize the media to the fact that the high yield customers R > are unhappy with the way Compaq ignores them, prefering to focus only on wintel.  I I agree with your points, although I would add that HP's MPE will also be N abandoned in the process, so this affects HP folks negatively too. I think theP petition should be short and focus on the future losses by all. Here's what I've come up with so far. ----------------------N We, the undersigned, represent a world wide community of executives, managers,F software and hardware developers, system administrators, educators andL technicians, in private industry and government who oppose the merger of theN Compaq Computer and Hewlett Packard corporations. We are serious professionalsD who believe that such a merger and the subsequent discontinuation ofM the OpenVMS, Tru64 and MPE operating systems will have an enormously negative O impact on the computing industry and substantially reduce the choices available P in the future. We believe that the short term gains made by such a consolidationL will be dwarfed by the long term losses to the information industry at large8 and, ultimately, to the combined HP/Compaq organization. --     Have VMS. Will Travel. Wire Paladin @alphase.com 
 San Francisco    ------------------------------  % Date: Thu, 28 Feb 2002 17:19:35 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca> 2 Subject: Re: Affirm Your Opposition to the Merger?, Message-ID: <3C7EACF2.F558825B@videotron.ca>   Don Sykes wrote:P > Compaq Computer and Hewlett Packard corporations. We are serious professionalsF > who believe that such a merger and the subsequent discontinuation ofO > the OpenVMS, Tru64 and MPE operating systems will have an enormously negative Q > impact on the computing industry and substantially reduce the choices available R > in the future. We believe that the short term gains made by such a consolidationN > will be dwarfed by the long term losses to the information industry at large: > and, ultimately, to the combined HP/Compaq organization.   Not strong enough.  L We are serious professionals who are very concerned about the the directionsJ outlined by the merger proponents who have conspicuously left out of theirN public plans the products on which our enterprises depend which also happen toL be Compaq's most profitable products. The precedent set by HP's treatment ofD its enterprise MPE product and Compaq's premature end-of-line of itsM commercial UNIX make us wonder what fate aways the other products such as VMS ' on which some 411,000 customers depend.   H Because of the way Compaq accounting aggregates enterprise products withJ wintel servers, it allows Compaq executives to portray their Wintel serverI business in a better light than it really is. Should enterprise customers K choose another vendor for long term infrastructure due to this uncertainty, K this may result in a significant drop in profits which would weight down HP N stuck with the Compaq wintel server product line which is less profitable than- Compaq's accountants had made them out to be.    ------------------------------  # Date: Fri, 01 Mar 2002 01:15:23 GMT ' From: Don Sykes <anonymous@pacbell.net> 2 Subject: Re: Affirm Your Opposition to the Merger?+ Message-ID: <3C7ED646.8AEFCBF8@pacbell.net>    JF Mezei wrote:  >  > Don Sykes wrote:R > > Compaq Computer and Hewlett Packard corporations. We are serious professionalsH > > who believe that such a merger and the subsequent discontinuation ofQ > > the OpenVMS, Tru64 and MPE operating systems will have an enormously negative S > > impact on the computing industry and substantially reduce the choices available T > > in the future. We believe that the short term gains made by such a consolidationP > > will be dwarfed by the long term losses to the information industry at large< > > and, ultimately, to the combined HP/Compaq organization. >  > Not strong enough. > N > We are serious professionals who are very concerned about the the directionsL > outlined by the merger proponents who have conspicuously left out of theirP > public plans the products on which our enterprises depend which also happen toN > be Compaq's most profitable products. The precedent set by HP's treatment ofF > its enterprise MPE product and Compaq's premature end-of-line of itsO > commercial UNIX make us wonder what fate aways the other products such as VMS ) > on which some 411,000 customers depend.  > J > Because of the way Compaq accounting aggregates enterprise products withL > wintel servers, it allows Compaq executives to portray their Wintel serverK > business in a better light than it really is. Should enterprise customers M > choose another vendor for long term infrastructure due to this uncertainty, M > this may result in a significant drop in profits which would weight down HP P > stuck with the Compaq wintel server product line which is less profitable than/ > Compaq's accountants had made them out to be.   N In order to garner the widest possible audience of folks dissatisfied with theN direction of these 2 companies, I would leave out as many details as possible,I since everyone may have different ideas about which are the most grievous O actions, or expectations of actions. The idea is to have at least one statement P on which we can ALL agree. Also, I think we need to make a statement that can beP understood by everyone, especially those persons and institutions outside of ourN industry who are stockholders, but technically ignorant. IMHO A statement by aL large group of seasoned professionals, no matter how terse, will make a muchP larger impact in the world at large than a statement describing specific gripes.     --     Have VMS. Will Travel. Wire Paladin @alphase.com 
 San Francisco    ------------------------------  # Date: Thu, 28 Feb 2002 22:09:28 GMT # From: "John Smith" <a@nonymous.com> ' Subject: After the merger vote strategy 0 Message-ID: <sUxf8.1658$K4l.1295@news2.bloor.is>   Okay everyone,  K We've all (mostly) been thinking about ways to deal with the merger. Now we < have to consider what we do afterwards, merger or no merger.  > Clearly the Compaq Board and senior executives need a thoroughC housecleaning. The question is, whom do WE wish to see in strategic L positions, both on the Board and in management, where it is a merger company or not.   J We need to know how to introduce motions on the floor of the shareholder'sJ meeting or otherwise, proposing a new slate of Directors & Officers. SinceI the shareholders meeting will be well attended and publicized, perhaps we J need to present it there so that in the event it is haughtily dismissed byL Curly, et al., the television cameras will catch it and the WSJ will take up> the challenge. The power isn't all in the hands of management.  J If this approach is taken, and a new slate of directors can be voted on at@ the merger meeting -- most large institutional investors will beF represented, and management collectively does not own enough shares toH influence the outcome in an honest vote (ok, we are talking Texas in theI case of Compaq.....), it may well be that this new slate of directors are J just temporary until a high-profile set of directors who really understand! business can be brought on-board.   K My votes for the long-term would include guys (if available and interested) J like Jack Welch, Lou Gerstner,  a senior telco and/or retail person and/orF major bank, maybe somebody from Europe, Senor Shannon to represent ourL collective user interests, perhaps someone from a high-profile scientific orL pharmaceutical background (not a 'drone'), maybe somebody ex-NSA/CIA. Again,J these are just examples of the types of people who should be on the board, not just crony's.    ------------------------------  # Date: Fri, 01 Mar 2002 02:50:54 GMT 0 From: William Barnett-Lewis <wlewis@mailbag.com>+ Subject: Re: After the merger vote strategy + Message-ID: <3C7EEC7B.ADE08997@mailbag.com>    John Smith wrote:  >  > Okay everyone, > M > We've all (mostly) been thinking about ways to deal with the merger. Now we > > have to consider what we do afterwards, merger or no merger.  C oh, irregardless of anything, your strategy is really quite simple: 
 1) Bend over   2) Spread asscheeks  3) Kiss said ass goodbye  G And then get used to living like every other orphaned hardware/software E group (ie amiga?) that has ever haunted usenet. Cause, let's face it, H VMS is dead either way. Nierher corp understands it's value - it's toast+ within months no matter what else happens.    F Yeah, I'm a newby and I've come to really enjoy it. But it ain't UnixyG enough to survive the coming disaster. And in the end, that is all that ( matters to those who controll the money.    E Shrug. You want a better analysis of what's happening right now? Read D the works of Michael Harrington. He explains all of this much better than I can.    William  --  * You better watch out    What you wish for;+ It better be worth it   So much to die for. -                                 Courtney Love    ------------------------------   Date: 28 Feb 2002 23:29:44 GMT) From: leslie@clio.rice.edu (Jerry Leslie) ' Subject: API Networks Closing Its Doors ' Message-ID: <a5meh8$5ap$1@joe.rice.edu> $ Keywords: api,networks,alpha,closing  .      http://news.com.com/2100-1001-848153.htmlA      Promoter of storied Alpha shuts doors - Tech News - CNET.com   (    Promoter of storied Alpha shuts doors    By John G. Spooner     Staff Writer, CNET News.com      "February 28, 2002, 2:35 PM PTH    API Networks, an important player in the history of the storied Alpha(    processor, is about to close up shop.  I    The Concord, Mass., company is winding down operations and will go out H    of business shortly, a victim of slow sales of the Alpha, a chip someF    thought superior to Intel's famous Pentium but that never caught on    with manufacturers.  D    A few remaining API employees also cited as a cause in the demiseI    Compaq Computer's June 2001 decision to license the Alpha to Intel andiG    adopt Intel Itanium chips for servers. Although Compaq has committedhH    to coming out with future versions of the Alpha, most Alpha engineers;    have already left Compaq to work on Itanium at Intel..."   4 --Jerry Leslie     (my opinions are strictly my own)   ------------------------------  + Date: Thu, 28 Feb 2002 20:28:16 +0000 (UTC)p7 From: lewis@lumina-spam-zero.mitre.org (Keith A. Lewis)p/ Subject: Re: Command line length limit and LINKt. Message-ID: <a5m3t0$3k7$1@newslocal.mitre.org>   Ernest <wmozart5@yahoo.com> writes in article <Hubf8.29360$7a1.2003704@bin5.nnrp.aus1.giganews.com> dated Wed, 27 Feb 2002 20:40:07 GMT:K >Is there any way around this?  Like, for example, response files (Windows sB >compilers generally support this sort of thing, as does the Java L >compiler)?  Or creating the library/program incrementally (which is what I F >have to do to create object libraries, and thankfully LIBRARY can be K >called multiple times with /INSERT to incrementally build the library one e% >object at a time).  Any other ideas?c  P Several people have pointed out the .OPT file.  IMHO object libraries are nicer.  # Library takes wildcard arguments.  l  E $ LIBRARY MYLIB *	! will insert/replace all .OBJ files into MYLIB.OLBlO $ LINK MYLIB/LIB/INCLUDE=main ! will link MAIN.OBJ and any other objects neededd  + --Keith Lewis              klewis%mitre.orgt> The above may not (yet) represent the opinions of my employer.   ------------------------------  % Date: Thu, 28 Feb 2002 21:45:15 -0000p- From: wspencer@ap.nospam.org (Warren Spencer)A4 Subject: Re: Compaq adopts microsoft approach to VMS7 Message-ID: <91C3ACF68warrenspencer1977@209.249.90.100>n  7 antony.wardle@optusnet.com.au (Antony Wardle) wrote in a1 <fe52053.0202261622.4183b2e7@posting.google.com>:   E >Anyone else concerned that unless you are running the latest versioniC >of VMS then you are now on Prior version/best endeavor support fore >fixes?V > 5 >What does this say about Compaqs committment to VMS/r< >Lets force everyone to upgrade, doesn't that sound like MS?  
 -- snip --  L I find the OpenVMS approach significantly different from Microsoft's.  Some $ of the differences I've encountered:  L - Difficulty finding MS documentation on the contents of their patches, and ? precisely what it affects (a simple file list is not much help)nG - Inability to roll back, but perhaps that's more due to a decent back 3 native backup/restore mechanismnJ - Difficulty in determining which MS patches are required, which versions K of what products are installed, and which shared libaries might be affected G - MS changes it support & licensing options often, it seems usually to  1 their advantage and the expense of the customer's G - MS documentation is seldom explicitly labelled with software version o identifiersaI - Lack of regression testing and certification of MS patches and releasesy  L Hoff's excellent reply later in this thread regarding Prior Version Support 4 should help you select the best option in your case.   ws   -- P   Warren Spencer' Senior Software Engineer (not a writer)- The Associated Press  < ** Time flies like an arrow.  Fruit flies like a bananna. **   ------------------------------  % Date: Thu, 28 Feb 2002 18:15:38 -0500-  From: John Santos <JOHN@egh.com>4 Subject: Re: Compaq adopts microsoft approach to VMS5 Message-ID: <1020228175840.9016A-100000@Ives.egh.com>i  # On 28 Feb 2002, Bob Ceculski wrote:w  _ > John Santos <JOHN@egh.com> wrote in message news:<1020227185421.3430B-100000@Ives.egh.com>...f' > > On 27 Feb 2002, Bob Ceculski wrote:  > > t > > > "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> wrote in message news:<D0Ye8.237$fL6.5571@news.cpqcorp.net>...T > > > > Beyond a certain point, it becomes very costly to debug and fix a problem inO > > > > an old release.  Prior version support allows you to get the fix if youoP > > > > really need it, and want to pay for the engineering.  If you want normalM > > > > maintenance, then you need to be running a release that is relatively P > > > > current.  Note that we support V7.2-2, and will for some time to come...S > > > > how many years did we keep a V7.1x version current - quite a few.  It isn'tiM > > > > like we are obsoleting releases every other day.  V7.2-2 was built totS > > > > consolidate all the fixes and hardware support in the V7.2 releases, and totF > > > > *not* force people into upgrading to a new functional release. > > > > T > > > > We *don't* expect people to upgrade immediately, which is why we support theT > > > > current release, and an earlier release (7.3 and 7.2-2 today).   But we willS > > > > eventually release a new functional release, and then V7.3x and the current / > > > > release will become the supported pair.e > > > >  > > > M > > > that is not true ... we would like to get the decwindows cert patch foroK > > > 7.1-1H2 and is only available for 7.1-2 ... that is a forced upgrade!e > > + > > What is 7.1-1H2????  Never heard of it.a > > J > > The DECwindows ECO is available for Alpha V6.2 (all variants), V7.1-2,E > > V7.2-1, V7.2-1H1, V7.2-2, V7.3 and VAX V6.2, V7.1, V7.2, V7.3 anda$ > > SEVMS V6.2 (both Alpha and VAX). > 6 > there are versions 7.1-1, 7.1-1H1, 7.1-1H2 out here!  B When I read another followup, I realized I had mis-read 7.1-1H2 asA 7.2-1H2.  AFAIK, there is no such thing as 7.2-1h2, just 7.2-1H1.a  D Still, how much are you willing to pay to have Compaq produce an ECOE for every version of VMS ever issued?  Given that they have no way of H even knowing if anyone in the whole world is still running that version,C wouldn't it make more sense to only support versions that customersoE specifically request, and to charge more for support on versions with  very few customers?q  F Even if the ECO involves shipping only the identical replacement filesH and there is no need to retrofit source changes, debug them, and compileC (on that version, so there aren't library incompatibilities, etc.),lF they still have to produce a kit, test install it, verify that it doesA fix the problem and doesn't break anything else, publish the fix,dE notify any supported customers who have reported the problem that the D ECO exists, possibly hand-holding during ECO installation, etc. etc.C None of this is cheap, and from the standpoint of customers who are 0 current, it is a waste of their support dollars.  A It also takes engineer time away from fixing other problems (XFC,I> anyone?) and implementing new features or improvements for new	 versions.f  @ If they had a "pay as you go policy" for fixing problems in veryB old versions (I don't know if PVS works this way, or if it is justC a premium-priced support for certain old versions that delivers thewB same support as normal support does for current versions), it may C very well be cheaper for you to update your 35 systems to somethingvD more recent than to pay Compaq to produce a special ECO kit just for
 your version.    --   John Santos  Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  # Date: Fri, 01 Mar 2002 01:57:12 GMTE1 From: "David J. Dachtera" <djesys.nospam@fsi.net> 4 Subject: Re: Compaq adopts microsoft approach to VMS' Message-ID: <3C7EE152.D7623D7B@fsi.net>r   antony wardle wrote: >  > Ok > < > so the millions my company pays for support doesn't count? > < > What if you are locked into a version of vms because of an > application?  ? ...or government agency regulations? (certifications and so on)n  ( > Im now stuck between a rock and a hard > place.  H ...like many VMS shops in the healthcare, financial, etc. markets (i.e., VMS's chosen niche).   -- j David J. Dachterar dba DJE Systemse http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/l   ------------------------------  # Date: Thu, 28 Feb 2002 22:58:06 GMTt. From: "Jeffrey Cameron" <bubbapig@hotmail.com> Subject: compaq c++T. Message-ID: <2Cyf8.980$635.947@news1.bloor.is>   I have a question:  J I am converting a C program to C++ on an Alpha and am trying to find a way: to convert the DEC C usage of fopen which looks like this:  G fopen(filename,"wb+", "mrs=length*4", "ctx=xplct", "rfm=var", "rat=cr")i      I into something that uses C++ iostream/fstream libraries. I mean I can usezL this if I have to but I would prefer to have everything C++ in the end as itE seems to be a little nicer to read, use and defintiely more typesafe.a       Thanks in advance    ------------------------------    Date: 28 Feb 2002 13:06:07 -08001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)d! Subject: Re: copying system disksa= Message-ID: <cf15391e.0202281306.5f0126cb@posting.google.com>-  | Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> wrote in message news:<01KET9GQMAMA8ZL57Q@sysdev.deutsche-boerse.com>...H > It seems to me to be a waste of time to maintain more than one system H > disk if they are more or less similar (same VMS version, same layered I > products installed etc).  Especially if one wants to remain up-to-date sH > on patches etc, some of which require a reboot after installation.  A K > better approach would seem to be to have a "master system disk" which is dC > maintained.  This could then be copied to the other system disks i# > whenever they need to be updated.a  > Once folks get beyond 2 or 3 system disks, this becomes a veryF attractive option to many.  (For example, I know of someone who had anF LAVC with 80 or so satellite nodes, each of which had their own system disk!)  F As another poster has pointed out, this is much easier if the "master"C disk has a separate root for every node in the cluster (even thoughoF you won't use all the roots on a given copy of the system disk).  ThisA way, you don't have to change the nodename and network setup infosF every time you copy the disk; you just give each system its own uniqueD root number, and set things up those things properly on the "master"F disk just once: when you add a new node.  (If you were short on systemB disk space, you _could_ delete the unused roots on each copy after< copying the master system disk, but be careful to delete theE SYSCOMMON.DIR file entries in those roots with $SET FILE/REMOVE firsto8 so you don't accidentally delete the common area, too!).  F The biggest help I've found in maintaining multiple system disks is toC move _off_ of the system disk, as much as possible, any files which D can be placed on other disks -- especially any files that tend to be= modified over time.  I recommend that even startup files likerE SYSTARTUP_VMS.COM on each system disk be simply a stub that calls thetC "real" copy on a "cluster-common" disk (shadowed for reliability). eF (To do this, you do have to mount the cluster-common disk somewhere inB startup; I like to do that in the stub SYLOGICALS.COM file on eachF system disk, which, after mounting the cluster-common disk, then callsD the "real" SYLOGICALS.COM from the common area.)  This way, there isD only one copy of all the startup files for the entire cluster in one$ place, where it is easy to maintain.  D I also like to have the bare minimum in MODPARAMS.DAT (typically not@ much more than SCSNODE and SCSSYSTEMID) and use the AGEN$INCLUDEB capability to include the rest of the parameters from files on the cluster-common disk.  = Here's a list of files to re-direct to a cluster-common disk:s  SYSUAF.DATi  RIGHTSLIST.DATh  NETPROXY.DAT and NET$PROXY.DATr  VMSMAIL_PROFILE.DATAc  LMF$LICENSE.LDB  NETOBJECT.DAT  NETNODE_REMOTE.DATa;  VMS$PASSWORD_HISTORY.DATA and VMS$PASSWORD_DICTIONARY.DATAi#  SYLOGIN.COM (SYS$SYLOGIN: logical)a  QMAN$MASTER: filesvE and the security audit log file (see SYSECURITY.COM).  You might alsotA consider OPC$LOGFILE_NAME: for OPERATOR.LOG and SYS$ERRORLOG: for F ERRLOG.SYS and ACCOUNTNG: for ACCOUNTNG.DAT files to move them off the system disk.  F You can also move system dump files off the system disk using the DOSD	 facility.-  : I would recommend making the following files just stubs in SYS$COMMON:,C pointing to the "real" copy in the cluster-common area, at least if  youm( modify then from their default contents:;  SYLOGICALS.COM (the stub needs to mount the cluster-common.9     disk before it transfers control to SYLOGICALS.COM in)!     the cluster-common directory)i
  SYCONFIG.COMN  SYPAGSWPFILES.COM  SYSECURITY.COMf  SYSTARTUP_VMS.COM  SYSHUTDWN.COM  B There is some valuable information that builds up on a system diskC that you probably want to save across a system disk update (AUTOGENnE feedback data, and the current SYSGEN parameter file, are a couple ofr obvious examples.)  A Here's a list of files to preserve and restore after you copy thet system disk:F  ALPHAVMSSYS.PAR & ALPHAVMSSYS.OLD ((VAXVMSSYS.PAR & VAXVMSSYS.OLD for VAXen)  AGEN$FEEDBACK.DAT:  MODPARAMS.DAT, PARAMS.DAT, SETPARAMS.DAT, AUTOGEN.PAR and AGEN$PARAMS.REPORT  VMSIMAGES.DAT  D And you probably want to save away (but not necessarily restore) anyE *.DMP files you might need to preserve for Compaq's use in diagnosingm4 problems (both process dumps and system dump files).? ---------------------------------------------------------------r? Keith Parris | parris at encompasserve dot org | Consulting on:o> Clusters, Disaster Tolerance, Performance, I/O, Storage & SANs   ------------------------------  % Date: Thu, 28 Feb 2002 15:02:58 -0500t+ From: "Main, Kerry" <Kerry.Main@Compaq.com> ' Subject: RE: decnet phase IV -> phase V T Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4016CEB14@kaoexc01.americas.cpqcorp.net>   Jim,   Fyi - doc pointer.4 http://www.openvms.compaq.com:8000/index.html#decnet   Regardst  
 Kerry Main Senior Consultantl Compaq Canada Corp.  Professional Serviceso Voice: 613-592-4660o Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----5 From: Jim Strehlow [mailto:jimSnoSpam@data911.com]=20,  Sent: February 28, 2002 12:12 PM To: Info-VAX@Mvb.Saic.Comf' Subject: Re: decnet phase IV -> phase V     * 1) thanks for the phase IV to phase V tips  D 2) we are probably going to install some FDDI cluster failover cable0   which requires phase V onto one remote system.E   So if I am going to install that soon, I need to "get up to speed".   @ 3) On a test node I first installed phase IV and got it working.+   I uninstalled that and installed phase V.m  6 4) I can not import node information from another node7   without first changing that phase IV node to phase V,rE   running the conversion, and then exporting the phase V information.    (can not get there from here)   8   Instead, I will manually register the node information   onto my new test system.  * 5) I am happily going to maintain Phase IV!   on twenty+ other nodes for now.r   Again, thanks for sharing.   Jim Strehlow, Data911n Alameda, CA, USA   ------------------------------  # Date: Thu, 28 Feb 2002 20:30:55 GMTu# From: "John N." <JNixon@cfl.rr.com>h' Subject: Re: decnet phase IV -> phase Vs< Message-ID: <3swf8.6758$1p6.1842387@typhoon.tampabay.rr.com>  E Oh,   I never thought of that!   But outside of a huge multi-nationaloK corporation with thousands of nodes, what software actually requires PhaseV F decnet?  (Except for certain bisynch drivers ,which Compaq is dropping support for anyway).  : "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message- news:Bf2TYf982R4g@eisner.encompasserve.org...bH > In article <Mxrf8.6667$1p6.1542930@typhoon.tampabay.rr.com>, "John N." <JNixon@cfl.rr.com> writes:  > >s9 > > "Paul Sture" <paul.sture@bluewin.ch> wrote in messages' > > news:3C7E04A3.6030203@bluewin.ch...m > >> Jim Strehlow wrote: > >> > >  >K > >> You will find various folks trying to persuade you not to use Phase V,A	 > > basedd > >>J > >> on their initial experiences with it. It really isn't so bad once you get: > >> > >> used to it. > >>F > > The same can be said for creamed spinach or Unix or rape.  But why shouldJ > > one go through the pain and agony of "getting used to it" unless there is aJ > > pressing need.  For most people, phase IV will do the job reliably and > > easily.t >gB > Some people like to prepare themselves for future possibilities,> > such as the need to run some software that requires Phase V. >s   ------------------------------  % Date: Thu, 28 Feb 2002 15:37:22 -0500t- From: JF Mezei <jfmezei.spamnot@videotron.ca>c' Subject: Re: decnet phase IV -> phase Vm, Message-ID: <3C7E94F8.1F1C339F@videotron.ca>   "Main, Kerry" wrote: > Fyi - doc pointer.6 > http://www.openvms.compaq.com:8000/index.html#decnet  L It would greatly help if Digital were to proviode PDF or BOOREADER documents? that can be printed into a readable book instead of HTML pages.@  K One really needs to sit down and read the stuff and HTML is not well suitedl
 for that.   E Is there a reason the web site doesn't provide bookreader documents ?h   ------------------------------  % Date: Thu, 28 Feb 2002 16:09:49 -0500c+ From: "Main, Kerry" <Kerry.Main@Compaq.com> ' Subject: RE: decnet phase IV -> phase VmT Message-ID: <BE56C50EA024184DAF48F0B9A47F5CF4016CEB18@kaoexc01.americas.cpqcorp.net>  
 G'day JF -  F >>> It would greatly help if Digital were to provide PDF or BOOKREADERB documents that can be printed into a readable book instead of HTMLF pages. Most of all the new release doc's come in PDF or HTML format. I? suspect it is primarily the older doc's that are HTML only. <<<e  
 Reference:8 http://www.openvms.compaq.com:8000/index.html#ovmsdocset   Regardsa  
 Kerry Main Senior ConsultantI Compaq Canada Corp.i Professional Servicesf Voice: 613-592-4660  Fax  :  819-772-7036 Email: Kerry.Main@Compaq.com     -----Original Message-----7 From: JF Mezei [mailto:jfmezei.spamnot@videotron.ca]=20a Sent: February 28, 2002 3:37 PMs To: Info-VAX@Mvb.Saic.Com-' Subject: Re: decnet phase IV -> phase Ve     "Main, Kerry" wrote: > Fyi - doc pointer.=20g6 > http://www.openvms.compaq.com:8000/index.html#decnet  B It would greatly help if Digital were to proviode PDF or BOOREADERB documents that can be printed into a readable book instead of HTML pages.  D One really needs to sit down and read the stuff and HTML is not well suited for that.=20g  E Is there a reason the web site doesn't provide bookreader documents ?a   ------------------------------  % Date: Thu, 28 Feb 2002 13:45:27 -0800n0 From: Mark Berryman <Mark.Berryman@Mvb.Saic.Com>' Subject: Re: decnet phase IV -> phase V , Message-ID: <3C7E3477.4D14DF07@Mvb.Saic.Com>   Jim Strehlow wrote:S > , > 1) thanks for the phase IV to phase V tips > F > 2) we are probably going to install some FDDI cluster failover cable2 >   which requires phase V onto one remote system.G >   So if I am going to install that soon, I need to "get up to speed".c  G Not true.  Cluster and DECnet are in no way related.  If the purpose ofhG your FDDI cable is to provide an alternate path for cluster traffic, nol change to DECnet is needed.   B > 3) On a test node I first installed phase IV and got it working.- >   I uninstalled that and installed phase V.  > 8 > 4) I can not import node information from another node9 >   without first changing that phase IV node to phase V,kG >   running the conversion, and then exporting the phase V information.o! >   (can not get there from here)t  H Had you upgraded from phase IV instead of uninstalling it you would have@ discovered that this is also not true.  Converting your phase IVG database to a phase V database is one of the steps available as part ofr the upgrade.  H On any phase V system, you will also find a utility in SYS$UPDATE calledE NET$CONVERT_DATABASE.EXE which is what is used to do the conversion. CE You can run this whenever you need to.  Information on this and otherAF migration aids can be found in section 3.1 of the DECnet-Plus planning guide.  : >   Instead, I will manually register the node information >   onto my new test system. > , > 5) I am happily going to maintain Phase IV# >   on twenty+ other nodes for now.c >  > Again, thanks for sharing.  B Part of the problem with this particular forum is that there are aE handful of posters who appear to have a tremendous amount of time foraH posting here and they let their biases show through when doing so.  MostC of them do not like, or see no reason for, DECnet phase V and speak = against it given any opportunity to do so.  So let me give an  alternative point of view:  H DECnet phase V is trivial.  I converted all of our DECnet nodes to phaseH V over two years ago and haven't had a single issue with it.  It is easyG to setup, easy to manage, and easy to query it for information.  What'ssG the catch?  It is a completely different approach from phase IV and you E need to actually read some documentation (but by no means all of it).n  G Take the nay-sayers with a grain of salt.  It simply isn't as difficultd as they make it out to be.  
 Mark Berryman  Mark.Berryman@Mvb.Saic.Com   ------------------------------    Date: 28 Feb 2002 15:46:50 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen) ' Subject: Re: decnet phase IV -> phase Vi3 Message-ID: <ZrzYps4jt3DV@eisner.encompasserve.org>   b In article <3swf8.6758$1p6.1842387@typhoon.tampabay.rr.com>, "John N." <JNixon@cfl.rr.com> writes:G > Oh,   I never thought of that!   But outside of a huge multi-national-M > corporation with thousands of nodes, what software actually requires PhaseVh	 > decnet?    The X.500 Directory Service.   ------------------------------  % Date: Thu, 28 Feb 2002 23:24:29 +0100( From: Dirk Munk <munk@home.nl>' Subject: Re: decnet phase IV -> phase Vt& Message-ID: <3C7EAE1D.3030701@home.nl>   Mark Berryman wrote:   >Jim Strehlow wrote: >I, >>1) thanks for the phase IV to phase V tips >>F >>2) we are probably going to install some FDDI cluster failover cable2 >>  which requires phase V onto one remote system.G >>  So if I am going to install that soon, I need to "get up to speed".l >> >gH >Not true.  Cluster and DECnet are in no way related.  If the purpose ofH >your FDDI cable is to provide an alternate path for cluster traffic, no >change to DECnet is needed. > B >>3) On a test node I first installed phase IV and got it working.- >>  I uninstalled that and installed phase V.n >>8 >>4) I can not import node information from another node9 >>  without first changing that phase IV node to phase V,oG >>  running the conversion, and then exporting the phase V information.s! >>  (can not get there from here)e >> > I >Had you upgraded from phase IV instead of uninstalling it you would have A >discovered that this is also not true.  Converting your phase IVoH >database to a phase V database is one of the steps available as part of
 >the upgrade.e > I >On any phase V system, you will also find a utility in SYS$UPDATE calledrF >NET$CONVERT_DATABASE.EXE which is what is used to do the conversion. F >You can run this whenever you need to.  Information on this and otherG >migration aids can be found in section 3.1 of the DECnet-Plus planning  >guide.t > : >>  Instead, I will manually register the node information >>  onto my new test system. >>, >>5) I am happily going to maintain Phase IV# >>  on twenty+ other nodes for now.u >> >>Again, thanks for sharing. >> >hC >Part of the problem with this particular forum is that there are a F >handful of posters who appear to have a tremendous amount of time forI >posting here and they let their biases show through when doing so.  MostED >of them do not like, or see no reason for, DECnet phase V and speak> >against it given any opportunity to do so.  So let me give an >alternative point of view:l >rI >DECnet phase V is trivial.  I converted all of our DECnet nodes to phaseoI >V over two years ago and haven't had a single issue with it.  It is easypH >to setup, easy to manage, and easy to query it for information.  What'sH >the catch?  It is a completely different approach from phase IV and youF >need to actually read some documentation (but by no means all of it). >nH >Take the nay-sayers with a grain of salt.  It simply isn't as difficult >as they make it out to be.p >M >Mark Berryman >Mark.Berryman@Mvb.Saic.Coml >      Hear Hear !!  E Very true. I've been using Phase V for some 10 years now., and it is rH realy not so difficult. It follows the OSI  7-layer model, and that can F be a blessing when you're searching for errors / problems. It is also G faster, at least when I had the opportunity to test the speed of Phase u IV and V a long time ago.i  B And it is also easy to use DECnet over IP with Phase V, making it ? possible to use Copy to download freeware, instead of FTP.  ;-)a         >.   ------------------------------    Date: 28 Feb 2002 16:03:48 -08001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)c' Subject: Re: decnet phase IV -> phase Va= Message-ID: <cf15391e.0202281603.2982836f@posting.google.com>-  e "Jim Strehlow" <jimSnoSpam@data911.com> wrote in message news:<a5locr$8sp@dispatch.concentric.net>...pF > 2) we are probably going to install some FDDI cluster failover cable2 >   which requires phase V onto one remote system.G >   So if I am going to install that soon, I need to "get up to speed".o  @ Is the requirement for Phase V because you're connecting two LAN? adapters on the same VMS node to the same extended LAN, and are C concerned because DECnet Phase IV will set the same MAC address (in - AA-00-04-00-yy-xx form) on both LAN adapters?e  D If DECnet Phase IV knows nothing about a LAN adapter (that is, thereD is no LINE or CIRCUIT defined for it at all), it will not change theE MAC address, but leave it at the original physical/hardware address. nC It is important that no LINE or CIRCUIT be defined, because even if C they're defined as STATE OFF their MAC address will be changed when D DECnet Phase IV starts up.  And if you start LAT on the 2nd adapter,5 use the /NODECNET qualifier when you create the link.s  D Of course, if you do the above, DECnet will not be able to fail over to the other LAN adapter.n  D If both your LAN adapters are on the same extended LAN, keep in mind< that both will be subject to the delays due to spanning-treeF reconfigurations on that extended LAN.  This often means RECNXINTERVAL= must be raised to 3-5 minutes or more.  You would have higherp? availability if the two LAN adapters were connected to separateaE (non-bridged) LANs, and you wouldn't have problems with duplicate MACeF addresses (or else the inability to fail over to the 2nd adapter) withE DECnet Phase IV in that case, either.  And you might well not have totA raise RECNXINTERVAL from the default of 20 seconds if you had twoe> independent LANs, because it's very unlikely that you'd have aC spanning-tree recofiguration on both of the independent LANs at theh
 same time.? ---------------------------------------------------------------y? Keith Parris | parris at encompasserve dot org | Consulting on:n> Clusters, Disaster Tolerance, Performance, I/O, Storage & SANs   ------------------------------  $ Date: Fri, 1 Mar 2002 11:36:59 +1100/ From: "Phil Howell" <phowell@snowyhydro.com.au>e7 Subject: Re: define "group-logicals" at system startup.I- Message-ID: <R3Af8.68$RH.6665@ozemail.com.au>e  3 "Jan-Erik Sderholm" <aaa@aaa.com> wrote in messager! news:3C7E1B16.C013E7A3@aaa.com..."@ > There have been a number of post on this issue now, all giving2 > RUN/UIC=xxx or SUBMIT/USER=yyy as the way to go. > < > Isn't there a way for SYSTEM to directly create this table6 > without using one of the users in the actual group ? >h > Such as :S >E > $ create /name_table - >          /exec -/ >          /parent_table=LNM$SYSTEM_DIRECTORY -o >          LNM$GROUP_zzzzzzn >s  ( Yes we do something very similar to this  8 > Is there some problem with the "owner" of this table ? >RK If you do a SET UIC to the relevant group first then the group is the ownerE (we also use ACLs on the table)S   Phil > Jan-Erik Sderholm.P   ------------------------------  + Date: Thu, 28 Feb 2002 23:25:56 +0000 (UTC)e= From: lewis@luminascrewsupspammers.mitre.org (Keith A. Lewis)m Subject: Re: DFO Issue. Message-ID: <a5mea4$423$1@newslocal.mitre.org>  x "Barry Treahy, Jr." <Treahy@mmaz.com> writes in article <3C7D46B0.80807@mmaz.com> dated Wed, 27 Feb 2002 13:50:56 -0700:F >a recommendation.  Contact Raxco and ask for a demo version of their H >PerfectDisk product.  Shutdown DFO and try it, you may find that it is J >worth changing loyalties with regard to disk defraging because I suspect H >it will do a much better job...  We've had a long time experience with = >Raxco and they are good folks that put out a good product...A  G While we're giving recommendations, I'll tell you why I moved the otherL' direction -- from Perfectdisk to DFO.  C  K Raxco uses a different (non-PAK) licensing scheme.  To get the license, yousL must install the software and pay for it, run a utility that reads some info? from your system, send the info to Raxco, and wait for the key.p  J I rebuilt my system disk a couple of times in the early 1990s.  Both timesI the key stopped working.  The first time they were nice and re-did it forMJ free.  The second time they noticed I had upgraded the CPUs in my cabinet.  F "So you upgraded from an Alphaserver 2100 4/250 to an Alphaserver 2100# 5/300.  You owe us a transfer fee."w   "But it's the same machine!"   No luck.  I I bought DFO instead and have not had any problems putting the license onoI whatever damn server I wish.  Last year I replaced the 2100 with a DS20E,-J rebuilding the system disk from scratch, and my PAK transferred just fine.  K I have heard PAKs outside the US are hardware-specific, so you might have a C similar problem.  But if you're in the US it makes sense to get the2 flexibility of portable PAKs.   + --Keith Lewis              klewis$mitre.orgh> The above may not (yet) represent the opinions of my employer.   ------------------------------  % Date: Thu, 28 Feb 2002 23:35:22 +0100p From: Dirk Munk <munk@home.nl> Subject: Re: DTE Unsynchronisede& Message-ID: <3C7EB0AA.3000109@home.nl>  F It means that for some reason there is not a good connection with the . LAPB link on the other site of the connection.  F That can have many causes. Wrong speed settings, cable problem, modem  problem, and so on.2       pat saunders wrote:M   >Hi,' >  I am using DECNET/OSI on a MicroVax,s% >  I am using a LAPB circuit on DTE-0 E >  When I look at state of DTE , I find it is "Unsynchronised" , Whata2 >is the cause of this message and how do I fix it, >s; >   I find that the LAPB link goes up and down like a yo-yoe >   : & >   Message from user SYSTEM on KEWG99C >Event: Link Setup Failed from: Node LOCAL:.KEWG99 LAPB Link DTE-0,l. >        at: 2002-02-28-17:16:00.693+00:00Iinf8 >        eventUid   D645CF84-2C6E-11D6-8008-AA0004009E2A8 >        entityUid  3718B880-2C6E-11D6-8007-AA0004009E2A8 >        streamUid  61C47CE0-2C6E-11D6-8008-AA0004009E2A >o >e >NCL> 9 >%%%%%%%%%%%  OPCOM  28-FEB-2002 17:16:00.75  %%%%%%%%%%% # >Message from user SYSTEM on KEWG99aC >Event: Link Initialising from: Node LOCAL:.KEWG99 LAPB Link DTE-0, . >        at: 2002-02-28-17:16:00.693+00:00Iinf/ >        Link Initialising Reason=Maximum Retry-8 >        eventUid   D645CF85-2C6E-11D6-8008-AA0004009E2A8 >        entityUid  3718B880-2C6E-11D6-8007-AA0004009E2A8 >        streamUid  61C47CE0-2C6E-11D6-8008-AA0004009E2A >p >Any ideas?  >Pat >    ------------------------------  % Date: Fri, 01 Mar 2002 09:52:00 +1300 # From: Bruce Hoult <bruce@hoult.org>e& Subject: Re: expensive procedure calls> Message-ID: <bruce-05C65E.09520001032002@news.paradise.net.nz>  A In article <vpgs7ucdmqjoq7j1a2ga4724f4ii5hkj73@4ax.com>, Alberto n( Moreira <junkmail@moreira.mv.com> wrote:  6 > Terje Mathisen <terje.mathisen@hda.hydro.com>  said: >  > >Alberto Moreira wrote: I > >> Also, the semantics of your programming language must be amenable to>H > >> tail-form conversion. If the semantics of the language demands thatK > >> you keep multiply nested stack frames with linkages to both staticallydK > >> and dynamically nested contexts, like Pascal for example, I'm not eveneJ > >> sure conversion to tail form is feasible. You may also get in trouble > > J > >There's absolutely nothing that stops a Pascal compiler from generatingI > >C-style code as long as the source code doesn't use any variables frome > >linked contexts, right? > C > If a Pascal program is written to stay within the limits of the C : > semantics, sure, no problem. But try, for example, this: > $ > PROCEDURE ReadOneWord ( ........ ) >  > 	VAR c : char ;s >  > 	PROCEDURE GetFirstNonBlank- >  > 	  PROCEDURE IsItBlank >                     BEGINM >                       ...... >                     ENDh > 
 > 	  BEGIN# > 		if (ItsBlank) GetFirstNonBlank;d > 		c =  ........, > 	  END > 
 >   BEGIN	 > 	GetFirstNonBlank ( )o	 > 		.....a >   END0 >  > END# > E > And you're already doing things that C doesn't do; all of a sudden,RA > the semantics of that maligned ENTER/LEAVE instructions becomesL > relevant !  1 I guess you didn't read the previous messages :-)L   You compile it like this:t     void ReadOneWord(...){     char c;n     GetFirstNonBlank(c);     ...    }-  !   void GetFirstNonBlank(char &c){h*     if (IsItBlank(c)) GetFirstNonBlank(c);     c = ...;   }@     bool IsItBlank(char &c){     ...    }     H Each uplevel variable used is passed as a reference.  If there are "too F many" of them then pass them all in a struct instead of as individual 
 arguments.    E If you really want I can show the actual input and output of a Dylan s compiler doing exactly this.   -- Bruce   ------------------------------    Date: 28 Feb 2002 22:16:57 -0500P From: "Stefan Monnier <foo@acm.com>" <monnier+comp.arch/news/@flint.cs.yale.edu>& Subject: Re: expensive procedure calls, Message-ID: <5lsn7lkmdy.fsf@rum.cs.yale.edu>  D >>>>> "Alberto" == Alberto Moreira <junkmail@moreira.mv.com> writes:A > I'm curious to see Tail Form conversion generally applied to OO-C > languages. It's been a few years I stopped reading papers in thatrG > area, so I'm not familiar with the latest developments. But I look athG > my C++ programs, and I don't know, I somehow doubt that anybody could - > effectively convert them to tail form ! :-)e  D The difference between SSA-form and continuation-passing-style (i.e.C using tail-calls only) is mostly limited to notational differences,LD so it's quite likely that your C++ compiler turns your programs into, something that looks a lot like "Tail Form".     	Stefane   ------------------------------  # Date: Thu, 28 Feb 2002 21:41:46 GMT-# From: "John Smith" <a@nonymous.com>59 Subject: FYI - PHP holes leave Web servers open to attack>. Message-ID: <uuxf8.754$635.293@news1.bloor.is>  . http://www.nwfusion.com/news/2002/0228php.html   http://www.cert.org/   for details and suggestionss   ------------------------------    Date: 28 Feb 2002 19:22:27 -0800" From: VMSfan@hotmail.com (VMS Fan)@ Subject: HP & Compaq high-end systems to "stay around for years"= Message-ID: <d0a53e6e.0202281922.1d206c5e@posting.google.com>d  C I've been watching the pre-merger-vote news for any clues as to thet? fate of VMS if HP succeeds in its takeover bid for Compaq.  TheEC integration team is playing their cards pretty close to the chest. dC Here's the first hint I've seen about potential plans for VMS.  See J http://www.crn.com/Sections/BreakingNews/dailyarchives.asp?ArticleID=33615  C 'Duane Zitzner, president of HP's Computing Systems group, said hisnC group has likewise formulated detailed post-merger plans. DecisionsoE have already been made on product road maps and customer transitions.oA He promised that a detailed playbook for field management will beuA available within several weeks of the merger if it is approved byl
 shareholders.r  F In an interview with CRN after his presentation, Zitzner said that theD company will continue to make both Compaq and HP high-end enterpriseF systems that are already in customer use available for some time. "The4 big equipment will stay around for years," he said.' ---3- "Rumors of my death are greatly exacerbated."n!                            -- VMS    ------------------------------  % Date: Fri, 01 Mar 2002 00:05:22 -0500 - From: JF Mezei <jfmezei.spamnot@videotron.ca>sD Subject: Re: HP & Compaq high-end systems to "stay around for years", Message-ID: <3C7F0C11.C8103E84@videotron.ca>   VMS Fan wrote:H > In an interview with CRN after his presentation, Zitzner said that theF > company will continue to make both Compaq and HP high-end enterpriseH > systems that are already in customer use available for some time. "The6 > big equipment will stay around for years," he said.'  K But Carly only mentioned Tandem surviving and Tru64 users being migrated to  HP-UX. VMS not mentioned.a  J Also just like MPE support will remain for years, old VMS stuff will too. K They may stop releasing new versions of VMS for VAX ASAP, and ALPHA a whileeM later but existing customers will continue to get support. So even in a worsemL case scenario, VMS would stay around for years even if the port to IA64 gets- cancelled. (please note liberal use of "if").a  N Note that "already in customer use" could be interpreted: "if you already haveH VMS, we'll continue to support you, but we won't sell VMS to new sites".  M In other words, one can interpret the above statement any which way you want,Z hence it is rather meaningless.o   ------------------------------  # Date: Thu, 28 Feb 2002 19:36:17 GMTn# From: "John Smith" <a@nonymous.com>h? Subject: Re: HP Sees Charges Up To $1.4 bln After Compaq Mergera. Message-ID: <REvf8.676$635.439@news1.bloor.is>   Bill,a    L They'd probably pull an Enron/Anderson to make the year-end figures come out 'as forecast'.  J When you are running a company as big as HP, and this applies to any largeD company, there is considerable latitude in how management classifiesI expenditures, ie. SG&A vs. merger-specific costs, allowances for doubtfulkL accounts that can be recaptured the following year, telecommunications costs@ attributed to continuing operations vs. discontinued operations,J terminations that are deemed to not be part of the merger, etc.... and theG buckets into which these get dumped are often pretty big, so a bunch ofl4 'small' items that total $50MM might not be noticed.  L Auditors do not examine every single scrap of paper or contract. They merelyC conduct 'tests', sometimes at random, and sometimes on the boxes of>J pre-prepared material that management hands them to conduct their 'random'	 tests on.n    Seen it done all too many times.    5 "Bill Todd" <billtodd@metrocast.net> wrote in message = news:Rouf8.231321$d34.17177038@bin8.nnrp.aus1.giganews.com...c >n8 > "Jerry Leslie" <leslie@clio.rice.edu> wrote in message# > news:a5ld55$2r3$2@joe.rice.edu...uB > >     http://www.siliconvalley.com/mld/siliconvalley/2756636.htm# > >     Mercury News | 02/27/2002 |d: > >     HP sees charges up to $1.4 bln after Compaq merger > > 8 > > --Jerry Leslie     (my opinions are strictly my own) >YI > Note also the rosy assumptions about Compaq's performance in the coming ? > year.  I think I'll address that separately in a few minutes.n >  > - bill >r >m >a   ------------------------------  # Date: Thu, 28 Feb 2002 23:21:02 GMTe) From: rob.buxton@wcc.govt.nz (Rob Buxton)e5 Subject: Re: HSD30 licensing with mirroring and Cache>1 Message-ID: <3c7ebacd.868730959@news.wcc.govt.nz>   @ You may be able to get round this by setting Cache Policy on theC Controller. Read the docs though as data could be lost if there's a  power fail.f( I think this option is available on HSDs  F On 28 Feb 2002 04:21:54 -0800, adrian_ogden@hotmail.com (Scumbag Adie) wrote:   >Hi, >MF >I thought one could do mirroring with a Cache module (no battery) andB >just the mirroring license. But in practice it seems to object if@ >there is no battery present.  Is this true, as according to theB >options catalogue you only get a battery if you purchase the WBCA >option (license and battery)? >t >I	 >Ta mucho  >  >Adiee   ------------------------------  # Date: Fri, 01 Mar 2002 01:53:48 GMT 1 From: "David J. Dachtera" <djesys.nospam@fsi.net>V( Subject: Re: I: PAKGEN Software for ISVs' Message-ID: <3C7EE086.5D339CF8@fsi.net>n   Wayne Sewell wrote:w > ] > In article <3C7DA1D7.B9A63756@fsi.net>, "David J. Dachtera" <djesys.nospam@fsi.net> writes:n > > Wayne Sewell wrote:. > >> >  > [stuff deleted]  >  > >>R > >> I agree.  Admittedly, it should have always been this way, but at least it isS > >> finally fixed.  Maybe we will actually start using LMF for our products, afternR > >> all these years, instead of our own key format.  I'm sure the system managers0 > >> at our customer sites will appreciate that. > > L > > I've worked in shops where non-LMF software (other license methods) were
 > > verboten.  > >o > Q > Really?  What's the reasoning on that?  Too much trouble dealing with alternateeK > key formats?  In our case, it's just a text file residing in a particularsN > product directory.  The information is just as easy to enter as that of LMF.L > In fact, there are far fewer fields to enter.   In most cases, the key canH > simply be extracted from a mail message sent by SP32 customer support. > H > Now if you are talking about tying the key to the hardware as has beenO > discussed many times in the past, bound to the cpu id or the ethernet addressoQ > or whatever, I can understand the objection to that.  I think nearly all of theoO > vms vendors have learned not to do that, due to the public outcry.   Software K > Partners never made that mistake, at least not in the ten years I've been  > involved with them.e > M > Would these sites of yours still ban alternate key systems if they were not E > hardware based, just a different key format and checksum algorithm?r > O > I have not heard of sales lost simply because of the lack of LMF keys, thoughnP > of course it could have happened.  If we had been losing a lot of business forP > that reason, I assume management would have been forced to bite the bullet and: > pay the (formerly) huge price for the LMF key generator.   Say, "Disaster Recovery".s   -- o David J. Dachteran dba DJE Systemsl http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/    ------------------------------  % Date: Thu, 28 Feb 2002 17:16:52 -0500 ( From: David Froble <davef@tsoft-inc.com> Subject: Re: Itanium troublesu, Message-ID: <3C7EAC54.9070909@tsoft-inc.com>   JF Mezei wrote:i   > Tony Scandora wrote: > N >>HP/UX has a viable hardware platform until the next one is ready, as do VMS,K >>Tru64, and NSK, and AIX has a long term viable platform.  I can't imagine2M >>why a new customer would want a vendor-specific non-Windows system from SGI 	 >>or NEC.a >> > O > Why would someone buy SGI ? becayuse the software they need only runs on SGI.sO > That is why. If the few software makers that make SGI-only software decide tohL > switch to a different platform (lets say IBM-POWER), then SGI will be dead
 > quite soon.-    I There's a big difference between 'switch platforms' and 'support another lN platform'.  Even if some or all ISVs port their products to another platform, O that in no way stops the software from running on (in this case) SGI hardware. eP If the SGI solution remains a good solution, then there would not be any reason Q for people to choose the new platform.  Dropping support for SGI wouldn't be the >P best move by the ISV.  This would cause customers to have some bargaining power H with SGI on price, and cause the ISV to maintain their software on more Q platforms.  In some (or all) cases there is a reason the software was originally  M developed for the SGI platform, and as long as SGI doesn't negate this/these   reason(s) they are still valid.   3 You're being way too simplistic, with too much FUD.     M > Why would software developpers switch platform from SGI to something else ? H > Because they are not certain that SGI will be able to keep up and if aO > competitor arises on a different platform that is better performing at betterL2 > price, then that software company is also toast.    ( That's  not something new.  That's life.    L > Uncertainty about a platform (hardware and OS) are deadly. SGI isn't awareP > that one of its major software developpers is contemplating a platform switch,M > and it won't know for quite some time until that company publicly announces@I > its product has been ported to platform X. By that time it is too late.c    T See above.  A port will not automatically make the non-SGI choice the better choice.    2 > I leave you the task of translating this to VMS.  P VMS products ported to other platforms do not always make for a better solution.N People buy solutions. Now, if you're going to bring the spriot of Palmer back,B and badmouth the VMS version of the product, that's another issue.     Dave   -- e4 David Froble                       Tel: 724-529-04504 Dave Froble Enterprises, Inc.      Fax: 724-529-0596> DFE Ultralights, Inc.              E-Mail: davef@tsoft-inc.com6 T-Soft, Inc.  170 Grimplin Road  Vanderbilt, PA  15486   ------------------------------  % Date: Fri, 01 Mar 2002 06:00:21 +0100i* From: Alexis Cousein <al@brussels.sgi.com> Subject: Re: Itanium troublesn/ Message-ID: <3C7F0AE5.6090309@brussels.sgi.com>o   JF Mezei wrote:nO > Why would someone buy SGI ? becayuse the software they need only runs on SGI.o  D The vast majority of *new* customers for SGI servers (last I looked,E 50%+ of revenue) are running applications that run on other platformst) too, so that can't be the only reason ;).p -- g? <these messages express my own views, not those of my employer>c) Alexis Cousein				Senior Systems Engineers. SGI Belgium and Luxemburg		al@brussels.sgi.com   ------------------------------  % Date: Thu, 28 Feb 2002 11:31:26 -0800u, From: "James Gessling" <jgessling@yahoo.com>L Subject: Lock queues, how can granted queue be emply if waiting queue is not4 Message-ID: <a5m0if$8lj8u$1@ID-46415.news.dfncis.de>  E We had some real lock weirdness yesterday and I'm wondering if anyone-E can help.  We have seen in the past cases where a process gets a lockmF on an RMS bucket in a file at EX mode and doesn't release it.  In thatH case other processes trying for that bucket get their lock request stuckG in the waiting queue.  By finding the process that has the lock grantednJ and killing it everything frees up and processing continues.  No big deal.  J Yesterday we had a lock with lots of requests in the conversion queue, butL nothing in the granted queue. So there wasn't any obvious process to kill toL get things moving.  Eventually we had to crash one of the cluster nodes, andK that cleared things up. (not a good thing).  My question is how can nothingoJ be in the granted queue if entries are in the conversion queue?  Shouldn't' those granted?  Here's a shot from sda,E   Resource Database0 -----------------3= RSB:         FFFFFFFF.70125050  GGMODE:     NL  Status: VALID0. Parent RSB:  FFFFFFFF.6DCA6250  CGMODE:     NL. Sub-RSB count:      0           FGMODE:     NL. Lock Count:        11           RQSEQNM:  00488 BLKAST count:       0           CSID: 00010051  (ETAB57)  I Resource:          00000000 0008E9CB  ......  Valblk: 00000000 00000000.I  Length    4       00000000 00000000  ........          00000000 00000000 .  Exec. mode        00000000 00000000  ........@  System            00000000 00000000  ........  Seqnum: 00000000  * Granted queue (Lock ID / Gr mode / Range):      *** EMPTY QUEUE ***  @ Conversion queue (Lock ID / Gr mode / Range -> Rq mode / Range):6  6B07F6D8  NL 00000000-FFFFFFFF / PW 00000000-FFFFFFFF6  71031BE3  NL 00000000-FFFFFFFF / PW 00000000-FFFFFFFF6  5F02EB47  NL 00000000-FFFFFFFF / PW 00000000-FFFFFFFF6  54103713  NL 00000000-FFFFFFFF / PW 00000000-FFFFFFFF  D This seems really weird.  But looking around another system, I foundE that empty granted queues were not unusual.  I added another sda shotd0 after this.  I'm confused, please help.  Thanks.   Resource Databases -----------------g= RSB:         FFFFFFFF.6B432650  GGMODE:     NL  Status: VALIDh. Parent RSB:  00000000.00000000  CGMODE:     NL. Sub-RSB count:      0           FGMODE:     NL. Lock Count:         1           RQSEQNM:  001E8 BLKAST count:       0           CSID: 0001004E  (ETAB50)  I Resource:          32303032 41534424  $DSA2002  Valblk: 00000000 00000000 I  Length   16       52484354 4157245F  _$WATCHR          00000000 00000000 .  Kernel mode       00000000 00000000  ........@  System            00000000 00000000  ........  Seqnum: 00000000  * Granted queue (Lock ID / Gr mode / Range):      *** EMPTY QUEUE ***  @ Conversion queue (Lock ID / Gr mode / Range -> Rq mode / Range):      *** EMPTY QUEUE ***  * Waiting queue (Lock ID / Rq mode / Range):  01000013  EX 00000000-FFFFFFFFI   ------------------------------    Date: 28 Feb 2002 13:36:22 -08001 From: keithparris_NOSPAM@yahoo.com (Keith Parris)fP Subject: Re: Lock queues, how can granted queue be emply if waiting queue is not= Message-ID: <cf15391e.0202281336.5a145f62@posting.google.com>n  h "James Gessling" <jgessling@yahoo.com> wrote in message news:<a5m0if$8lj8u$1@ID-46415.news.dfncis.de>...  > My question is how can nothingL > be in the granted queue if entries are in the conversion queue?  Shouldn't, > those be granted?  Here's a shot from sda, ...c: > BLKAST count:       0           CSID: 00010051  (ETAB57) ...n, > Granted queue (Lock ID / Gr mode / Range): >      *** EMPTY QUEUE ***  C The lock master node for this resource tree is ETAB57 (if this nodevD were the lock master, the CSID field would be zero).  If you ran SDA; on node ETAB57, you'd most likely see a granted lock there.   C Wouldn't the DECamds lock-contention screen be a much easier way tou track this sort of thing down?? ---------------------------------------------------------------e? Keith Parris | parris at encompasserve dot org | Consulting on:"> Clusters, Disaster Tolerance, Performance, I/O, Storage & SANs   ------------------------------  % Date: Thu, 28 Feb 2002 19:21:30 -0500   From: John Santos <JOHN@egh.com>4 Subject: Re: Microsoft Curries Favor With Undergrads5 Message-ID: <1020228191112.9016D-100000@Ives.egh.com>.  # On 28 Feb 2002, Jerry Leslie wrote:g  A > $ 99 for each student and only $799/year for each university...m > . >    http://news.com.com/2100-1001-847298.htmlC >    Microsoft curries favor with undergrads - Tech News - CNET.comm > , >    Microsoft curries favor with undergrads >    By Wylie Wong  >    Staff Writer, CNET News.com" >    February 28, 2002, 4:45 AM PT > H >   "Microsoft hopes to win over software developers while they're still >    young.o > G >    Microsoft on Thursday released software development tools aimed at-F >    college-level computer science students, hoping it will produce aE >    fresh crop of software programmers loyal to its Windows and .Net  >    technology. > J >    The software maker has shipped a version of its new Visual Studio.NetK >    tools with specific features for educational use. Visual Studio.Net is-J >    the latest version of Microsoft's development tools that allow peopleI >    to write Web-based software and services. As part of its overarchingoJ >    .Net software strategy, the company earlier this month released three9 >    versions of the tools aimed at the corporate market.s > D >    Michael Bronsdon, Microsoft's lead product manager for academicI >    developer marketing, said win over software developers while they'reeH >    still young, which competes against Sun Microsystems, IBM and otherJ >    Java supporters for talent, is offering its tools at a heavy discountH >    to students and schools in hopes of enticing more people to use its >    technology. > J >    "We are doing an awful lot to get the next wave of developers workingI >    with Web services and understanding and working with .Net, and we'ref5 >    focused quite a bit on academia," Bronsdon said.s > I >    Visual Studio.Net Academic includes Web-based software that providesNC >    an online area where faculty and students can communicate. For I >    example, professors could put class assignments for students online. J >    The class, in turn, could download the assignments, complete them and& >    upload them to Web-based servers. > I >    The product also includes several wizards, which makes it easier for-J >    programmers to write software by guiding them through the development
 >    process.. > D >    The cost of the Visual Studio.Net Academic for students is $99,I >    Bronsdon said. Universities can gain access to the Visual Studio.Net F >    tools and install it in their computer labs through a $799 yearly1 >    subscription with Microsoft's MSDN Web site.a > G >    Visual Studio.Net includes updates to programming languages VisuallC >    Basic, Visual C++, as well as the first version of Microsoft's"$ >    Java-like language called C#. " >  > 6 > --Jerry Leslie     (my opinions are strictly my own)  > This sounds like a wonderful opertunity for the truly creative? student.  He/She/It could change the class assignments to matchsA their anwsers retroactively, upload new assignments after readingeC other student's work, change other students' assignments after theyV5 had turned them in, "correct" their grades, etc. etc.   A All the while achieving great proficiency with MicroSoft securityr	 issues...t  = P.s.  I realize this is a subtle dig at DEC/Compaq's droppingc4 the ball on academic VMS over the last decade or so.   --   John Santosr Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Thu, 28 Feb 2002 23:06:05 -0500-* From: "Stanley F. Quayle" <stan@stanq.com>6 Subject: Re: Need help on Alpha:  Calling C from MACRO. Message-ID: <3C7EB7DD.3954.100321A2@localhost>  E Thanks for your suggestions.  It turns out that VAXman's analysis of pE stepping through the argument list was correct -- Alpha uses 8 bytes a per argument, while VAX uses 4.i  D I was able to recode two of my client's source modules to avoid the F use of "va_start_1" altogether.  That will work on both VAX and Alpha.  D Two more modules got conditionalization, with 4 bytes for VAX and 8  for Alpha (yuck!).  0 In looking in the "varargs.h" header file (from F SYS$LIBRARY:DECC$RTLDEF.TLB), the "va_start" macro expects everything  to be 8 bytes on Alpha:e  C #define va_arg(ap, type) (ap = (__va_list) ((char *) ap + ((sizeof e (type) + 7) & ~7)), \ 7 (* (type *)((char *) ap - ((sizeof (type) + 7) & ~7))))b  B But no special treatment is given to macro "va_start_1".  And the E Compaq C manuals don't even mention it, must less give VAX vs. Alpha e	 guidance.x  E Perhaps some of this needs to go into the programming section of the  D FAQ.  If anyone agrees, I'll be glad to write something up and send  it to Hoff.@    
 --Stan Quaylee! President, Quayle Consulting Inc..  
 ----------G Stanley F. Quayle, P.E.   N8SQ   +1 614-868-1363   Fax: +1 614 868-1671r1 8572 North Spring Ct. NW, Pickerington, OH  43147u= Preferred address:  stan@stanq.com       http://www.stanq.com6   ------------------------------    Date: 28 Feb 2002 19:32:53 -0800  From: cherephon@yahoo.com (Mart)" Subject: proliant 1600 not booting= Message-ID: <e86bb13d.0202281932.3c0f6ded@posting.google.com>s  E I have a compaq proliant 1600 and when the server powers up but, gets D to the bios, then quits when it goes to recognize the PIII, it says,( "Unsupported Processor detected. Systems6 halted". From then nothing happen, I can`t do anything  < I need to boot the system, any help would be appreciated....   ------------------------------  % Date: Thu, 28 Feb 2002 22:46:21 -0000o- From: wspencer@ap.nospam.org (Warren Spencer) O Subject: Re: Q: Why is XP-1000 RAM so expensive from Compaq vis-a-vis Kingston?f7 Message-ID: <91C3BD837warrenspencer1977@209.249.90.100>0  0 pdafniotis@yahoo.com (Petros Dafniotis) wrote in3 <e54adf36.0202280714.46145e1c@posting.google.com>: i  C >In another post I asked for XP-1000 ram. I need 4 modules of 256MBs >each. >r >This is listed as:j< >Compaq reference numbers are:     SN-MSP01-KD or 388262-B21 >This is from:I >http://www.compaq.com/alphaserver/options/xp1000/xp1000_sn-msp01-kd.htmlc >eF >Compaq Switzerland quoted this as 10,000 CHF; Compaq USA as 6,300 USD >so almost the same. > E >Now I go to Kingston which I thought was rather reputable and I see:tJ >http://www.ec.kingston.com/ecom/kepler/PartsInfo_Bod.asp?ktcpartno=KTC-XP' >1000/1024 which retails for US$ 729!!!  >aE >This is a HUGE difference! Can I please get an explanation? I do notfE >mind at all paying twice or three times as much iff the RAM is going A >to be more reliable but the price factor of ~9 is just enormous.h >w >Kind regards, >Petros  >--- >Petros Dafniotis, PhD >pdafniotis@yahoo.com  >   I RAM price differential has been a curiosity for years.  On most machines .L I've managed, I've used Kingston to augment what RAM came with the system.  I Clearly Compaq cannot support 3rd-party RAM, so a CPQ support technician tK might ask you to remove it temporarily if you have a hard-to-find hardware ?E failure.  However iff the system in question has extreme reliability ,L requirements, you may wish to use the more expensive RAM to avoid potential ) conflicts with you CPQ support agreement.o   ws   -- f   Warren Spencer' Senior Software Engineer (not a writer)t The Associated Press  < ** Time flies like an arrow.  Fruit flies like a bananna. **   ------------------------------    Date: 28 Feb 2002 18:11:48 -0800) From: P.Young@unsw.EDU.AU (Patrick Young) O Subject: Re: Q: Why is XP-1000 RAM so expensive from Compaq vis-a-vis Kingston? = Message-ID: <55f85d77.0202281811.7fbb57cb@posting.google.com>a  l wspencer@ap.nospam.org (Warren Spencer) wrote in message news:<91C3BD837warrenspencer1977@209.249.90.100>...  iK > RAM price differential has been a curiosity for years.  On most machines fN > I've managed, I've used Kingston to augment what RAM came with the system.  K > Clearly Compaq cannot support 3rd-party RAM, so a CPQ support technician aM > might ask you to remove it temporarily if you have a hard-to-find hardware h  F I'm using Kingston on two XP1000 systems - One OpenVMS the other Tru64G with no problems. The machines were ordered with minimal (128Mb) Compaq @ memory. I did find to make the two co-exist I had to stagger the9 Kingston memory every second slot with the Compaq memory.m  G It is not only the memory prices that are a killer - also storage. WithpG the exception of one RA3000 all our storage I've assembled myself usinghA Seagate 50Gb drives and generic 8 disk enclosures/RAID canisters..  D In our environment I don't have much of a choice. If I had to go forE Compaq everything management would take one look at the price and sayaF "OK, _YOU_ are now going to dump OpenVMS and Tru64 and _YOU_ are going7 to have to make it work using PCs and Window or Linux".    ------------------------------  # Date: Fri, 01 Mar 2002 02:33:04 GMTi1 From: "David J. Dachtera" <djesys.nospam@fsi.net>oO Subject: Re: Q: Why is XP-1000 RAM so expensive from Compaq vis-a-vis Kingston?i' Message-ID: <3C7EE9B8.170B7A2F@fsi.net>k   Patrick Young wrote: > [snip]I > It is not only the memory prices that are a killer - also storage. With I > the exception of one RA3000 all our storage I've assembled myself using C > Seagate 50Gb drives and generic 8 disk enclosures/RAID canisters.r > F > In our environment I don't have much of a choice. If I had to go forG > Compaq everything management would take one look at the price and saylH > "OK, _YOU_ are now going to dump OpenVMS and Tru64 and _YOU_ are going9 > to have to make it work using PCs and Window or Linux".m  1 There's that "Affordable" thing again! *DAMN*!!!!o   -- a David J. DachteraS dba DJE Systemsc http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/n   ------------------------------    Date: 28 Feb 2002 13:14:06 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)nW Subject: Re: Question on a Deskpro EP`s motherbaord and possibily of changing it out :) 3 Message-ID: <nOu5qDbk8DEL@eisner.encompasserve.org>G  i In article <edb829c0.0202281058.69b32e4c@posting.google.com>, cpw531@hotmail.com (Clark Williams) writes:r< > I have a Compaq Deskpro EP BX/P500 , System Serial Number: > 6941CJN4L090.t  7 That hardware really is not a topic for this newsgroup.o   ------------------------------  # Date: Thu, 28 Feb 2002 19:28:31 GMTa# From: "John Smith" <a@nonymous.com> W Subject: Re: Question on a Deskpro EP`s motherbaord and possibily of changing it out :)w. Message-ID: <zxvf8.923$K4l.749@news2.bloor.is>  & Try alt.sys.pc-clone.compaq for advice    6 "Clark Williams" <cpw531@hotmail.com> wrote in message7 news:edb829c0.0202281058.69b32e4c@posting.google.com...I< > I have a Compaq Deskpro EP BX/P500 , System Serial Number:F > 6941CJN4L090. I have basically explored very nook and cranny of thisH > system, and I have a question about the motherboard. I have opened theA > case and noticed the motherboard looks like a standard ATX formnH > factor, so the question is, for flexibility in the future, does anyoneE > know if I can take out this older compaq motherboard (Compaq 041Ch) F > and replace with a more modern standard atx motherboard??? I have toF > admit I like the Deskpro chassis and I enjoy tinkering, but, being aH > novice and somewhat inexperienced with ATX ( I have always worked withH > AT ),I was wondering if the actual motherboard mounting of the chassisH > are standard or proprietary. THe fact is that I don`t have another ATXD > motherbaord to visually compare the mountings, and second I reallyA > don`t want to take apart this system just for the prime fact oftF > exploration  ( its my home business PC ). I thank anyone who has any > info on this.s >h > cordially, >nG >                                                                 Clarkm
 > Williams >l >sF > Just as a sidenote, my other system is an older custom system with aE > Tyan Trinity 100 AT (S1590) motherboard and other components, and i2D > can`t keep its case on because I am always experimenting with it (8 > meaning also that it likes to get unstable alot more).   ------------------------------    Date: 28 Feb 2002 14:19:50 -0800) From: cpw531@hotmail.com (Clark Williams)nW Subject: Re: Question on a Deskpro EP`s motherbaord and possibily of changing it out :)s= Message-ID: <edb829c0.0202281419.781d4310@posting.google.com>e  @ Very true, this was the wrong forum for me to post my message. I7 sincerely apologize, and thankyou for the instructions.   >                                                     cordially,  E                                                                 Clarkc W.   ------------------------------  % Date: Thu, 28 Feb 2002 19:01:36 -0500e  From: John Santos <JOHN@egh.com>( Subject: Re: restricting access to ports5 Message-ID: <1020228182333.9016C-100000@Ives.egh.com>h  * On Thu, 28 Feb 2002, Phillip Helbig wrote:  N > > But you do this for the defined services. For instance, for SMTP (port 25)9 > > you'd do the SET SERVICE SMTP/ACCEPT=NETWORK=10.0.0.0s > > D > > (you can specify the network mask, but am unsure of the syntax). > > R > > With such a command, the SMTP would only accept incoming calls from your local- > > LAN network and nothing from the outside.C > A > Right, but I WANT things from the outside, just not EVERYTHING.  > D > On the other hand, everything comes through the ISDN router which 6 > connects the local LAN to the ISP over an ISDN line. > Q > > Note that if you don't have a service defined for a port, VMS will refuse the0K > > call. The dangerous portion though is for services that are dynamically K > > declared (for instance, the OSU web server delcares port 80 by itself).v > I > That's not a problem in itself; I want to avoid unwanted requests from 0G > reaching my VMS machine at all, so that I don't have to pay for them.W > L > > > Note that I am not mainly trying to block initial incoming access to aI > > > given port, but rather keep VMS itself from "randomly" allocating a.L > > > given port for return traffic associated with an outgoing connection I > > > initiated myself.h > > * > > Why are you trying to restrict those ? > M > If I can restrict them to, say, ports 49125--49155 (or however many I need 6G > simultaneously), then I can tell the ISP to block incoming access to EG > everything except these (which are listening for return traffic from  K > connections I initiated), ports less than 1024 which I actually use, and EI > special cases like 8000, 8080 for HTTP or whatever.  That way, if some 0I > joker tries to access a random port as part of a port-scan strategy or 0K > whatever, or a virus going for a certain port, it will be blocked at the  % > ISP and I don't have to pay for it.   F This shouldn't be necessary.  When the ISP blocks incoming connectionsD on all ports except some very limited subset that you have chosen toF allow, they are not filtering out *ALL* packets to those ports on yourE system, only those that have (or don't have) a certain bit set in the-B packet header that says "this is a new connect request".  When youE initiate a connection to a specific port on a remote host, the TCP/IPeD stack assigns you a random available port number for your end of theE connection.  (The port number is how it keeps track of connections soeC it knows which application, i.e. which BG: or TCP: device gets thise@ particular packet.)  The ISP should *NOT* be filtering out theseG packets on the established connections, only the packets for externallyf initiated new connections.  F So sending from a random port to a remote SMTP server (and getting itsF responses) or reading mail from a remote POP3 server should work fine.  @ The only common exception to this is FTP.  Standard FTP uses oneF connection for control messages.  The client uses a random port number? and initiates a connection to port 21 (IIRC) on the FTP server.mC However, data transfers occur over a second connection.  The clientfB allocates a port number (randomly assigned by the IP stack), tellsA the server what the port number is, and then listens on that porttB for the server to initiate a connection.  Smart filters know about> the FTP protocol and allow the incoming data connection to getB created (i.e. temporarily allow incoming port X from host W.X.Y.Z)@ Most filters or firewalls aren't that smart, (and this is really@ ugly), so the solution is to use PASSIVE mode.  In PASSIVE mode,@ the client and server exchange info about what ports to use overD the control connection, and then the client initiates the connectionD to the server.  Since it is a client-initiated connection, it works.B Most (all?) web browsers use passive-mode by default, so they work@ through such filters when doing downloads (i.e. ftp://... URL's)  > The problems arise if the SERVER is behind such a filter.  TheB filter allows in port 20, so the control connection is no problem.@ The standard-mode data connection is initiated by the server, so; the filter also allows it.  However a PASSIVE connection isr> initiated by the client, to an unknown (to the filter) port on, the server, so data connections are blocked.  ? If both the client and the server are behind such filters, then < neither PASSIVE nor standard (ACTIVE?) mode will work.  Ugh!  @ As far as totally restricting all but a small set of ports, this? would only work if you can tell your TCP/IP stack to only issue ? ports in that range.  I don't think you can do that with eithers> TCPWare (which I use a lot) or UCX/Compaq TCP/IP, which I have@ on a couple of systems, but am much less familiar with.  I think< the port number is a 16 bit number, low numbers are reserved= for standard servers, and higher numbers (starting at 4096 ora< something like that) are sequentially assigned to new ports.4 When it gets to 65535, it starts over again at 4096.? It is (or should be - I don't know if I've ever encountered theeA situation, but once your VMS system has been up for a few months,t? it should be no problem hitting it...) smart enough to skip thed; ports that are still in use.  There are probably "min port"i9 and "max port" constants somewhere in NETCP (TCPWARE), ord< TCPIP$INETACP (TCP/IP) or INETD (standard Unix name for this< process, IIRC), that could be patched to restrict the range,. but I don't think there is much call for this.   > D > I have no problem with the accesses hitting the machine; VMS just I > refuses.  The problem is that I have to pay for incoming access (if it  D > initiates a new connection; connections time out after 2 minutes).  A I don't know if the filter at your ISP tracks connections.  (MosteC true firewalls do this.)  If not, a malicious person could do a DOSNC attack on your system by sending packets that looked like responsesnC to non-existent connections.  The ISP would start up your ISDN linetC and charge you for the packet.  Your TCP/IP stack would discard theoA packet, probably setting off various alarms, but the damage would  already be done.  = Anyone who did this would of course be violating the terms ofi< service of their ISP and would have their account terminated? immediately.  (If the ISP didn't ban this, then every other ISPs? in the world would cut them off, and put them out of business.)n" But that doesn't do you much good.   > J > > I have an ISDN router between me and the ISP (in fact, that is how theI > > connection is made), but I have to pay for things which get as far ase= > > the router, which is why I want to block them at the ISP.l > L > > Ok, with ISDN I can understand why. A call request to your port 80 wouldJ > > force the ISDN link to be established from the ISP to you only to haveG > > your host reject it, and the ISDN router keep the line active for Xi' > > time, during which you are billed.   > 
 > Exactly. > M > > Do they have DSL or CABLE internet where you live ? Those are usually not ? > > measured for connect time so that would solve your problem.m > E > Yes, but my last information from the ISP is that he can offer the uK > service I need (dial-in-on demand access, static IP addresses) only over g > ISDN.t > G > Actually, the ISDN connection is not as bad as it seems and if I get aK > things working right, it would be cheaper than DSL etc (I don't need the sI > DSL bandwidth) and would also allow me to do things like dial in to my l
 > own router.n > J > I have a telephone-billing arrangement which doesn't charge for outgoingC > calls on Sundays and holidays, so then I initiate a connection at_G > midnight and keep it alive.  I allow robots in only on Sundays, so myaE > web pages get accessed by robots---which I want---but only when the B > connection is free.  Legitimate and/or non-robot access is not aH > problem.  Someone once said that "intelligent" robots will black-list D > pages and not index them if it is not always accessible, but this K > doesn't seem to be the case---I get the same bots as always, but only on tJ > Sundays.  As long as I do big downloads etc myself only on Sundays, the I > connection time and thus the costs are not that much (volume is not an - > issue in any case).l   HTH      -- + John Santos3 Evans Griffiths & Hart, Inc. 781-861-0670 ext 539   ------------------------------  % Date: Thu, 28 Feb 2002 21:14:00 -0500w1 From: Michael Austin <maustin@firstdbasource.com>a( Subject: Re: restricting access to ports2 Message-ID: <3C7EE3E8.350747C2@firstdbasource.com>  D With this type of configuration, no matter what you do, someone willG attempt to access your system via it's (I'm assuming here...) static IP G address.  The router does not know that if it is wanted or unwanted andsF since you said yourself that if it gets to the router, you are billed.G ISDN in this configuration is a lose-lose situation.  Especially if youe want to have access at all.  -  H You can set up any service on any port you want.  However, if someone isG port-scanning and you have set up access for that port, you are billed.vE Period.  The alternative is that when you want ot  access your system1E provide the ISP with static IP addresses you would be connecting fromn' and only allow access from those ports.o  A Get DSL, Cable-modem or bi-directional DirectPC.  ISDN was a gooddA technology 10 years ago and all the tariff rates should be in the A sub-penny range. (like .00002/min or $50/month) or flat rate like/ everything else in the world.  s -- 0 Regards,  7 Michael Austin            Registered Linux User #261163,7 First DBA Source, Inc.    http://www.firstdbasource.com  Sr. Consultant     John Santos wrote: > , > On Thu, 28 Feb 2002, Phillip Helbig wrote: > P > > > But you do this for the defined services. For instance, for SMTP (port 25); > > > you'd do the SET SERVICE SMTP/ACCEPT=NETWORK=10.0.0.0g > > >xF > > > (you can specify the network mask, but am unsure of the syntax). > > >RT > > > With such a command, the SMTP would only accept incoming calls from your local/ > > > LAN network and nothing from the outside., > > C > > Right, but I WANT things from the outside, just not EVERYTHING.s > >oE > > On the other hand, everything comes through the ISDN router whichn8 > > connects the local LAN to the ISP over an ISDN line. > >rS > > > Note that if you don't have a service defined for a port, VMS will refuse theyM > > > call. The dangerous portion though is for services that are dynamicallysM > > > declared (for instance, the OSU web server delcares port 80 by itself).n > >RJ > > That's not a problem in itself; I want to avoid unwanted requests fromI > > reaching my VMS machine at all, so that I don't have to pay for them.i > >PN > > > > Note that I am not mainly trying to block initial incoming access to aK > > > > given port, but rather keep VMS itself from "randomly" allocating awN > > > > given port for return traffic associated with an outgoing connection I > > > > initiated myself.  > > >-, > > > Why are you trying to restrict those ? > >mN > > If I can restrict them to, say, ports 49125--49155 (or however many I needH > > simultaneously), then I can tell the ISP to block incoming access toH > > everything except these (which are listening for return traffic fromL > > connections I initiated), ports less than 1024 which I actually use, andJ > > special cases like 8000, 8080 for HTTP or whatever.  That way, if someJ > > joker tries to access a random port as part of a port-scan strategy orL > > whatever, or a virus going for a certain port, it will be blocked at the' > > ISP and I don't have to pay for it.m > H > This shouldn't be necessary.  When the ISP blocks incoming connectionsF > on all ports except some very limited subset that you have chosen toH > allow, they are not filtering out *ALL* packets to those ports on yourG > system, only those that have (or don't have) a certain bit set in theiD > packet header that says "this is a new connect request".  When youG > initiate a connection to a specific port on a remote host, the TCP/IPaF > stack assigns you a random available port number for your end of theG > connection.  (The port number is how it keeps track of connections sorE > it knows which application, i.e. which BG: or TCP: device gets this B > particular packet.)  The ISP should *NOT* be filtering out theseI > packets on the established connections, only the packets for externallyC > initiated new connections. > H > So sending from a random port to a remote SMTP server (and getting itsH > responses) or reading mail from a remote POP3 server should work fine. > B > The only common exception to this is FTP.  Standard FTP uses oneH > connection for control messages.  The client uses a random port numberA > and initiates a connection to port 21 (IIRC) on the FTP server.oE > However, data transfers occur over a second connection.  The clientnD > allocates a port number (randomly assigned by the IP stack), tellsC > the server what the port number is, and then listens on that portmD > for the server to initiate a connection.  Smart filters know about@ > the FTP protocol and allow the incoming data connection to getD > created (i.e. temporarily allow incoming port X from host W.X.Y.Z)B > Most filters or firewalls aren't that smart, (and this is reallyB > ugly), so the solution is to use PASSIVE mode.  In PASSIVE mode,B > the client and server exchange info about what ports to use overF > the control connection, and then the client initiates the connectionF > to the server.  Since it is a client-initiated connection, it works.D > Most (all?) web browsers use passive-mode by default, so they workB > through such filters when doing downloads (i.e. ftp://... URL's) > @ > The problems arise if the SERVER is behind such a filter.  TheD > filter allows in port 20, so the control connection is no problem.B > The standard-mode data connection is initiated by the server, so= > the filter also allows it.  However a PASSIVE connection is>@ > initiated by the client, to an unknown (to the filter) port on. > the server, so data connections are blocked. > A > If both the client and the server are behind such filters, thenr> > neither PASSIVE nor standard (ACTIVE?) mode will work.  Ugh! > B > As far as totally restricting all but a small set of ports, thisA > would only work if you can tell your TCP/IP stack to only issuetA > ports in that range.  I don't think you can do that with eithere@ > TCPWare (which I use a lot) or UCX/Compaq TCP/IP, which I haveB > on a couple of systems, but am much less familiar with.  I think> > the port number is a 16 bit number, low numbers are reserved? > for standard servers, and higher numbers (starting at 4096 ori> > something like that) are sequentially assigned to new ports.6 > When it gets to 65535, it starts over again at 4096.A > It is (or should be - I don't know if I've ever encountered theeC > situation, but once your VMS system has been up for a few months,pA > it should be no problem hitting it...) smart enough to skip thet= > ports that are still in use.  There are probably "min port" ; > and "max port" constants somewhere in NETCP (TCPWARE), ors> > TCPIP$INETACP (TCP/IP) or INETD (standard Unix name for this> > process, IIRC), that could be patched to restrict the range,0 > but I don't think there is much call for this. >  > >hE > > I have no problem with the accesses hitting the machine; VMS just J > > refuses.  The problem is that I have to pay for incoming access (if itF > > initiates a new connection; connections time out after 2 minutes). > C > I don't know if the filter at your ISP tracks connections.  (MostlE > true firewalls do this.)  If not, a malicious person could do a DOSaE > attack on your system by sending packets that looked like responses4E > to non-existent connections.  The ISP would start up your ISDN line E > and charge you for the packet.  Your TCP/IP stack would discard the C > packet, probably setting off various alarms, but the damage would  > already be done. > ? > Anyone who did this would of course be violating the terms of > > service of their ISP and would have their account terminatedA > immediately.  (If the ISP didn't ban this, then every other ISPiA > in the world would cut them off, and put them out of business.)h$ > But that doesn't do you much good. >  > >rL > > > I have an ISDN router between me and the ISP (in fact, that is how theK > > > connection is made), but I have to pay for things which get as far as ? > > > the router, which is why I want to block them at the ISP.. > > N > > > Ok, with ISDN I can understand why. A call request to your port 80 wouldL > > > force the ISDN link to be established from the ISP to you only to haveI > > > your host reject it, and the ISDN router keep the line active for Xe( > > > time, during which you are billed. > >  > > Exactly. > >LO > > > Do they have DSL or CABLE internet where you live ? Those are usually noteA > > > measured for connect time so that would solve your problem.t > >hF > > Yes, but my last information from the ISP is that he can offer theL > > service I need (dial-in-on demand access, static IP addresses) only over	 > > ISDN.  > >tH > > Actually, the ISDN connection is not as bad as it seems and if I getL > > things working right, it would be cheaper than DSL etc (I don't need theJ > > DSL bandwidth) and would also allow me to do things like dial in to my > > own router.o > >aL > > I have a telephone-billing arrangement which doesn't charge for outgoingE > > calls on Sundays and holidays, so then I initiate a connection at I > > midnight and keep it alive.  I allow robots in only on Sundays, so my(G > > web pages get accessed by robots---which I want---but only when thelD > > connection is free.  Legitimate and/or non-robot access is not aI > > problem.  Someone once said that "intelligent" robots will black-list0E > > pages and not index them if it is not always accessible, but thisPL > > doesn't seem to be the case---I get the same bots as always, but only onK > > Sundays.  As long as I do big downloads etc myself only on Sundays, thepJ > > connection time and thus the costs are not that much (volume is not an > > issue in any case).r >  > HTHe >  > --
 > John Santose > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539   ------------------------------  $ Date: Fri, 1 Mar 2002 09:17:49 +04004 From: Valentin Likoum <valentin.likoum@ncc.volga.ru>* Subject: Re[2]: decnet phase IV -> phase V4 Message-ID: <1843856634.20020301091749@ncc.volga.ru>  0 On 01.03.2002 John N. <JNixon@cfl.rr.com> wrote:  G > Oh,   I never thought of that!   But outside of a huge multi-nationalrM > corporation with thousands of nodes, what software actually requires PhaseVnH > decnet?  (Except for certain bisynch drivers ,which Compaq is dropping > support for anyway).     X.25   -- o   Valentin Likoumi   valentin.likoum@ncc.volga.ru   ------------------------------  % Date: Thu, 28 Feb 2002 15:44:21 -0500c; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>e$ Subject: Re: Solution for the merger$ Message-ID: <3c7e96f3$1@news.si.com>  ( >Sorry, but aren't we allowed to dream ?  " Sounds more like an hallucination! -- nA Brian Tillman                   Internet: tillman_brian at si.com A Smiths Aerospace                          tillman at swdev.si.como= 3290 Patterson Ave. SE, MS      Addresses modified to preventn< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  # Date: Fri, 01 Mar 2002 02:03:18 GMTr1 From: "David J. Dachtera" <djesys.nospam@fsi.net>n$ Subject: Re: Solution for the merger' Message-ID: <3C7EE2C0.94156BC0@fsi.net>h   Brian Tillman wrote: > * > >Sorry, but aren't we allowed to dream ? > $ > Sounds more like an hallucination!   <music>./ ...and you've just had some kind of mushroom...e </music>     -- r David J. Dachtera  dba DJE Systemsn http://www.djesys.com/  ( Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/t   ------------------------------  # Date: Thu, 28 Feb 2002 21:59:32 GMTt* From: "Bill Todd" <billtodd@metrocast.net> Subject: Timing is everything C Message-ID: <8Lxf8.239707$Re2.18149826@bin6.nnrp.aus1.giganews.com>t  E Unlike some participants in c.o.v., I usually don't much subscribe toaF conspiracy theories - simple incompetence seems so much more likely anK explanation in most cases.  Still, with increasing evidence coming out thatuK Ken Lay has been producing theatrical corporate fiction since the mid-'80s, # it makes even me start to wonder...r  L I observed previously that the HP and Compaq shareholder votes are scheduledJ to occur before Q1 results are made public, and that Compaq's surprisingly; strong 2001Q4 results seem to reflect one-time sales in the L enterprise/high-end-technical/military computing areas that aren't likely toL represent its longer-term performance very well (I don't know any comparableL details that might or might not shed doubt on HP's Q4 numbers).  Now that weE see analyst projections for a strong 2002 year for Compaq (based, onesK suspects, on the Q4 numbers) being used to support the merger, that earlier & observation seems even more pertinent.  @ Then there's McKinley, with its up-again, down-again performanceG projections.  It's looking more and more likely that we won't see solid L SPECint (or any other) numbers before the merger votes - which means we justE won't know how badly both the HP and the Compaq leadership screwed byxI hitching their corporate wagons to this particular falling star, and willoE have to (at least most shareholders may be likely to) just take theirc decision on faith.  K Now, I don't really believe that Intel would significantly delay McKinley'seH introduction just to keep from embarrassing the HP and Compaq leadershipH before their shareholders have to decide on their fate, but I do find itL conceivable that, if McKinley weren't going to appear anyway until about theE vote date, Intel might both tweak its schedule a bit *and* float somenH encouraging 'whisper numbers' to enhance the probability of the merger'sL acceptance:  having a merged entity run by leadership that has already swornJ absolute fealty to Itanic would certainly be preferable to Intel to havingC two important customers undergo a significant change away from thattI leadership (with who knows what result for Itanic acceptance?), and if it L can help promote the first result rather than the second with really minimal effort, why not?  J In this context, Paul DeMone's numbers from his realworldtech.com 'SiliconJ Insider' articles are interesting.  Last June, his estimates of McKinley'sD performance *at 1.2 GHz and with an assumed 7-stage pipeline* were aL SPECint_base2k of 700 and a SPECfp_base2k of 1500 (by way of comparison, hisJ EV7 estimates at 1.2 GHz were 1000 and 1600, respectively, and they aren'tL much different today).  I believe his most-recent McKinley estimates (thoughL I can't find them at the moment) are 800 SPECint and 1400 SPECfp - *despite*F a lower clock frequency (1 GHz) and longer pipeline (8 stages) than heK expected last year.  Now, I realize that his understanding may have evolvedoJ some over the past 9 months, but that's a *big* change:  it's not too hardK to imagine that a few judicious words from Intel insiders might have causedtB him to move his estimate just a bit more than might turn out to beH realistic, and that the timing of this w.r.t. the merger vote (and givenI that the facts of the matter won't be known before the merger vote) isn'tf entirely coincidental.  L And there's even Intel's anomolous recapturing of some market share from AMDK last quarter:  ascribing *that* in any way to the merger would be a stretch K even for a confirmed Ken Lay conspiracy enthusiast, but it does help defuse C suggestions that Intel is losing its grip (which in turn affect the K perception of McKinley's potential, which in turn affects the perception ofeI the competence of those who have pledged the future of their companies toc it...).r  I If it weren't for the clear overlap in the timing of the Intel/Alpha dealiJ and the merger discussions I'd still be reluctant to bring up such issues.H But the merger itself is enough of a soap opera that it makes such addedL speculations in this vein seem pretty consistent, even if I still feel a bit sheepish in presenting them.   - bill   ------------------------------    Date: 28 Feb 2002 21:34:42 -0600+ From: young_r@encompasserve.org (Rob Young)-! Subject: Re: Timing is everything 3 Message-ID: <h7d9jg7BPJlu@eisner.encompasserve.org>-  p In article <8Lxf8.239707$Re2.18149826@bin6.nnrp.aus1.giganews.com>, "Bill Todd" <billtodd@metrocast.net> writes: > L > In this context, Paul DeMone's numbers from his realworldtech.com 'SiliconL > Insider' articles are interesting.  Last June, his estimates of McKinley'sF > performance *at 1.2 GHz and with an assumed 7-stage pipeline* were aN > SPECint_base2k of 700 and a SPECfp_base2k of 1500 (by way of comparison, hisL > EV7 estimates at 1.2 GHz were 1000 and 1600, respectively, and they aren'tN > much different today).  I believe his most-recent McKinley estimates (thoughN > I can't find them at the moment) are 800 SPECint and 1400 SPECfp - *despite*H > a lower clock frequency (1 GHz) and longer pipeline (8 stages) than he    g http://www.realworldtech.com/forums/index.cfm?action=detail&PostNum=584&Thread=1&entryID=5291&roomID=13   5 Topic: EV7, McKinley SPECint perf: works in progress w  + Name: Paul DeMone (pdemone@igs.net) 2/26/02d    M "Intel and Compaq people are busy fine tuning the performance of McKinley andhM EV7 running standard benchmarks in time for official release later this year.hO After talking with sources with better perspective of the difficulties involved N in maximizing integer performance of high ILP, moderate clockrate processors IM now think the SPECint_base2k estimates for EV7 and McKinley in my "Spider anduN the Mountain article" are too optimistic, especially for the McKinley. I don'tN like revising predictions made in my articles so I thought I would disclose myL misgivings about those estimates here. My new estimates for McKinley and EV7J SPECint_base2k scores are 700 at 1.0 GHz and 1000 and 1.2 GHz respectivelyN (down from 800 and 1050 in the article). Ironically that brings me back to theN same score estimates I had in my last year's "Battle in 64 bit Land Revisited"< article although the 700 figure was for a 1.2 GHz McKinley."   				RobN  u   ------------------------------  # Date: Thu, 28 Feb 2002 21:21:29 GMTr0 From: prune@ZAnkh-Morpork.mv.com (Paul Winalski), Subject: Re: What return codes mean success?8 Message-ID: <3c7e9cc5.352511755@proxy.news.easynews.com>  D On Wed, 27 Feb 2002 20:57:07 GMT, Ernest <wmozart5@yahoo.com> wrote:  I >I've noticed that when calling system() or execlp() in a C program, the iK >return codes of DCL commands (WRITE, COPY, etc.) are quite different even  K >in cases of success.  e.g., WRITE SYS$OUTPUT "Hello" returns 65537, while c >SHOW DEFAULT returns 196609.  > J >Similarly, commands like CC and CXX return some pretty bizarre values on  >success (like 12124161).  >fJ >Is there any easily programmatic way (like a macro you can pass a return J >value which will return true or false) to translate these various values I >as success or failure?  Or how else might one go about determining this?o  B Low bit set in the return code means success.  Low bit clear means failure.  ? VMS status values are 32-bit quantities with several bit fieldsn< (little-endian bit terminology--bit 0 is LSB--is used here):    bits 0-2 are the condition code:     0 = warningv     1 = success 
     2 = error      3 = informationalm     4 = fatal errorr     other values are reservedr   bits 3-14 are the message codeE bit 15 is 0 if the message code in bits 3-14 is one of the OS-definedm@     shared messages, or 1 if the message code is specific to the)     particular facility (see bits 16-31).rA bits 16-30 are the facility code of the generator of the message.t1     For example the DCL CLI's facility code is 3.y= bit 31 is 0 for system-defined facilities registered with VMS 2     Engineering, 1 for customer-defined facilities  = To use one of your examples, 65537 is hex 00010001, conditiont= code success, shared message 0, system facility 1 (RMS).  TheaD $GETMSG system service will return "%RMS-S-NORMAL, normal successful? completion" for this message.  196609 is hex 00030001, the samei= code but fir the CLI (DCL command line interpreter) facility.p; 12124161 is hex 00b90001, again the same condition code andt- message but for the CC (C compiler) facility.e    
 ---------- Remove 'Z' to reply by email..   ------------------------------  + Date: Thu, 28 Feb 2002 22:22:03 +0000 (UTC) - From: forkosh@panix1.panix.com (John Forkosh)e, Subject: Re: What return codes mean success?, Message-ID: <a5maib$c0t$2@reader2.panix.com>  2 Michael Austin (maustin@firstdbasource.com) wrote:  # : anything ANDed with 0 is failure.    I'll say!!!    ------------------------------  # Date: Fri, 01 Mar 2002 02:44:57 GMTaL From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr")! Subject: Re: [Q] internet and VMSv8 Message-ID: <00A0A410.7B9433FD@SSRL04.SLAC.STANFORD.EDU>  h In article <d7791aa1.0202280552.3f815c38@posting.google.com>, bob@instantwhip.com (Bob Ceculski) writes:v >martin@radiogaga.harz.de (Martin Vorlaender) wrote in message news:<3c79aec9.524144494f47414741@radiogaga.harz.de>..., >> Bob Ceculski (bob@instantwhip.com) wrote:9 >> > "David J. Dachtera" <djesys.nospam@fsi.net> wrote...II >> > > TCPware for OpenVMS from Process Software, http://www.process.com/rL >> > > TCPware was written from the ground up on VMS. It's kind of a pain to= >> > > manage, but is very fast for some important functions.k >> >O >> > what are you talking about a pain to manage?  it is far easier than ucx orhP >> > multinet, and once you understand the tcpware_configure.com file, you don't >> > even need $ NETCU anymore,r >> eH >> TCPWARE_CONFIGURE.COM doesn't carry an NETCU settings. It's all about >> CNFNET.COM. >> aN >> 1. I thought you violently opposed having to edit ASCII configuration filesO >>    at some time? Once you understand HTTPD.CONF, configuring Apache is easy.e >> rO >> 2. The WEBCNF (Web GUI) component has very limited functionality in TCPware.d >> s >> cu, >>   Martin  >tH >wrong!  tcpware_configure.com carries netcu settings ... one example is >        $ NETCU SET GATEWAYG >        this can be done by edt on the above con ... there are severaltN >        others I can do also ... when I say eliminate netcu almost completelyM >        I also mean cnfnet ... and editing tcpware_configure is a lot easierh8 >        than editing 8 million conf files in apache ...  J Once again, it's just utterly fine with me that Purveyor and TCPware work ) for you; I'm glad you're happy with them.n  ( However, 8 million conf files in Apache?  
 HTTPD.CONF' If you're running mod_ssl, mod_ssl.confn) If you're running mod_perl, mod_perl.conf4( If you're runing  mod_php,  mod_php.conf! Oh, if you count this: MIME.TYPESi   How hard is that?r   -- Alan           O ===============================================================================i0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056oM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210IO ===============================================================================m   ------------------------------  % Date: Fri, 01 Mar 2002 02:00:45 +0100n2 From: martin@radiogaga.harz.de (Martin Vorlaender)! Subject: Re: [Q] internet and VMSa; Message-ID: <3c7ed2bd.524144494f47414741@radiogaga.harz.de>e  ) Bob Ceculski (bob@instantwhip.com) wrote: 7 > martin@radiogaga.harz.de (Martin Vorlaender) wrote...e- > > Bob Ceculski (bob@instantwhip.com) wrote:n: > > > "David J. Dachtera" <djesys.nospam@fsi.net> wrote...J > > > > TCPware for OpenVMS from Process Software, http://www.process.com/M > > > > TCPware was written from the ground up on VMS. It's kind of a pain too> > > > > manage, but is very fast for some important functions. > > >eM > > > what are you talking about a pain to manage?  it is far easier than ucxeN > > > or multinet, and once you understand the tcpware_configure.com file, you& > > > don't even need $ NETCU anymore, > > I > > TCPWARE_CONFIGURE.COM doesn't carry an NETCU settings. It's all aboutt > > CNFNET.COM.s > > L > > I thought you violently opposed having to edit ASCII configuration filesM > > at some time? Once you understand HTTPD.CONF, configuring Apache is easy.I >vI > wrong!  tcpware_configure.com carries netcu settings ... one example isw >         $ NETCU SET GATEWAY   A Oops, you're right. The first few lines of the file deal with therC interface(s), host and domain name, etc. Which of course have NETCUI equivalents.  E But the remaining statements (those which deal with enabling servicestJ and setting up LPD queues) are used to control execution of *_CONTROL.COM,' and thus have nothing to do with NETCU.n  @ > this can be done by edt on the above con ... there are severalG > others I can do also ... when I say eliminate netcu almost completelyfF > I also mean cnfnet ... and editing tcpware_configure is a lot easier1 > than editing 8 million conf files in apache ...r  F Oh come on. You don't have to use Apache's INCLUDE statement - you canG have it all in one file (in fact, using HTTDP.CONF/SRM.CONF/ACCESS.CONFLD is deprecated). As the task at hand is a little more complicated, of4 course you do have to remember some more statements.   cu,a   Martin -- bG                            | Martin Vorlaender  |  VMS & WNT programmers4 Microsoft isn't the Borg:  | work: mv@pdv-systeme.deK the Borg have proper       |       http://www.pdv-systeme.de/users/martinv/ ; networking.                | home: martin@radiogaga.harz.dee   ------------------------------   End of INFO-VAX 2002.117 ************************  Someone once said that "intelligent" robots will black-list0E > > pages and not index them if it is not always accessible, but thisPL > > doesn't seem to be the case---I get the same bots as always, but only onK > > Sundays.  As long as I do big downloads etc myself only on Sundays, thepJ > > connection time and thus the costs are not that much (volume is not an > > issue in any case).r >  > HTHe >  > --
 > John Santose > Evans Grif