1 INFO-VAX	Fri, 12 Jul 2002	Volume 2002 : Issue 381       Contents: Re: !MalRe: OpenVMS Ambassadors  Re: !MalRe: OpenVMS Ambassadors - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - Re: "Clean" CISC (was Re: McKinley Cometh...) - RE: "Clean" CISC (was Re: McKinley Cometh...) # Re: 2002 Worldwide HP OpenVMS Study # Re: 2002 Worldwide HP OpenVMS Study # Re: 2002 Worldwide HP OpenVMS Study # Re: 2002 Worldwide HP OpenVMS Study # Re: 2002 Worldwide HP OpenVMS Study # Re: 2002 Worldwide HP OpenVMS Study # Re: 2002 Worldwide HP OpenVMS Study # Re: 2002 Worldwide HP OpenVMS Study  Re: Affordable Page Updated % Re: Alpha Shadowing Phase II question  Re: Andrew the hypocrite!  ANN: Updated GAWK and MMK ' Re: C and X11 programming, finding info ' Re: C and X11 programming, finding info 1 Re: Command Procedure to logoff inactive users... 1 Re: Command Procedure to logoff inactive users... 1 Re: Command Procedure to logoff inactive users... - Re: Dell Says on Track Despite Weak PC Demand  Re: Doing the Math on Alpha  Re: Doing the Math on Alpha  Re: Doing the Math on Alpha  Re: DS10 shutting down Re: DS10 shutting down RE: DVD drives on OpenVMS  Re: FTP Hang Question  Re: FTP Hang Question ( Re: Intel Wall Street Journal Itanium Ad& Re: List the processes using a mailbox, Re: Looking for terminal session sharing pgm, Re: Looking for terminal session sharing pgm, Re: Looking for terminal session sharing pgm, Re: Looking for terminal session sharing pgm, Re: Looking for terminal session sharing pgm, Re: Looking for terminal session sharing pgm, Re: Looking for terminal session sharing pgm, Re: Looking for terminal session sharing pgm, Re: Looking for terminal session sharing pgm, Re: Looking for terminal session sharing pgm, Re: Looking for terminal session sharing pgm Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... RE: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh... Re: McKinley Cometh...+ Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: McKinley tops SpecFP AND SpecInt charts + Re: Only 20% drop in VMS systems (was: wow) + Re: Only 20% drop in VMS systems (was: wow)  Re: OpenVMS Ambassadors  Re: OpenVMS Ambassadors  Re: OpenVMS Ambassadors  Re: OpenVMS Ambassadors A Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!)  Re: OpenVMS Polls are back!  Re: OpenVMS Polls are back!  Oracle RDB on VMS  Re: Oracle RDB on VMS  Re: Oracle RDB on VMS  Re: Oracle RDB on VMS  Re: Oracle RDB on VMS  Re: Oracle RDB on VMS  Re: Oracle RDB on VMS ! Problem with access to VMS on VAX % Re: Problem with access to VMS on VAX % Re: Problem with access to VMS on VAX % Re: Problem with access to VMS on VAX < Re: Problem with access to VMS on VAX (System Password lost) Re: RECALL suggestion  Re: TIMA Re: VAX Scan on OpenVMS Alpha  Re: VAX Scan on OpenVMS Alpha  RE: VAX Scan on OpenVMS Alpha  Re: VAX Scan on OpenVMS Alpha  RE: VAX Scan on OpenVMS Alpha  Re: VAX Scan on OpenVMS Alpha  Re: VAX Scan on OpenVMS Alpha  RE: VAX Scan on OpenVMS Alpha  VMS freewareC Re: WATCHER (was Re: Command Procedure to logoff inactive users...) C Re: WATCHER (was Re: Command Procedure to logoff inactive users...) C Re: WATCHER (was Re: Command Procedure to logoff inactive users...)  Re: Where to put startup stuff( Re: XP1000 667Mhz USD2995 !!!!! Incoming  F ----------------------------------------------------------------------   Date: 12 Jul 2002 07:26:19 GMT3 From: gartmann@immunbio.mpg.de (Christoph Gartmann) ( Subject: Re: !MalRe: OpenVMS Ambassadors0 Message-ID: <agm0ar$54c$1@n.ruf.uni-freiburg.de>  k In article <zKsX8.1146$7vA.995@news01.bloor.is.net.cable.rogers.com>, "John Smith" <a@nonymous.com> writes:  > = >"Terry C. Shannon" <terryshannon@attbi.com> wrote in message ) >news:feoX8.154289$Uu2.34623@sccrnsc03...  >> >>> ....go down the tubes. > 2 >> That is your opinion, whoever the hell you are. > J >No Terry, that's an observation of what the market does to companies thatJ >don't take their customers seriously. You've seen it and written about it >often enough.   [...]   M Perhaps I should add a story that happened around 15 years ago at IBM here in M Germany. IBM headquarters for Germany was in Stuttgart. And there was a local F sales and support office as well. The headquarters and the office wereN completely separate, in different areas of the town. Next thing was that IBM'sK PCs were sold and supported by local dealers unlesss, of course, you were a O large customer. One day a phone call came in from someone whose German whas not N that excellent. He was asking about buying PCs, the converstation seemed to beL a bit difficult and the woman at the phone got annoyed and told the guy thatK she won't seel any PCs to him, he should look for a local dealer around his I area and so on. All that not in very friendly manner. A few days later it K turned out that she talked to the boss of Olivetti. He started to build his  own PCs then...    Regards,    Christoph Gartmann   H -- --------------------------------------------------------------------+H | Max-Planck-Institut fuer      Phone   : +49-761-5108-464   Fax: -452 |H | Immunbiologie                                                        |H | Postfach 1169                 Internet: gartmann@immunbio.mpg.de     |H | D-79011  Freiburg, Germany                                           |H +--------- http://www.immunbio.mpg.de/home/english/menue.html ---------+   ------------------------------  # Date: Fri, 12 Jul 2002 13:43:17 GMT # From: "John Smith" <a@nonymous.com> ( Subject: Re: !MalRe: OpenVMS AmbassadorsE Message-ID: <V1BX8.1370$WsS.666@news01.bloor.is.net.cable.rogers.com>   < "Terry C. Shannon" <terryshannon@attbi.com> wrote in message( news:feoX8.154289$Uu2.34623@sccrnsc03... >  >> ....go down the tubes.   1 > That is your opinion, whoever the hell you are.   I No Terry, that's an observation of what the market does to companies that I don't take their customers seriously. You've seen it and written about it 
 often enough.   F In this case 'the market' is both customers and Wall Street. CustomersJ because when they walk revenues and profits drop. Wall Street because whenI revenues and profits are down, and defection rates go up and PC's haven't L turned around, then the cash cushion starts to run low and the credit ratingL suffers. Which means when they have to go to the bond market to borrow moneyE the rate they have to pay goes up significantly too, and impact later L earnings. That only makes sense in a real growth industry where revenues areK increasing by leaps and bounds. Their recent bond offerings last month were K rated "A3" by Moody's Investors Services, "A-" by Standard & Poor's and "A" K by Fitch Ratings, ***in each case with a negative outlook***. That's single H A for god's sake. Some investment managers won't buy BBB-rated bonds anyJ more, and HP is one step from that. Yes, companies are tending to buy moreG and more gear, but the unit cost keeps coming down, so revenues tend to 8 stagnate relative to where they may otherwise have been.  H With the capital markets spooked the way they are, many corporations areG going to continue to defer IT capital expenditures as long as possible, I because many of them would rather raise the money first before they spend H it, and that just isn't happening to the extent that would significantlyL help HP at this time. HP has two dead processor families (PA and Alpha) theyF are trying to flog at the same time as a new processor on the block isI introduced to not as rabid a reception as they'd have liked, one dead OS, L and another that is not marketed, and all the while the PC market hangs like* an over-ripe albatross around their necks.  F VMS was about 1/4 of the all-in revenue stream for Compaq and they didI nothing to effectively market it; with HP it's less than 10%. It's all to D easy for a big corporation to 'forget' about something that 'small',L especially when it has a small mindshare even within the corporation itself,J never mind the potential customer base. Perhaps some of the complaining inK c.o.v. reaches the ears of those that hold the controls and that would be a I good thing, because in the absence of those complaints it would seem that $ complacency is the order of the day.      @ > Incidentally, I place very  little credence in people who post" anonymously. If you don't have theK > fortitude to admit who you are, I consider your comments to be completely  > without merit.  E The truth, or reasonable approximation thereof, is where you find it, F irrespective of who writes it. Whether it is me, or you, a Nobel PrizeJ winning economist, Bob Celuski (just kidding), or somebody else who writes it matters not.     K > Now. If you think you have the power to flush me down the tubes, I hereby  > dare you to GO FOR IT!  H If you carefully re-read what I wrote, I never suggested that I would orK could do that. I am sorry I worded things that way with respect to you, but  I do mean it relative to HP.   ------------------------------  + Date: Fri, 12 Jul 2002 07:08:29 +0000 (UTC) 2 From: Anil T Maliyekke <amaliy1@icarus.cc.uic.edu>6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)+ Message-ID: <aglv9d$s2l$1@newsx.cc.uic.edu>   B In comp.arch George William Herbert <gherbert@gw.retro.com> wrote:; > While true, note that this is a standard library problem, % > not an underlying language problem.   ; > One could trivially write up a library full of equivalent 7 > functions using an alternative string handling system = > (say, a struct with string_len and string_ptr) which didn't % > have to deal with null terminators.   = String literals in C are null terminated, so it is a language  problem.   > -george william herbert  > gherbert@retro.com   ------------------------------   Date: 12 Jul 2002 07:12:52 GMT0 From: gah@ugcs.caltech.edu (glen herrmannsfeldt)6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...), Message-ID: <aglvhk$shn@gap.cco.caltech.edu>  6 gherbert@gw.retro.com (George William Herbert) writes:  / >Peter Boyle  <pboyle@holyrood.ed.ac.uk> wrote: P >>> But in Unix/C, a routine such as strcpy must really look at individual bytesP >>> to determine where the copy is to stop, so a single assembler instruction toN >>> move large amounts of data doesn't map terribly well to C in this case andE >>> you need a loop with a test for 0 in there and move byte by byte.  >> >>Absolutely, ;) >>+ >>C null terminated strings are responsible 3 >>for a great many optimisation and security evils.   : >While true, note that this is a standard library problem,$ >not an underlying language problem.  E ESA/390 now has instructions similar to many of the str... functions.   . Moving more to the CISC side than ever before.   -- glen    ------------------------------  % Date: Fri, 12 Jul 2002 09:22:34 +0200 E From: Jan C. =?iso-8859-1?Q?Vorbr=FCggen?= <jvorbrueggen@mediasec.de> 6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)* Message-ID: <3D2E83BA.A57E494@mediasec.de>  I > This brings up an interesting question. What do you consider a "clean"" J > CISC?  Intel (and AMD) has proven that you can take what most consider aJ > really ugly CISC instruction set and make it run very fast, at least for > integer code.   J Apart from its register starvation, x86 isn't that difficult to get to runF quickly, especially if you "deprecate" (by not throwing implementationI resources at them) some of the more troublesome features. The VAX and the H 68020, while "clean" in an abstract sense, are much worse because of theJ complicated interactions of execution with memory. If you look at Mashey'sG table, you will see that these features, while making life easy for the H assembler programmer, are what causes hell for the implementor. In fact,F the last VAX chips took a route similar to what Intel did with the P6:K make the RISC-like instructions run quickly in hard-wired logic and execute J everything else (relatively) slowly in microcode. See some historic copiesM of the Digital Technical Journal near you and search for "NVAX". As an aside, L the got about 50% of the SPEC(92, IIRC) performance out of the NVAX comparedK to the 21064 which was built by the same company at the same time using the - same tools on the same semiconductor process.    	Jan   ------------------------------    Date: 12 Jul 2002 00:54:38 -07004 From: gherbert@gw.retro.com (George William Herbert)6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)' Message-ID: <agm1vu$l40$1@gw.retro.com>   4 Anil T Maliyekke  <amaliy1@icarus.cc.uic.edu> wrote:C >In comp.arch George William Herbert <gherbert@gw.retro.com> wrote: < >> While true, note that this is a standard library problem,& >> not an underlying language problem. > < >> One could trivially write up a library full of equivalent8 >> functions using an alternative string handling system> >> (say, a struct with string_len and string_ptr) which didn't& >> have to deal with null terminators. > > >String literals in C are null terminated, so it is a language	 >problem.   : You're confusing "strings" with C's string type (which is,8 admittedly, something I could have made more explicit in7 my posting to avoid this, but I was bravely hoping that  everyone might just get it...).   8 It's syntactically clumsy to substitute such a system in7 where string literals are used now.  But it's possible. 6 At worst, an adapter function which returns the struct6 corresponding to a given literal can be wrapped around6 literals input into the new library... I was trying to7 figure out how to #define something which would do that 6 but it's late at night and the C preprocessor has only4 been an aquaintence for the last decade or so, not a
 close friend.      -george william herbert  gherbert@retro.com   ------------------------------  % Date: Fri, 12 Jul 2002 10:21:51 +0200 3 From: Terje Mathisen <terje.mathisen@hda.hydro.com> 6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)- Message-ID: <3D2E919F.8A6CB291@hda.hydro.com>    JF Mezei wrote:  > " > One issue about the MVC vs RISC. > L > In cobol and other languages, MVC uis extremely useful because you know in+ > advance how many bytes need to be copied.  > N > But in Unix/C, a routine such as strcpy must really look at individual bytesN > to determine where the copy is to stop, so a single assembler instruction toP > move large amounts of data doesn't map terribly well to C in this case and you? > need a loop with a test for 0 in there and move byte by byte.   E Good strcpy() implementations, either generated as inline code by the 2 compiler, or as called library code won't do that:  G Even on x86 most compilers have used 4-byte load/store operations, with  checks for any zero byte.   F Alpha have dedicated opcodes to handle this, making it very natural to move 8 bytes per iteration.    Terje  --    - <Terje.Mathisen@hda.hydro.com>@ "almost all programming can be viewed as an exercise in caching"   ------------------------------   Date: 12 Jul 2002 13:37:21 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)0 Message-ID: <agmm2h$a12$1@pegasus.csx.cam.ac.uk>  - In article <3D2E919F.8A6CB291@hda.hydro.com>, 5 Terje Mathisen <terje.mathisen@hda.hydro.com> writes:u |> JF Mezei wrote: |> > CQ |> > But in Unix/C, a routine such as strcpy must really look at individual bytesCQ |> > to determine where the copy is to stop, so a single assembler instruction to.S |> > move large amounts of data doesn't map terribly well to C in this case and youlB |> > need a loop with a test for 0 in there and move byte by byte. |> nH |> Good strcpy() implementations, either generated as inline code by the5 |> compiler, or as called library code won't do that:. |> eJ |> Even on x86 most compilers have used 4-byte load/store operations, with |> checks for any zero byte. |> (I |> Alpha have dedicated opcodes to handle this, making it very natural to2 |> move 8 bytes per iteration.  < It is a pity that correct code has great difficulty in using them :-(  = In C+POSIX or C+OpenMP, it is permitted for two threads (or aM? thread and a signal handler) to access separate objects with noe; explicit synchronisation, provided that the objests are noth< aliased in the language sense.  And, because it is permitted9 to access any byte of any type of object as a char, it isf; generally essential not to access even a single byte beyondc the end of a string.  ? It is commonly believed that this applies only for writing, bute= that is not so.  It is permitted for one thread or handler to ; do I/O directly to an object, which is in turn permitted to > lock the object to that process in hardware.  You can then get? deadly embraces in programs that conceptually should terminate.p  = Now, I don't know the exact specification of the Alpha codes, = and there are ways to get some way without falling foul of C,m, POSIX or OpenMP, but it is a nightmare area.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679m   ------------------------------   Date: 12 Jul 2002 14:39:15 GMT From: Dan.Pop@ifh.de (Dan Pop)6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)* Message-ID: <agmpmj$k1s$1@sunnews.cern.ch>  R In <agmm2h$a12$1@pegasus.csx.cam.ac.uk> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:  > >In C+POSIX or C+OpenMP, it is permitted for two threads (or a@ >thread and a signal handler) to access separate objects with no< >explicit synchronisation, provided that the objests are not= >aliased in the language sense.  And, because it is permitted : >to access any byte of any type of object as a char, it is< >generally essential not to access even a single byte beyond >the end of a string.  >i@ >It is commonly believed that this applies only for writing, but> >that is not so.  It is permitted for one thread or handler to< >do I/O directly to an object, which is in turn permitted to? >lock the object to that process in hardware.  You can then gett@ >deadly embraces in programs that conceptually should terminate.  4 Show us a *concrete* example on a *concrete* system.  I On most systems this is not possible at all in the first place, thereforecI neither implementors nor users are affected in any way.  Normally, if youaE can read one byte in a machine word, you can read the whole word (howa@ many modern architectures have memory systems that support byte = transactions?).  This property is exploited by most efficient:C strcpy implementations that read the input data one word at a time.o   Dan  -- Dan Pope DESY Zeuthen, RZ group Email: Dan.Pop@ifh.dee   ------------------------------   Date: 12 Jul 2002 15:00:33 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)0 Message-ID: <agmquh$e2u$1@pegasus.csx.cam.ac.uk>  K In article <agmpmj$k1s$1@sunnews.cern.ch>, Dan.Pop@ifh.de (Dan Pop) writes:SU |> In <agmm2h$a12$1@pegasus.csx.cam.ac.uk> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:M |> hA |> >In C+POSIX or C+OpenMP, it is permitted for two threads (or a C |> >thread and a signal handler) to access separate objects with noA? |> >explicit synchronisation, provided that the objests are not @ |> >aliased in the language sense.  And, because it is permitted= |> >to access any byte of any type of object as a char, it isC? |> >generally essential not to access even a single byte beyondR |> >the end of a string. |> >C |> >It is commonly believed that this applies only for writing, but A |> >that is not so.  It is permitted for one thread or handler to-? |> >do I/O directly to an object, which is in turn permitted torB |> >lock the object to that process in hardware.  You can then getC |> >deadly embraces in programs that conceptually should terminate.g |>  7 |> Show us a *concrete* example on a *concrete* system.e  @ No problem.  Back in the 1970s, a colleague and I used preciselyA that technique to get a 370/165's cache out of step with its main5
 memory :-)  ? Note that getting cache out of step with memory in the way thatu: we did it was a form of locking the object to a process in> hardware.  It wasn't an exclusive lock, but it was effectively< allowing a shared lock for an object that was being updated.  L |> On most systems this is not possible at all in the first place, thereforeL |> neither implementors nor users are affected in any way.  Normally, if youH |> can read one byte in a machine word, you can read the whole word (howC |> many modern architectures have memory systems that support byte  @ |> transactions?).  This property is exploited by most efficientF |> strcpy implementations that read the input data one word at a time.  B I am fully aware that most modern systems have a memory managementB system based around the concept of atomic cache lines.  So none ofA them will see this problem?  Well, er, almost.  There are quite ad/ few things wrong with that assumption, such as:,  A     1) What is true today may not be true tomorrow.  So a programh> that relies on such a property can get into use, have everyoneB who understands it die off, and then fail.  Been there, seen that.  B     2) This doesn't apply just at the byte level, but at ANY levelB where two types of access are in (assumed atomic) units, but where? the units are different.  Such as when one unit is a cache line  and the other is a word.  C     3) Quite a few still have most significant word first fetching, A and some still have real DMA (i.e. not through the cache system).r@ And it was the combination of those two that enabled us to trick the 370/165.  A I have been informed by people that I regard as reliable that the-A problem was present until very recently on a wide range of chips,m@ under circumstances described in (3).  None of them have checked< up on the last few years' new architectures, but I should be> surprised if all of them were immune.  Certainly, looking at a? few current architectures, I should be mildly surprised if they ? really had closed the loophole entirely, because to do so needsa; primitives not in the architecture (but which may be in thee8 system-specific, undocumented, hardware implementation).     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679u   ------------------------------   Date: 12 Jul 2002 16:35:09 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon)n6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...), Message-ID: <agn0ft$2icc$1@info.cs.uofs.edu>  H In article <Pine.GSO.4.33.0207120104250.10471-100000@holyrood.ed.ac.uk>,/  Peter Boyle <pboyle@holyrood.ed.ac.uk> writes:i |>, |> C null terminated strings are responsible4 |> for a great many optimisation and security evils.   Sigh....  Here we go again.r  ; C did not invent the concept of the null terminated string.s: MACRO-11 had it and I'm sure it didn't begin there either.   bill   -- aJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>       ------------------------------   Date: 12 Jul 2002 17:28:41 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)6 Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)0 Message-ID: <agn3k9$lcp$1@pegasus.csx.cam.ac.uk>  , In article <agn0ft$2icc$1@info.cs.uofs.edu>,3 bill@triangle.cs.uofs.edu (Bill Gunshannon) writes:iK |> In article <Pine.GSO.4.33.0207120104250.10471-100000@holyrood.ed.ac.uk>,a2 |>  Peter Boyle <pboyle@holyrood.ed.ac.uk> writes: |> |>s/ |> |> C null terminated strings are responsibler7 |> |> for a great many optimisation and security evils.  |> i |> Sigh....  Here we go again. |>  > |> C did not invent the concept of the null terminated string.= |> MACRO-11 had it and I'm sure it didn't begin there either.n  ; It didn't.  It was invented well before my time, though the = character used was not always a NUL.  Just possibly, MACRO-11a= started using a NUL, but special-character-terminated stringsn" date from before modern computers.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679a   ------------------------------  % Date: Fri, 12 Jul 2002 10:20:33 -0700i# From: "Tom Linden" <tom@kednos.com>c6 Subject: RE: "Clean" CISC (was Re: McKinley Cometh...)9 Message-ID: <CIEJLCMNHNNDLLOOGNJIOEKDFFAA.tom@kednos.com>s  # Bad ideas have a way of survivng:-)   - Bill, do you stll have the BA350s to dispose?s   >-----Original Message-----i9 >From: Bill Gunshannon [mailto:bill@triangle.cs.uofs.edu]e$ >Sent: Friday, July 12, 2002 9:35 AM >To: Info-VAX@Mvb.Saic.Com7 >Subject: Re: "Clean" CISC (was Re: McKinley Cometh...)  >e >eI >In article <Pine.GSO.4.33.0207120104250.10471-100000@holyrood.ed.ac.uk>,f0 > Peter Boyle <pboyle@holyrood.ed.ac.uk> writes: >|>t- >|> C null terminated strings are responsibled5 >|> for a great many optimisation and security evils.  >r >Sigh....  Here we go again. >-< >C did not invent the concept of the null terminated string.; >MACRO-11 had it and I'm sure it didn't begin there either.: >: >bill" >S >-- K >Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvescE >bill@cs.scranton.edu     |  and a sheep voting on what's for dinner.  >University of Scranton   |nB >Scranton, Pennsylvania   |         #include <std.disclaimer.h>    >  >---' >Incoming mail is certified Virus Free.v; >Checked by AVG anti-virus system (http://www.grisoft.com).eA >Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002  >a --- & Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002   ------------------------------    Date: 12 Jul 2002 08:39:08 +0800, From: Paul Repacholi <prep@prep.synonet.com>, Subject: Re: 2002 Worldwide HP OpenVMS Study- Message-ID: <87ptxtbx03.fsf@prep.synonet.com>>  3 "Terry C. Shannon" <terryshannon@attbi.com> writes:e  E > Yep. But here's a question: having cast all the EV8 developers into,E > the not-so-tender embrace of L'Intella, and having lost over a yeardB > of development, is there any way in which HPQ could re-start the
 > effort now?l  eD Continue the EV8. The chip people should now be free to return, withF pockets intact :) and continue on. A low cost EV8LCA would be a REALLY- good idea at the moment, for several reasons.g   -- e< Paul Repacholi                               1 Crescent Rd.,7 +61 (08) 9257-1001                           Kalamunda.r@                                              West Australia 6076. Raw, Cooked or Well-done, it's all half baked.F EPIC, The Architecture of the future, always has been, always will be.   ------------------------------    Date: 12 Jul 2002 05:48:21 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)v, Subject: Re: 2002 Worldwide HP OpenVMS Study3 Message-ID: <FhboRWcfOEdx@eisner.encompasserve.org>8  \ In article <87ptxtbx03.fsf@prep.synonet.com>, Paul Repacholi <prep@prep.synonet.com> writes:5 > "Terry C. Shannon" <terryshannon@attbi.com> writes:n > F >> Yep. But here's a question: having cast all the EV8 developers intoF >> the not-so-tender embrace of L'Intella, and having lost over a yearC >> of development, is there any way in which HPQ could re-start thel >> effort now? >  (F > Continue the EV8. The chip people should now be free to return, withH > pockets intact :) and continue on. A low cost EV8LCA would be a REALLY/ > good idea at the moment, for several reasons.n  C Are you suggesting that the contract Intel and Compaq signed makinguE IA64 Compaq's stated direction for the future has no penalty clause ?eD It probably has a time limit, but for that time limit to be as short as one year seems improbable.i   ------------------------------  # Date: Fri, 12 Jul 2002 13:53:17 GMTu# From: "John Smith" <a@nonymous.com> , Subject: Re: 2002 Worldwide HP OpenVMS StudyH Message-ID: <hbBX8.22534$WJf1.3556@news01.bloor.is.net.cable.rogers.com>  : "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message- news:FhboRWcfOEdx@eisner.encompasserve.org...p> > In article <87ptxtbx03.fsf@prep.synonet.com>, Paul Repacholi <prep@prep.synonet.com> writes: 7 > > "Terry C. Shannon" <terryshannon@attbi.com> writes:- > >-H > >> Yep. But here's a question: having cast all the EV8 developers intoH > >> the not-so-tender embrace of L'Intella, and having lost over a yearE > >> of development, is there any way in which HPQ could re-start the  > >> effort now? > >eH > > Continue the EV8. The chip people should now be free to return, withJ > > pockets intact :) and continue on. A low cost EV8LCA would be a REALLY1 > > good idea at the moment, for several reasons.t >iE > Are you suggesting that the contract Intel and Compaq signed makingnG > IA64 Compaq's stated direction for the future has no penalty clause ?gF > It probably has a time limit, but for that time limit to be as short > as one year seems improbable.,    L If the contract states that Compaq agreed to not continue development on EVxG or market systems based on EVx, then it is probable that a sharp lawyeryD could 'prove' it an unenforceable contract given that CPQ apparently retained IP rights.   L Mind you, given CPQ's 'smarts' about all this, it's just as likely that they! signed a suicide pact with Intel.    ------------------------------  % Date: Fri, 12 Jul 2002 14:26:33 +0100gU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com> , Subject: Re: 2002 Worldwide HP OpenVMS Study0 Message-ID: <agmldd$6i4$1@new-usenet.uk.sun.com>   JF Mezei wrote:y   > Robert Deininger wrote:  > K >>Then I guess it is also wrong to blindly assume the numbers tossed aroundrG >>here for Alpha development and production costs are realistic.  If an1I >>alpha CPU cost several times as much as the guesses seen here, it wouldRK >>certainly change the flavor of many of the "economic" arguments that haveh >>been swirling. >> > C > Correct. But if Sun can do it, how come Digital/Compaq couldn't ?o > P > If one company is able to develop its own chip and not complain about how muchN > it costs, then other companies SHOULD be able to do the same. In the case ofN > Compaq, it was clear that they were not interested in this and any argumentsN > they brought forwards would clear be sqewed to help justify their decisions. >     G Sun started with a different model to Digital, we were always a FABlesseH CPU vendor, Sun designs the CPU's with some involvement from the foundryH and then it is built by one of a number of vendors. Over the years SPARC> CPU's have been built by Ross, LSI, TI, Fujitsu, Phillips etc.  : Digitals decision to build their own FAB for Alpha was one> of the causes of Digitals demise, they bled money. The sale of? the FAB facilites to Intel was a mitigation measure to stop the  flow of red ink.  @ Since the sale of the FAB and the Compaq purchase Alpha has been> FABless like SPARC, however Alpha has never acheived parity in: volumes with SPARC making the returns on design investment; lower. It costs roughly the same to design a SPARC or Alpha> CPU.  > Compaq also never invested enough in designing multiple ranges= of Alpha CPU's to meet different customer requirements. There ; isn't for example a low cost lower power Alpha range, which < could have been the basis of the low cost Alpha systems that; people in this newsgroup clamoured for. Interesting becausem; this is also the issue that IA-64 has as well, don't expect : to see blade servers using IA-64 any time soon in any sort of large densities.>  8 Not having the product spread has the effect of reducing; the market impact of the rest of the product range. Despiteh4 claims to the contrary customers like building their? infrastructure using a minimal number of vendors and platforms.>= Not having a low end Alpha system ment that Compaq had to usee; Wintel boxes as well, this in turn lowered their chances ofy selling larger Alpha Servers.f  > Very few customers buy the one vendor multiple platforms story@ that Compaq/IBM/HP put about, experience has shown them that theG Wintel division and the UNIX/OpemVMS/AS400/MVS divisions of the companybB that can apparently provide end to end solutions behave as if they? are different companies anyway, amazingly some customers end upi# paying IBM GS to sort out the mess.   ; Most of the large corporates I have worked in have ended upn: because of this with a prefered wintel vendor which has noA relationship to whoever their prefered datacenter systems vendorsr are.  C Finally Sun's breadth of SPARC products has allowed us to ammortiser: the costs of developing the OS, Compilers to a far greater> extent than Compaq was ever able to do with Alpha. It has also= allowed us to address market segments not available to Alpha.s# Appliances, blades, FT servers etc.    RegardsI Andrew Harrisoni    K > Consider that prior to June 25, IA64 was a flawed architecture that couldpL > never catch up to Alpha, and was a chip so physically big and complex thatK > Intel's production costs would be much higher than for Alpha (in terms of M > yields etc). Magically, on June 25, IA64 was the architecture of the future@C > which would quickly surpass Alpha which couldn't keep up anymore.. > P > It is very clear in my mind that Compaq didn't provide the REAL reasons why itN > took the actions on June 25 but it has much more to do with its relationshipB > with Intel (and HP) than it does about the true costs of Alpha.  > L > Consider also the reasoning behind the sacrificial offering of the DigitalN > compiler people to the Intel god.  HP saw a reason to keep its own compilersM > for IA64 which would give it competitive advantage. Compaq could  have donet  > the same, but it chose not to. >    ------------------------------  + Date: Fri, 12 Jul 2002 15:42:27 +0000 (UTC)r From: david20@alpha1.mdx.ac.uk, Subject: Re: 2002 Worldwide HP OpenVMS Study+ Message-ID: <agmtd3$koa$2@aquila.mdx.ac.uk>   c In article <FhboRWcfOEdx@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes:g] >In article <87ptxtbx03.fsf@prep.synonet.com>, Paul Repacholi <prep@prep.synonet.com> writes:.6 >> "Terry C. Shannon" <terryshannon@attbi.com> writes: >> pG >>> Yep. But here's a question: having cast all the EV8 developers into G >>> the not-so-tender embrace of L'Intella, and having lost over a year D >>> of development, is there any way in which HPQ could re-start the >>> effort now?n >>  G >> Continue the EV8. The chip people should now be free to return, withoI >> pockets intact :) and continue on. A low cost EV8LCA would be a REALLYY0 >> good idea at the moment, for several reasons. >-D >Are you suggesting that the contract Intel and Compaq signed makingF >IA64 Compaq's stated direction for the future has no penalty clause ?E >It probably has a time limit, but for that time limit to be as shortt >as one year seems improbable.   Well two things come to mind :-s   1) Compaq no longer exists..  4 2) Employees are not slaves to be bartered and sold.    
 David Webb VMs and Unix team leader CCSS Middlesex University   ------------------------------  % Date: Fri, 12 Jul 2002 12:24:59 -0400A- From: JF Mezei <jfmezei.spamnot@videotron.ca>h, Subject: Re: 2002 Worldwide HP OpenVMS Study, Message-ID: <3D2F02D8.128D62A9@videotron.ca>  ( Andrew Harrison SUNUK Consultancy wrote:E > Finally Sun's breadth of SPARC products has allowed us to ammortiseb< > the costs of developing the OS, Compilers to a far greater4 > extent than Compaq was ever able to do with Alpha.  N The biggest difference between Sun and "Digital" is that Sun wants to sell andL grow its own products, whereas the Digital products were seen as liabilities% that should be hidden and phased out.>  J The initial "we FAB them" model by Digital wasn't flawed per say. What wasM flawed is that management did not want to allow the FAB's capacity to be sold1K to third parties, except for the token StrongArm business. Had the FAB beenhM marketed and allowed to do FABbing business for others (perhaps including Sun D , AMD, MIPS etc), it might have had volumes that made it profitable.  H Where the FAB model failed is in thinking it would work for only one low volume chip.  I In a way, Palmer was spineless. He would have needed to abandon the "safetL Wintel" business and dive head first witha  whole range of Alphas, includingN low end to compete head to head with wintel. But he didn't have the guts to doI that and thought that developping a wintel business was the safest thing.t  M Building 2000 low end Alphas that each generate a modest profit is still moresC profitable than building 100,000 wintel boxes that each lose money.    ------------------------------    Date: 12 Jul 2002 12:14:40 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)o, Subject: Re: 2002 Worldwide HP OpenVMS Study3 Message-ID: <APcrd5NdfHM9@eisner.encompasserve.org>   L In article <agmtd3$koa$2@aquila.mdx.ac.uk>, david20@alpha1.mdx.ac.uk writes:e > In article <FhboRWcfOEdx@eisner.encompasserve.org>, Kilgallen@SpamCop.net (Larry Kilgallen) writes: ^ >>In article <87ptxtbx03.fsf@prep.synonet.com>, Paul Repacholi <prep@prep.synonet.com> writes:7 >>> "Terry C. Shannon" <terryshannon@attbi.com> writes:v >>> H >>>> Yep. But here's a question: having cast all the EV8 developers intoH >>>> the not-so-tender embrace of L'Intella, and having lost over a yearE >>>> of development, is there any way in which HPQ could re-start thee >>>> effort now? >>>  hH >>> Continue the EV8. The chip people should now be free to return, withJ >>> pockets intact :) and continue on. A low cost EV8LCA would be a REALLY1 >>> good idea at the moment, for several reasons.  >>E >>Are you suggesting that the contract Intel and Compaq signed makingiG >>IA64 Compaq's stated direction for the future has no penalty clause ?fF >>It probably has a time limit, but for that time limit to be as short >>as one year seems improbable.t > ! > Well two things come to mind :-  >  > 1) Compaq no longer exists.y  0 But the contracts they signed are binding on HP.  6 > 2) Employees are not slaves to be bartered and sold.  D That contract does not affect the rights of individuals, but it doesC affect the rights of HP.  Perhaps they are allowed to pick up again,B developing EV8 provided they give Intel all the money back.  SinceA a lot of the compensation likely was in the form of reduced Intel7B prices, they better be ready to jump exclusively to AMD and Power4& before they decide to give up on IA64.   ------------------------------   Date: 12 Jul 2002 17:20:56 GMT1 From: bill@triangle.cs.uofs.edu (Bill Gunshannon) , Subject: Re: 2002 Worldwide HP OpenVMS Study, Message-ID: <agn35o$2jeg$1@info.cs.uofs.edu>  + In article <agmtd3$koa$2@aquila.mdx.ac.uk>,e!  david20@alpha1.mdx.ac.uk writes:> |> |> e7 |> 2) Employees are not slaves to be bartered and sold.e |> o  = That's what I said at the time of the deal.  I was assured byt: many here that I was wrong and that the companies involved< could in fact exhibit that level of control over where these  people would be allowed ro work.   bill   -- aJ Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolvesD bill@cs.scranton.edu     |  and a sheep voting on what's for dinner. University of Scranton   |A Scranton, Pennsylvania   |         #include <std.disclaimer.h>   a   ------------------------------  # Date: Fri, 12 Jul 2002 17:42:56 GMT.1 From: "Terry C. Shannon" <terryshannon@attbi.com>>$ Subject: Re: Affordable Page Updated, Message-ID: <AyEX8.37076$Jp.70986@rwcrnsc53>  	 Hi David,t  A Thanks for updating the Affordable Page and adding the new polls!d   Your efforts are appreciated.o  < "David J. Dachtera" <djesys.nospam@fsi.net> wrote in message! news:3D2A4BD1.8AB9AB38@fsi.net...  > "David J. Dachtera" wrote: > >iE > > The "Unofficial Affordable OpenVMS Home Page" has been updated tov  > > reflect VMS's new ownership. > >sJ > > I consider this an interim update since I don't currently know what HPL > > will be calling their ISV program (DEC had A.S.A.P., Q had C.S.A.). Once4 > > that info. comes my way, I'll update this again. > > C > > Denizens of HP: please bring this page to the attention of yourd- > > management. The link is in my sig., belown >rC > I've also discovered that the free polls have disappeared. I willeE > recreate them and post a note to such effect here and in some other  > groups as well.  >3H > Sorry for the inconvenience, but at least you'll be able to vote againD > on these issues. Maybe this time, someone will listen. (Hey, I can	 > dream!)R >M > -- > David J. Dachtera- > dba DJE SystemsO > http://www.djesys.com/ >s* > Unofficial Affordable OpenVMS Home Page:! > http://www.djesys.com/vms/soho/o   ------------------------------   Date: 12 Jul 02 06:22:25 PST From: mckinneyj@cpva.saic.come. Subject: Re: Alpha Shadowing Phase II question( Message-ID: <4OyLZd3vPiqS@cpva.saic.com>  , In article <3D2E1A9A.B2215733@videotron.ca>,0  JF Mezei <jfmezei.spamnot@videotron.ca> writes: > Witchy wrote:c >> >INITIALIZE >> >
 >> >  /SHADOWd >> >G >> >        /SHADOW=(device_name_1, device_name_2, device_name_3) labelo > A >> see that. Surely though a full copy must be performed anyway? e > K > *speculation* Perhaps what this does is simply setup the few prerequisiteCN > files in [000000] on all 3 drives at the same time, and with the rest markedO > "unused" it doesn't bother copying the "random" data on the unused portion ofl
 > the drive ?d > L > This way, when you copy data to the new "empty" shadowset, perhaps it onlyN > needs to write the new data to all drives without having to first compare to! > see if it needs to be written ?e > & > This is just speculation on my part.  D Check out Rick Lord's OpenVMS Technical Update Days Volume Shadowing presentation  C http://www.compaq.at/downloads/events/openvms/11New_HBVS_slides.pptt   The notes for slide 25 say  K "o This new qualifier lets you format all of the disks you plan to add to a H    shadow set at once, and avoid copies when the VU is initially mountedK  o Because this only writes file system data on the disk, a merge operationS/    is likely to find lots of mismatching blockscI  o You can use /ERASE to ensure that every block on each disk is the samehH  o Or you can, once the VU is mounted, fill it up with scratch files andG    then delete them - not as complete as /ERASE, but it will help a lottI  o The goal is just to make sure that the disks are as alike as possible"t   ------------------------------  % Date: Fri, 12 Jul 2002 14:38:19 +0100nU From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>f" Subject: Re: Andrew the hypocrite!0 Message-ID: <agmm3f$6i4$2@new-usenet.uk.sun.com>   Bob Ceculski wrote:1  G >>>FWIW, Solaris is more or less "UN*X vanilla" here: at, atq, crontab, 4 >>>etc., but no batch queues as VMS folks know them. >>>s >>>h >>D >>But there is a wealth of 3rd party batch queue products, Control-M
 >>etc etc. >>	 >>Regards- >>Andrew Harrisona >> > = > from one of your prior posts Andrew about VMS IP stacks ...a > E > Nice try but not the point. Who gives a rats arse if Multinet isn'tOF > vunerable. Now days no customer expects to have to buy an additionalC > layered 3rd party product to get IP support in an OS and very fewhE > customers would be impressed with the idea that you need to do thist, > because the vendors own product is broken. >     1 Bob if you cannot work out the difference betweeno0 the basic requirement in the internet age for an3 OS to include a functioning and not to CERT adverse 2 IP stack and the need for a reliable batch queuing system then you need help.  4 As ever you are a delight and a joy to converse with keep it up :):):)e   Regardsm Andrew Harrisonr   ------------------------------  # Date: Fri, 12 Jul 2002 12:35:45 GMTm- From: goathunter@goatley.com (Hunter Goatley)f" Subject: ANN: Updated GAWK and MMK0 Message-ID: <3d2ecb5f.89461328@news.process.com>  : GAWK V3.1.1 and MMK V3.9-3 are now available for download.  F GAWK (GNU awk) is a powerful pattern-matching scripting language (sortE of a precursor to Perl).  The previous version I'd made available wase@ V3.0.6; this is the current release, V3.1.1.  My distribution isB unmodifified from the original GNU distribution, I just Zipped theA original files up and added a [.VMS-BINARIES] subdirectory, whicht@ contains object files for both VAX (V5.4-2 and higher) and Alpha? (V6.1 and higher).  The official home for the gawk distributions: (without VMS binaries) is: ftp://ftp.gnu.org/pub/gnu/gawk/  ? MMK V3.9-3 corrects a couple of bugs from the previous release.,= MMK is Matt Madison's MaKe utility for VMS that is compatible ? with DEC's MMS (I'm sorry, it's still DEC in my mind).  MMK can @ process most DESCRIP.MMS files without modification and includes@ additional features not supported by MMS.  The official home for  MMK is:  http://www.madgoat.com/  4 You can find both packages using the following URLs:   http://www.process.com/openvms/   4 ftp://ftp.process.com/vms-freeware/fileserv/gawk.zip9 http://vms.process.com/ftp/vms-freeware/fileserv/gawk.zipl0 ftp://ftp.tmk.com/vms-freeware/fileserv/gawk.zip5 http://www.tmk.com/ftp/vms-freeware/fileserv/gawk.zips  3 ftp://ftp.process.com/vms-freeware/fileserv/mmk.zip 8 http://vms.process.com/ftp/vms-freeware/fileserv/mmk.zip/ ftp://ftp.tmk.com/vms-freeware/fileserv/mmk.zip 4 http://www.tmk.com/ftp/vms-freeware/fileserv/mmk.zip  ( and on the mirrors in the next 24 hours.   Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/ 8 goathunter@goatley.com    http://www.goatley.com/hunter/< New Robert R. McCammon site: http://www.RobertRMcCammon.com/   ------------------------------  % Date: Fri, 12 Jul 2002 12:01:46 -0400e; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com> 0 Subject: Re: C and X11 programming, finding info$ Message-ID: <3d2efd9d$1@news.si.com>  . >Perhaps your DECW$Server hasn't been started?  I Perhaps.  Because there is no graphics board on a VAX 7730 (or VAX 4600),PK why run it?  However, the font daemon _is_ running and does find the fonts.  --A Brian Tillman                   Internet: tillman_brian at si.comnA Smiths Aerospace                          tillman at swdev.si.coma= 3290 Patterson Ave. SE, MS      Addresses modified to preventt< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------  # Date: Fri, 12 Jul 2002 17:14:53 GMTa5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> 0 Subject: Re: C and X11 programming, finding info2 Message-ID: <h8EX8.28$Os7.426031@news.cpqcorp.net>  K That's because the logical is there for the server as a search path.  It isfK server-specific, as you might have multiple servers, and perhaps not all atA& the same DPI, or using the same fonts.    = JF Mezei wrote in message <3D2DD387.88ADD037@videotron.ca>...F >Martin Vorlaender wrote:e# >> $ sho logical /table=* decw$font A >>    "DECW$FONT" = "DECW$SYSCOMMON:[SYSFONT.DECW.USER_CURSOR32]"s >>  (DECW$SERVER0_TABLE) > L >OK, I have it too, but without the TABLE=* the logical is not visible. This# >means that "dir DECW$FONTS" fails.e   ------------------------------  # Date: Fri, 12 Jul 2002 08:38:55 GMTe$ From: "labadie" <labadie_g@decus.fr>: Subject: Re: Command Procedure to logoff inactive users...1 Message-ID: <zAwX8.3$_h7.155716@news.cpqcorp.net>a  : "JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message& news:3D2DFCF6.90D43C38@videotron.ca... > Shiva MahaDeva wrote:e > > J > > Is there any way to make a Command Procedure to logoff inactive users? >dJ > There would be, but it wouldn't be pretty. You need to keep an artray ofJ > CPU/IO numbers for each process and compare it to see it it has moved in thee > last XX minutes.   JF is right.L I remember a site where a Dcl procedure did that (in 1988), when it started,@ you could as well go and have a coffee, it was close to a freeze for 5 minutes !r   Grard   ------------------------------    Date: 12 Jul 2002 07:57:41 -0600- From: koehler@encompasserve.org (Bob Koehler)l: Subject: Re: Command Procedure to logoff inactive users...3 Message-ID: <LU0p+1PUQWIc@eisner.encompasserve.org>t  m In article <ddf392ea.0207111321.45d8392b@posting.google.com>, contracer11@uol.com.br (Shiva MahaDeva) writes:dH > Is there any way to make a Command Procedure to logoff inactive users?  G    Yes, and it almost certainly will be wrong.  It's a simple idea, butoB    it's hard to implement it correctly.  There are packages on theD    freeware CD and commercially available packages that do good jobs    of this.   E    Hitman is probably one of the most popular commercial packages fort    this.   ------------------------------  % Date: Fri, 12 Jul 2002 15:07:06 +0200f9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>d: Subject: Re: Command Procedure to logoff inactive users...' Message-ID: <3D2ED47A.5B5A351A@aaa.com>a  2 And WATCHER is the most popular *free* package :-)  < http://vms.process.com/scripts/fileserv/fileserv.com?WATCHER   Jan-Erik Sderholm   Bob Koehler wrote: > o > In article <ddf392ea.0207111321.45d8392b@posting.google.com>, contracer11@uol.com.br (Shiva MahaDeva) writes:iJ > > Is there any way to make a Command Procedure to logoff inactive users? > I >    Yes, and it almost certainly will be wrong.  It's a simple idea, buteD >    it's hard to implement it correctly.  There are packages on theF >    freeware CD and commercially available packages that do good jobs
 >    of this.R > G >    Hitman is probably one of the most popular commercial packages forw
 >    this.   ------------------------------  # Date: Fri, 12 Jul 2002 17:45:21 GMTa1 From: "Terry C. Shannon" <terryshannon@attbi.com>c6 Subject: Re: Dell Says on Track Despite Weak PC Demand? Message-ID: <RAEX8.331542$R61.296079@rwcrnsc52.ops.asp.att.net>A  . "John Smith" <a@nonymous.com> wrote in messageA news:GPGW8.3249$UHe1.2048@news01.bloor.is.net.cable.rogers.com...- >-L http://story.news.yahoo.com/news?tmpl=story&cid=580&ncid=749&e=6&u=/nm/20020" > 709/bs_nm/tech_dell_outlook_dc_4 >0+ > Dell Says on Track Despite Weak PC Demandm > Tue Jul 9, 1:20 PM ETk > By Caroline Humero >fL > NEW YORK (Reuters) - Dell Computer Corp. on Tuesday said it had not seen aI > pick-up in demand for personal computers but its results in the currentpH > quarter were on track as it holds down costs and captures market share from > competitors. >hG > The No. 2 PC maker also poured cold water on rumors that it might buyo+ > printer maker Lexmark International Inc..  >rE > "We are still sticking by our guidance of our earnings call," ChiefaH > Operating Officer Kevin Rollins said on a Bear Stearns conference call with > investors. >,H > Dell previously predicted fiscal second-quarter earnings of 18 cents aK > share, up from 16 cents a year earlier, and revenue of $8.2 billion, up 8e
 > percent.  K Gotta hand it to Dell. They continue to do pretty darned well. Longer term, I though, will the firm be able to extend itself into the enterprise, wheretA systems are generally not purchased over the Web? Time will tell.e   ------------------------------  % Date: Fri, 12 Jul 2002 11:26:32 +0100e% From: Alan Greig <a.greig@virgin.net>l$ Subject: Re: Doing the Math on Alpha8 Message-ID: <8uatiu01lpae7g7jrhmjahr9n7u0fuo922@4ax.com>  4 On Thu, 11 Jul 2002 19:30:34 GMT, "Terry C. Shannon" <terryshannon@attbi.com> wrote:e   >.L >That is, of course, if you take data points gathered from CPQ execs anotherE >sources at face value. Some of our resident experts claim that AlphalM >remained intensely profitable and that it was killed by a Conspiracy Theory.dJ >However, none of the Conspiracy Theorists can back up their rantings. ButB >hey, when have they let the facts get in the way of a good story?  D I have it on good authority that the higher Alpha costs included the? full amount of shared costs such as compiler groups etc.  By my D reckoning, had these been charged fully to VMS and Tru64, both wouldC have remained immensely profitable and Alpha would have looked muchl better.A  C Assigning as much of the shared costs as possible to the Alpha chipAA bottom line is exactly what you would do if you wanted to justifyb$ shutting down Alpha on cost grounds.  @ I can give you the source by private email for this if you wish.  @ As we all know, even if we had professional auditors look at theF books, it would be difficult to answer these questions with certainty.E What we can say for certain is that the entire ex-DEC Alpha/VMS/Tru64t> group made a lot more money than the PC business. And that the? Alphacide risks sales losses in the most profitable part of thed	 business.a  9 In other words the knock on effect of the Alphacide risksl; "opportunity" losses for VMS and Tru64 if I recall my basicsF accountancy terminology. Not taking this into account fully could be aF breach of duty to shareholders no matter how well you could argue that Alpha itself was a money drain.. -- Alan   ------------------------------   Date: 12 Jul 2002 11:53:17 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren)$ Subject: Re: Doing the Math on Alpha0 Message-ID: <agmfvd$4np$1@pegasus.csx.cam.ac.uk>  A In article <zarX8.50379$Bt1.2788420@bin5.nnrp.aus1.giganews.com>,e, "Bill Todd" <billtodd@metrocast.net> writes:? |> "Terry C. Shannon" <terryshannon@attbi.com> wrote in message.+ |> news:u1lX8.484846$cQ3.41339@sccrnsc01...a |> a2 |> > Some of our resident experts claim that Alpha" |> > remained intensely profitable |>  I |> And have backed these claims fairly solidly with Compaq's own figures.e  C There is also very good evidence that the fact that the Alpha salesh@ figures were poor was not because there was a lack of customers.@ I don't know how many customers were begging to buy, but many of> them were wanting to buy in units of dozens, hundreds or more.  3 |> > and that it was killed by a Conspiracy Theory.s |> t/ |> I lean toward an Incompetence Theory myself.   , I lead towards an anti-Conspiracy Theory :-)  J |> > However, none of the Conspiracy Theorists can back up their rantings. |> oO |> Ah, but evidence of incompetence (and accompanying incompetent mendacity) isdK |> far easier to come by:  so many visible and demonstrable gaffes and lies  |> have occurred.   A I have definite evidence, which I will not post, that there was a < conspiracy (after the takeover by Compaq, that is).  But theD conspiracy was to attempt to promote Alpha in the face of implacableC opposition to committing the necessary resources from you-know-who.f  3 And, as history now relates, the conspiracy failed.e     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679    ------------------------------  # Date: Fri, 12 Jul 2002 14:00:11 GMT-# From: "John Smith" <a@nonymous.com> $ Subject: Re: Doing the Math on AlphaH Message-ID: <LhBX8.22703$WJf1.9410@news01.bloor.is.net.cable.rogers.com>  2 "Alan Greig" <a.greig@virgin.net> wrote in message2 news:8uatiu01lpae7g7jrhmjahr9n7u0fuo922@4ax.com...6 > On Thu, 11 Jul 2002 19:30:34 GMT, "Terry C. Shannon"! > <terryshannon@attbi.com> wrote:t >vB > As we all know, even if we had professional auditors look at theH > books, it would be difficult to answer these questions with certainty.G > What we can say for certain is that the entire ex-DEC Alpha/VMS/Tru64f@ > group made a lot more money than the PC business. And that theA > Alphacide risks sales losses in the most profitable part of the- > business.e >r; > In other words the knock on effect of the Alphacide riskss= > "opportunity" losses for VMS and Tru64 if I recall my basicgH > accountancy terminology. Not taking this into account fully could be aH > breach of duty to shareholders no matter how well you could argue that! > Alpha itself was a money drain.e    F I have a good friend who runs a successful class-action commercial lawI practice. I must ask him if it is possible for former CPQ shareholders tomH launch a suit against officers/directors of the former CPQ for breach ofA fiduciary responsibility or some other claim. If so, I'm sure the K documentation that would have to be produced would provide most interestingnJ reading. Mind you, there's no law against being terminally stupid, so long as it's not criminal.i  ? If anyone here sells shredders, don't ship any more to Houston.    ------------------------------  % Date: Fri, 12 Jul 2002 09:30:00 -0600e From: Kevin Handy <kth@srv.net>o Subject: Re: DS10 shutting down & Message-ID: <3D2EF5F8.2000206@srv.net>   Carl Perkins wrote:n > E > Have you made certain that someone isn't pressing the halt or powertI > button? That gives you instant system death. They are both conveniently., > located on the front of the box on a DS10. > G > "User stupidity" is not unheard of. Neither is "deliberate sabotage".yG > For that matter, neither is "the cleaning person unplugged it to plug2 > in the vacuum cleaner".p > I > You might check to see if the last timestamps recorded before each bootZG > indicate hatls at about the same time of the day, and check to see ifJ& > it happens on weekends and holidays. > 
 > --- Carl  = Already thought of that, but it occurs at random times, often ; late at night when noone is there, sometimes during the day ? when many people are about.  System is used as a server, nobodya* should be sitting in front of it normally.   ------------------------------  # Date: Fri, 12 Jul 2002 17:12:45 GMTd5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>u Subject: Re: DS10 shutting downe2 Message-ID: <h6EX8.27$%t7.475188@news.cpqcorp.net>  H Not worth losing a job over.  But I don't think Bill uses VMS anyway, he2 just writes about it from some sense of nostalgia.    E Malcolm Dunnett wrote in message <0HYtq7yLyF3j@malvm7.mala.bc.ca.>... - >In article <3D2DCCD8.45A56EA6@videotron.ca>,h3 >   JF Mezei <jfmezei.spamnot@videotron.ca> writes:u >SJ >> I think Bill Todd should be careful whenever he logs into a VMS system, heJ >> might get electrocuted by VMS :-) ( would it be a LIB$ELECTROCUTE_USER, or a >> SYS$ELECTROCUTE_USER ? )  >a@ >   I believe it's actually CIA$TERMINATE_WITH_EXTREME_PREJ  :-) >i   ------------------------------  % Date: Fri, 12 Jul 2002 08:32:43 +0200eC From: Eberhard Heuser-Hofmann <vaxinf@chclu.chemie.uni-konstanz.de>Y" Subject: RE: DVD drives on OpenVMS@ Message-ID: <00A10D07.27B36EFB.428@CHCLU.CHEMIE.UNI-KONSTANZ.DE>   Hi Rick,  K >I've been trying to locate some details on using "PC" style (but SCSI) DVD,I >drives on Alphas running OpenVMS.  I have found a few references to somerG >DVD-R and DVD-RAM drivers, but I am just looking for a reader.  If the1M >DVD drive is a SCSI-2 or UltraSCSI drive compatible with the SCSI controllerpH >in my AlphaServers, will VMS recognize it and allow me to read from it?= >Would it be dependent on the OS version?  Would I need v7.3?w   Here a my expiriences:L 1.) Many IDE-DVD-drives work with OpenVMS. You do not need a special driver,I     because DEQ offers the DQDRIVER on the Freeware-CD. For some machinesf*     it is not possible to boot from a DVD.Q 2.) If you want to connect an IDE-DVD via SCSI get a SCSI-IDE-brigde. You have tosR     use a special driver, that converts the 512 byte read-requests into 2048 blockK     reads. The driver program is freely available thank to Glenn Everhart.  R 3.) If the DVD-drive has a jumper to use 512 byte per I/O OpenVMS should recognizeP     this drive as a "big" CDROM/read-only drive. If this is not the case use theR     driver mentioned in point 2. It seems to the case that booting from a scsi-DVDQ     with a DVD doesn't wrok although booting with a CD with the same drive is OK.   H >Has anyone else hung DVD drives on any Alphas and if so, what models of. >drive, Alpha and SCSI controller did you use?  K Personal Workstation 433/500, Pioneer DVR-103. SCSI-Bridge ACARD AEC-7720U.d  C >This would be a good FAQ entry, if there is a good answer to it!!!   3 Then one should mention my dvd-burner-program, too.u  J >Note, I know there have been some discussions of this in the newsgroup inI >the past, but both archives mentioned in the current FAQ (apparently) nodQ >longer exist. (Google has dropped the archive and crvax.sri.com did not answer.)    try www.dejanews.com   regardso eberhard   ------------------------------    Date: 12 Jul 2002 09:15:12 -0600 From: briggs@encompasserve.org Subject: Re: FTP Hang Question3 Message-ID: <KMOh8AlQ+IWQ@eisner.encompasserve.org>   W In article <sd2d86bd.015@PSUGATE.hmc.psu.edu>, "Scott Brooks" <sbrooks@psu.edu> writes:e	 > Hi All,a > I > In VMS have a COM program running from a batch queue that FTPs to an NTSH > Server running IIS.  Every once in a while the FTP service stops beingJ > available in the middle of the FTP process and the COM program just sitsJ > at the FTP step.  In the batch queue it says it is running, but it neverE > ends until manual intervention is taken. Does anyone know how I can J > prevent this from happening?  (Like trap the error and stop the process, > etc.)s   One brute force technique is:    $! Your command proceduret? $	SPAWN /NOWAIT /NOSYMBOLS /NOLOGICAL_NAMES @WATCHDOG.COM 0:5:0t $	FTP blah blah blah, $	P = F$TRNLNM ( "WATCHDOG_PID", "LNM$JOB" )  $	IF P .NES. "" THEN STOP /ID='P $	EXIT   $! WATCHDOG.COMr. $	DEFINE /JOB WATCHDOG_PID 'F$GETJPI("","PID")
 $	WAIT 'p1* $	! Optionally ring alarms and sound gongsF $	STOP /ID='F$GETJPI("","OWNER")   ! Or try $FORCEX or $ DELETE /ENTRY  + Untested.  But it should at least be close.a   	John Briggs   ------------------------------  % Date: Fri, 12 Jul 2002 13:28:53 -0400r& From: "Scott Brooks" <sbrooks@psu.edu> Subject: Re: FTP Hang Question. Message-ID: <sd2ed99c.058@PSUGATE.hmc.psu.edu>  = Thanks for all your answers and code for my FTP hang problem.n   Much appreciated!e   Scotto   ------------------------------  % Date: Fri, 12 Jul 2002 14:35:38 -0000 - From: wspencer@ap.nospam.org (Warren Spencer)t1 Subject: Re: Intel Wall Street Journal Itanium Adm5 Message-ID: <924961471warrenspencer1977@216.168.3.30>>  2 terryshannon@attbi.com (Terry C. Shannon) wrote in  <XbmS8.1864$Uu2.240@sccrnsc03>:    >b9 >"Richard D. Piccard" <piccard@ohio.edu> wrote in messageh" >news:3D19AC04.B751DA4@ohio.edu... >>H >> The WSJ for Tuesday had a more-than-one-page ad for Itanium (-2, as I >recall) that listedE >> all sorts of software being developed for it, including in the topn >section, markedE >> operating systems, three flavors of Windows, HP-UX, two flavors ofR
 >> Linux,  >but >> >> **** NO LISTING OF VMS **** >>? >> This is perhaps not surprising, but is certainly outrageous.r >1I >Yep. And the NonStop community no doubt is equally miffed by the lack ofcB >mention of NSK on Itanium. Kinda dumb on Intel's part to omit twoE >ENTERPRISE-CLASS operating systems from its list. Unless, of course, G >folks up Redmond way had "input" to the collateral generation process.i >;-} e  J And there may be a reason for that, other that sloppy detail-management.  H Has anyone seen the errata sheet for the I-2 yet?  It might not be good . enough yet for high-availability environments.   ws   -- n   Warren Spencer' Senior Software Engineer (not a writer)C The Associated Press  < ** Time flies like an arrow.  Fruit flies like a bananna. **   ------------------------------    Date: 12 Jul 2002 00:39:29 -0700! From: soterro@yahoo.com (Soterro) / Subject: Re: List the processes using a mailboxb= Message-ID: <d5440555.0207112339.77a9732d@posting.google.com>o  n jbrankin@ntlworld.com (Jim Brankin) wrote in message news:<863f19d6.0207111344.4169db45@posting.google.com>...5 > I don't think so. I usually do something like this n > % > SDA> set out sys$login:channels.tmp  > SDA> sho proc all /channel > SDA> set out sys$outputa   Hello,  = Yes, finally that is what I did and it turned out correctly. kD Too bad there's no direct way to do it, but I don't (hopefully) need; it so often to think about a script to automate the task...h   Thank you all very much,   Sorinc   ------------------------------  % Date: Fri, 12 Jul 2002 09:14:42 +0100 ( From: Nic Clews <sendspamhere@127.0.0.1>5 Subject: Re: Looking for terminal session sharing pgm ( Message-ID: <3D2E8FF2.C3229A8@127.0.0.1>   Ransom Fitch wrote:  > I > Looking for terminal session sharing software to be used in 'help desk'sF > setting.  I had one at one time but am unable to find it in FreewareI > listing (mostly because I've forgotten what it was called, getting' olda# > ya know).  Any ideas appreciated.     E Seen this? It is a package you can buy smaller (and cheaper) lumps of 5 and I believe cheaper than some competing software...i   http://www.advsyscon.com/e   Go to products...a  C Some other interesting VMS offerings as well (like file shadowing).g   -- s? Regards, Nic Clews a.k.a. Mr. CP Charges, CSC Computer Scienceso nclews at csc dot com    ------------------------------  # Date: Fri, 12 Jul 2002 10:44:13 GMT7 From: system@SendSpamHere.ORGo5 Subject: Re: Looking for terminal session sharing pgmm0 Message-ID: <00A10CF7.FF7991F2@SendSpamHere.ORG>  S In article <3D2E8FF2.C3229A8@127.0.0.1>, Nic Clews <sendspamhere@127.0.0.1> writes:) >Ransom Fitch wrote: >> sJ >> Looking for terminal session sharing software to be used in 'help desk'G >> setting.  I had one at one time but am unable to find it in Freeware J >> listing (mostly because I've forgotten what it was called, getting' old$ >> ya know).  Any ideas appreciated. >  >rF >Seen this? It is a package you can buy smaller (and cheaper) lumps of6 >and I believe cheaper than some competing software... >e >http://www.advsyscon.com/ >w >Go to products... > D >Some other interesting VMS offerings as well (like file shadowing).  B Not true.  It's a misnomer.  It's simply a mirroring package whichC mirrors virtual disks.  "file shadowing" is accomplished by placing2B a file in the virtual disk.  It doesn't buy you much; just more K- mode code that can go wrong.   --O VAXman- OpenVMS APE certification number: AAA-0001     VAXman(at)TMESIS(dot)COMJ            @5   "Well my son, life is like a beanstalk, isn't it?" 4   ------------------------------  % Date: Fri, 12 Jul 2002 10:04:44 -0400/! From: Jim Agnew <jpagnew@vcu.edu>65 Subject: Re: Looking for terminal session sharing pgm ' Message-ID: <3D2EE1FC.88E907C4@vcu.edu>m  G Wasn't there a freeware somewhere for this??  It's waaay out on the rim-+ of my mind, lost in the empty spaces... ;-)o   Jim, the good-humored...   Ransom Fitch wrote:s > I > Looking for terminal session sharing software to be used in 'help desk'sF > setting.  I had one at one time but am unable to find it in FreewareI > listing (mostly because I've forgotten what it was called, getting' oldm# > ya know).  Any ideas appreciated.r > 	 > Thanks,g > Ransom Fitch   ------------------------------  % Date: Fri, 12 Jul 2002 16:16:08 +0200 9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>l5 Subject: Re: Looking for terminal session sharing pgm ' Message-ID: <3D2EE4A8.F9C9345C@aaa.com>e  2 On "http://vms.process.com/fileserv-software.html" I found the following :D  B JOBLOG     Record terminal output, w/ secure mode (uses FTDRIVER) @ LASTCMD    Peek at terminal typeahead buffer (get last command) A LOGGER     Log terminal sessions using FT pseudo-terminal driver  : SUPERVISOR Supervisor Series terminal monitoring software ? TERMINALS  Create terminal statistics reports and usage tables R  ( Perhaps any of those suites your needs ?   Jan-Erik Sderholm.u     Jim Agnew wrote: > I > Wasn't there a freeware somewhere for this??  It's waaay out on the rimo- > of my mind, lost in the empty spaces... ;-)t >  > Jim, the good-humored...   ------------------------------  % Date: Fri, 12 Jul 2002 10:33:39 -0400l! From: Jim Agnew <jpagnew@vcu.edu>e5 Subject: Re: Looking for terminal session sharing pgmv' Message-ID: <3D2EE8C3.7552EF19@vcu.edu>b  D Jan's "long-range sensors" jogged my mind for supervisor... that wasB what I was trying to find in the dusty corners of my mind for this@ person.  we use CONTRL, from raxco... it's pretty good, and also; controls decneted, telnet, etc as well as physical logins..    Jimo   Jan-Erik Sderholm wrote:a > 4 > On "http://vms.process.com/fileserv-software.html" > I found the following :n > C > JOBLOG     Record terminal output, w/ secure mode (uses FTDRIVER)nA > LASTCMD    Peek at terminal typeahead buffer (get last command)dB > LOGGER     Log terminal sessions using FT pseudo-terminal driver; > SUPERVISOR Supervisor Series terminal monitoring softwarep@ > TERMINALS  Create terminal statistics reports and usage tables > * > Perhaps any of those suites your needs ? >  > Jan-Erik Sderholm.  >  > Jim Agnew wrote: > >rK > > Wasn't there a freeware somewhere for this??  It's waaay out on the rimd/ > > of my mind, lost in the empty spaces... ;-)o > >d > > Jim, the good-humored...   ------------------------------  % Date: Fri, 12 Jul 2002 15:33:45 +0100a% From: Alan Greig <a.greig@virgin.net>a5 Subject: Re: Looking for terminal session sharing pgml8 Message-ID: <a5qtiu4a381cbu8t5h8c5c5vhk4jn8cfr1@4ax.com>  F On Fri, 12 Jul 2002 10:04:44 -0400, Jim Agnew <jpagnew@vcu.edu> wrote:  H >Wasn't there a freeware somewhere for this??  It's waaay out on the rim, >of my mind, lost in the empty spaces... ;-)  ? There certainly was for VAX. I don't think anyone ever ported a / freeware version to Alpha but I could be wrong.u   >Jim, the good-humored...d >b >Ransom Fitch wrote: >> eJ >> Looking for terminal session sharing software to be used in 'help desk'G >> setting.  I had one at one time but am unable to find it in FreewarexJ >> listing (mostly because I've forgotten what it was called, getting' old$ >> ya know).  Any ideas appreciated. >> o
 >> Thanks, >> Ransom Fitch    -- Alan   ------------------------------  % Date: Fri, 12 Jul 2002 16:52:50 +0200o9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>m5 Subject: Re: Looking for terminal session sharing pgmr' Message-ID: <3D2EED42.45644AF1@aaa.com>r  = Hm, it wasn't *that* long-range, Hunters archive is the firsty/ place I look when searching for VMS freeware...   	 Jan-Erik.    Jim Agnew wrote: > F > Jan's "long-range sensors" jogged my mind for supervisor... that wasD > what I was trying to find in the dusty corners of my mind for this	 > person.y   ------------------------------  % Date: Fri, 12 Jul 2002 11:12:25 -0400a1 From: Michael Austin <maustin@firstdbasource.com> 5 Subject: Re: Looking for terminal session sharing pgma2 Message-ID: <3D2EF1D9.60134E71@firstdbasource.com>   Jan-Erik Sderholm wrote:s > 4 > On "http://vms.process.com/fileserv-software.html" > I found the following :t > C > JOBLOG     Record terminal output, w/ secure mode (uses FTDRIVER)eA > LASTCMD    Peek at terminal typeahead buffer (get last command)rB > LOGGER     Log terminal sessions using FT pseudo-terminal driver; > SUPERVISOR Supervisor Series terminal monitoring software.@ > TERMINALS  Create terminal statistics reports and usage tables > * > Perhaps any of those suites your needs ? >  > Jan-Erik Sderholm.@ >  > Jim Agnew wrote: > >DK > > Wasn't there a freeware somewhere for this??  It's waaay out on the rimt/ > > of my mind, lost in the empty spaces... ;-)n > >  > > Jim, the good-humored...  G I have used Supervisor - very effective when you are 100 miles from the H site and can connect to the uses session and watch as they re-create theF error.  And if you need too, you can also actually type stuff in theirG session. Be careful with any product like this as it can, and has been,  abused.i -- t Regards,  6 Michael Austin            OpenVMS User since June 19847 First DBA Source, Inc.    Registered Linux User #261163a7 Sr. Consultant            http://www.firstdbasource.comsE                           http://www.firstdbasource.com/donation.html / 704-947-1089 (Office)     704-236-4377 (Mobile)l   ------------------------------  % Date: Fri, 12 Jul 2002 11:15:26 -0400o! From: Jim Agnew <jpagnew@vcu.edu>h5 Subject: Re: Looking for terminal session sharing pgm ' Message-ID: <3D2EF28E.5ABAC9C1@vcu.edu>g  G Yes, the only time I ever saw Contrl abused was when my boss and I wereuG contrling one of our helpers.. He missed the splash screen and the beepiD (don't ask how...we never could figure out that one), and so we keptD VAXPhoning him, and watched him keep mispelling it, and we'd "cause"E some errors ourselves..  then right when we saw him get it right, andd hit return, we'd hang up..    F we kept it up for 10 minutes...   watching all the mispelling...  poor= guy was really ticked off...  we were rolling on the floor...-  H Of course, this was a special occasion...  the guy we were abusing was a "good ole boy"...s but then, so were we...1     Michael Austin wrote:D >  > Jan-Erik Sderholm wrote:a > >r6 > > On "http://vms.process.com/fileserv-software.html" > > I found the following :e > > E > > JOBLOG     Record terminal output, w/ secure mode (uses FTDRIVER).C > > LASTCMD    Peek at terminal typeahead buffer (get last command)"D > > LOGGER     Log terminal sessions using FT pseudo-terminal driver= > > SUPERVISOR Supervisor Series terminal monitoring softwarenB > > TERMINALS  Create terminal statistics reports and usage tables > >p, > > Perhaps any of those suites your needs ? > >b > > Jan-Erik Sderholm.d > >n > > Jim Agnew wrote: > > >eM > > > Wasn't there a freeware somewhere for this??  It's waaay out on the rim 1 > > > of my mind, lost in the empty spaces... ;-)n > > >  > > > Jim, the good-humored... > I > I have used Supervisor - very effective when you are 100 miles from theiJ > site and can connect to the uses session and watch as they re-create theH > error.  And if you need too, you can also actually type stuff in theirI > session. Be careful with any product like this as it can, and has been,1	 > abused.c > --
 > Regards, > 8 > Michael Austin            OpenVMS User since June 19849 > First DBA Source, Inc.    Registered Linux User #261163 9 > Sr. Consultant            http://www.firstdbasource.comaG >                           http://www.firstdbasource.com/donation.htmli1 > 704-947-1089 (Office)     704-236-4377 (Mobile)t   ------------------------------  % Date: Fri, 12 Jul 2002 11:16:03 -0400>! From: Jim Agnew <jpagnew@vcu.edu>(5 Subject: Re: Looking for terminal session sharing pgmT' Message-ID: <3D2EF2B3.9A450533@vcu.edu>a   Yup..  $   Jan-Erik Sderholm wrote:: > ? > Hm, it wasn't *that* long-range, Hunters archive is the first:1 > place I look when searching for VMS freeware...@ >  > Jan-Erik.k >  > Jim Agnew wrote: > >DH > > Jan's "long-range sensors" jogged my mind for supervisor... that wasF > > what I was trying to find in the dusty corners of my mind for this > > person.e   ------------------------------  % Date: Fri, 12 Jul 2002 12:25:25 -0400f; From: "Brian Tillman" <tillman_brian@notnoone.notnohow.com>o5 Subject: Re: Looking for terminal session sharing pgm $ Message-ID: <3d2f0328$1@news.si.com>  H >Looking for terminal session sharing software to be used in 'help desk'	 >setting.?  G Peek & Spy is a product from Networking Dynamics Corp that can do this.m www.networkingdynamics.com . --A Brian Tillman                   Internet: tillman_brian at si.comaA Smiths Aerospace                          tillman at swdev.si.com = 3290 Patterson Ave. SE, MS      Addresses modified to preventc< Grand Rapids, MI 49512-1991     SPAM.  Replace "at" with "@"8        This opinion doesn't represent that of my company   ------------------------------    Date: 12 Jul 2002 16:53:09 +1000) From: raob@news.unimelb.edu.au (r.oxbrow)t Subject: Re: McKinley Cometh...53 Message-ID: <aglucl$3ju$1@ariel.ucs.unimelb.edu.au>i  L   NEC Japan have announced their Itanium 2 server boxes, TX7 a few days ago,  - 	http://www.nec.co.jp/press/ja/0207/0901.htmlb  O   They scale between 8-32 CPUs, 16GB-128GB of ram, running  linux or HP-UX 11i.   E   They have  Linpack HPC benchmark of 101 GFlops for a full 32 cpus..a&   Shipping date Aug 2002 for 32CPUs..   	   richardr  3 In article <l7QyKqsM+Aw$@eisner.encompasserve.org>,n, Rob Young <young_r@encompasserve.org> wrote:T >In article <3D2D8E15.35DFD3D4@kgcc.co.uk>, Ken Green <Ken.Green@kgcc.co.uk> writes: >e >>  B >> AFAIK HP isn't making any public comittments as to when I2 willH >> be available in larger boxes, so I can't comment on bigger than 4 way	 >> boxes.  >> n >A2 >http://www.theregister.co.uk/content/3/26097.html >tG >Mark Hudson, worldwide marketing manager for HP's Business Systems and N >Technology Organization, says that the Pinnacles chipset will scale from 8 toH >64 processors and that it will debut with the Madison Itanium chip, dueF >sometime in 2003. Eventually, the Pinnacles chipset will scale to 128P >processors, says Hudson, but it is unclear if that will happen when Intel cramsO >more Itanium cores on a single chip or if HP will expand the SMP functionalitySP >of the Pinnacles chipset to literally support 128 distinct Itanium processors.  >l >				Rob >l     -- FF 	    U n i v e r s i t y  o f  M e l b o u r n e  -  A u s t r a l i a   ------------------------------  % Date: Fri, 12 Jul 2002 09:03:44 +0100i& From: Ken Green <Ken.Green@kgcc.co.uk> Subject: Re: McKinley Cometh... * Message-ID: <3D2E8D60.171CD93E@kgcc.co.uk>   Anil T Maliyekke wrote:   6 > In comp.arch Ken Green <Ken.Green@kgcc.co.uk> wrote: > F > > I believe theres quite a difference between the Power4 SPEC scoresC > > when they're configured with 64MB of L3 cache instead of 128MB.O >I
 > POWER4 SPEC B > system     GHz  ratio  L3 cache  int peak  ratio  fp peak  ratioA > 1-way p690 1.3  1.3    128MB     839       1.31   1266     1.41$7 > 1-way p630 1.0         64MB      637              896  >nD > There is really no differance for 64MB vs 128MB of external cache.C > The additional performance boost for the SPECfp200  could be fromm/ > the cache or the additional memory bandwidth.F >H > Anil  0 Sorry I stand corrected, I hadn't done the sums.   Cheers   Kenl   ------------------------------   Date: 12 Jul 2002 08:23:51 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: McKinley Cometh...:0 Message-ID: <agm3mn$n00$1@pegasus.csx.cam.ac.uk>  3 In article <aglucl$3ju$1@ariel.ucs.unimelb.edu.au>,i* r.oxbrow <raob@news.unimelb.edu.au> wrote: >@M >  NEC Japan have announced their Itanium 2 server boxes, TX7 a few days ago,6 >u. >	http://www.nec.co.jp/press/ja/0207/0901.html >cP >  They scale between 8-32 CPUs, 16GB-128GB of ram, running  linux or HP-UX 11i. >fF >  They have  Linpack HPC benchmark of 101 GFlops for a full 32 cpus..' >  Shipping date Aug 2002 for 32CPUs.. g  @ I'll take your word for it - my Japanese is only slightly better than my Mayan :-)   C If that date is real, it is just possible that NEC could be selling*H 32-CPU boxes in Japan before anyone is selling 2-CPU ones in the UK ....? My colleage had the patience to get through HP's e-commerce Webt= page and found that the delivery dates were to be determined! ! And that is the USA availability.t     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679p   ------------------------------  % Date: Fri, 12 Jul 2002 08:47:29 -0400I# From: "Dan Allen" <dallen@nist.gov>h Subject: RE: McKinley Cometh... : Message-ID: <OPEPIPEJGHNICIJKJFEAAEIHEOAA.dallen@nist.gov>   	Ah yes, 60's overlays ;-)   > -----Original Message-----1 > From: Bill Todd [mailto:billtodd@metrocast.net]-' > Sent: Thursday, July 11, 2002 4:43 PM3 > To: Info-VAX@Mvb.Saic.Como! > Subject: Re: McKinley Cometh...  >  >  > 6 > "Alex Colvin" <alexc@world.std.com> wrote in message" > news:Gz3EFD.H3n@world.std.com...E > > >Akk, you don't need a 64 bit processor to support more than 4 GB4G > > >of memory, trust me on this one or alternatively look at a sequenti > > >brochure. > > A > > sure, you can go with TINY/COMPACT/MEDIUM/HUGE memory models.  > > but it's no way to live. > N > Nor is there any need to live that way (nor am I even sure that the hardwareM > *allows* you to live that way:  while segmentation can IIRC be used, it maykC > still limit your segments to a single 32-bit-wide address space).  > N > If you want to make use of > 4 GB of memory by multiple applications, but noN > single application needs access to more than 2 GB (or 3 GB if it's using theH > 3GB app/1GB system Windows server setup; don't know how flexibly LinuxK > splits up the address space), then it all just works transparently to the I > applications.  Whether Windows supports over-sized system cache in such H > cases I don't know, but there's certainly no reason why it couldn't if@ > someone made the effort (though if other system hardware isn'tK > 36-bit-physical-address-aware the system would need to copy data into anda@ > out of such 'high memory' when, e.g., moving it from/to disk). > N > Or if one or more individual applications want access to more than 2 or 3 GBE > of physical memory for data storage (since having more than 2 GB oftG > executing code is, I would hope, a rare occurrence), they can use the L > Windows or Linux address windowing extensions to map (not copy) the largerM > memory as required into virtual address ranges within their normal 2 GB - 3SD > GB address space.  While the overhead of this mapping might becomeK > noticeable for, say, random access within very large arrays, using it forrM > something like an expanded database cache (where once you get a page you dodN > at least some actual work with it before needing another) makes the overheadH > negligible, and the managing of such a cache adds very little relative8 > complexity to that of managing a cache in flat memory. >  > - bill >  >  >  >    ------------------------------  % Date: Thu, 11 Jul 2002 16:45:24 -0700/, From: "Chris Ruemmler" <ruemmler@cup.hp.com> Subject: Re: McKinley Cometh...e, Message-ID: <agl5fd$ost$1@hplms2.hpl.hp.com>  3 "Ken Green" <Ken.Green@kgcc.co.uk> wrote in messagew$ news:3D2DD1B0.E9A48EA5@kgcc.co.uk... > Alex Colvin wrote: >bK > > >>         Exactly.  You can cook a benchmark to make an UltraSparc III- lookD > > >>         fast too, i.e. art.  Hats off to their compiler team. > >AF > > >But definitelt hats off to the compiler guys. Since the benchmark result stillJ > > >stands I assume none of the competitor have shown the optomisation toK > > >be art specific. Also no one else seems to have managed to pull of theg same > > >trick yet.h > > ? > > any information or unsupported rumors on what the trick is?f > >r >o@ > They managed to invert a nested pair of loops that no one else< > has, I believe. The art benchmark forces memory access the> > wrong way round, so that it trashes the cache and TLB, Sun'sA > compiler guys have found a way of putting it into the order the > > CPU finds easy, this is usually easy for a programmer to do,= > but hard for a compiler to tell whether the change is safe.A >iC Actually, you don't quite have your information correct.  What they-D did was to rearrange the allocated memory such that the hot loops inH the code walk down memory very efficiently.  This greatly improves cacheC reuse and makes much better use of the bandwidth between the L2 andeG L1 caches (art's working set will fit in an 8MB cache).  In particular,w7 there is the following structure and definition in art:d   typedef struct {         double *I;         double W;u         double X;a         double V;g         double U;u         double P;i         double Q;V         double R;i                 } f1_neuron;   f1_neuron *f1_layer;  ; The "f1_layer" variable is created via a large malloc call.t> Each "I" element is created with a call to malloc that creates; two doubles (so it creates a two element array of doubles).t< The resulting array of f1_neuron structures is then accessed in several loops such as:g          cp = 0;         for (ti=0;ti<numf1s;ti++)       {,C           f1_layer[ti].W = f1_layer[ti].I[cp] + a*(f1_layer[ti].U);j3           tnorm += f1_layer[ti].W * f1_layer[ti].W;e       }   > Notice that in this loop, only a few of the structure elements8 are accessed (namely W, I, and U).  In other loops other< different structure elements are accessed.  The way the codeA is written, these loops can't be combined together.  The "numf1s", value is very large.  = What Sun did was to rearrange the way the array of structures B was allocated.  Instead of allocating it as specified in the code,1 they allocated it as though the code looked like:,   double *f1_layer_I0; double *f1_layer_I1; double *f1_layer_W;e double *f1_layer_X;t double *f1_layer_V;  double *f1_layer_U;o double *f1_layer_P;r double *f1_layer_Q;V double *f1_layer_R;s  9 They then created these arrays in contiguous storage suchs2 as would be done if the following were in the code  <        f1_layer_W = (double *)malloc(sizeof(double)*numf1s);  8 for each of these double arrays.  So, now when the above2 loop is optimized it looks like it was written as:  
        cp= 0;h         for (ti=0;ti<numf1s;ti++)       {g@           f1_layer_W[ti] = f1_layer_I0[ti] + a*(f1_layer_U[ti]);3           tnorm += f1_layer_W[ti] * f1_layer_W[ti];i       }a  9 So, now they are walking down arrays of doubles and usings= each cache line fully vs the original allocation where only a : few doubles out of each cacheline were used.  This greatly; helps with cache-reuse.  In order to create the "I" portiona= which was a mini array in each structure, they had to perform : another optimization that coalesced malloc calls together.  < Given they completely rearranged the "normal" representation< of memory as one would expect it in C, they can only do this@ optimization if several conditions hold.  The list of conditions include things like:  =       1).  No pointer math can be done on the variables beinggH             modified.  This includes taking the address of the variable.B             So in the above examples, you can't do something like:3                    fscanf(fp,"%lf",&f1_layer[0].W);rC       2).  The variable modified has to be declared as a global andhJ              has to be allocated directly via a call to malloc/calloc.  It can't beK              a large statically declared array or allocated via an indirecta callF              to malloc such as would be done if error code was wrapped?              around the malloc call in a personalized function.eG       3).  You can't pass the variable as a parameter to a function, itd/              must only be accessed as a global.-G       4).  You can't alias the global (ie assign the pointer to a localr pointer)B       5).  You can't call "free" to deallocate the memory that was1              allocated via malloc for the object.0@       6).  User level shared libraries can't be used, only Sun's*              shared libraries can be used.K       7).  The program can't dynamically load any library (ie call dlopen). @       8).  The -xipo=2 compiler option must be used on all filesG              linked to create the program, including archive libraries.FG              The -xipo=2 option does all compilation at the link phase.i  H I think I specified all of the current restrictions, there might be someH more.  If the code does not meet the restrictions, then the Sun compilerC does not do the optimizations as done in art.  So, if you have codehG that can meet these restrictions (such as art) and can benefit from them	 structure.; splitting, you may be set if you go with the Sun compilers.e   >r= > I'm sure sooner or later other compiler writers will managen> > the trick and everyone elses SPECfp figures will take a leap- > skyward. Until then Sun wins at that trick.y >p5 It depends.  If the other vendors have overall SPECfpl> scores that are much larger than Sun without the optimization,: then the ROI might not be enough to implement it.  This is= especially true for this optimization given all of the issuesl= that need to be handled to implement it safely for all codes.    --Christ My own views   ------------------------------  + Date: Fri, 12 Jul 2002 12:58:26 +0000 (UTC) / From: mccalpin@gmp246.austin.ibm.com (McCalpin)u Subject: Re: McKinley Cometh... 1 Message-ID: <agmjpi$hik$1@ausnews.austin.ibm.com>t  + In article <agl51r$rgs$1@newsx.cc.uic.edu>,F4 Anil T Maliyekke  <amaliy1@icarus.cc.uic.edu> wrote:5 >In comp.arch Ken Green <Ken.Green@kgcc.co.uk> wrote:  > E >> I believe theres quite a difference between the Power4 SPEC scoreshB >> when they're configured with 64MB of L3 cache instead of 128MB. >m
 >POWER4 SPEC iA >system     GHz  ratio  L3 cache  int peak  ratio  fp peak  ratioe@ >1-way p690 1.3  1.3    128MB     839       1.31   1266     1.416 >1-way p630 1.0         64MB      637              896 >eC >There is really no differance for 64MB vs 128MB of external cache.nB >The additional performance boost for the SPECfp200  could be from. >the cache or the additional memory bandwidth.  ; I am pretty confident that the IBM web site lists incorrectk> system configuration information for the p630 -- the p630 SPEC? CPU2000 runs were done on a system with 32 MB L3 (one processor  card).  ? The performance situation is not so clear as the above implies,P: since both the p690 and p630 run a portion of their memory> subsystems at the fixed speed of 400 MHz.  This means that the@ p630 suffers somewhat less relative latency than the p690 (about? 12% less, if I did the arithmetic correctly).  This p630 config A only uses the L3 connected directly to the processor chip runningr; the benchmark, so the relative L3 latency is lower as well.n  ? So the "SPECfp2000/MHz" on the p630 is decreased by the reduced A amount of L3 cache, but increased by the lower relative latencies   of the L3 and the memory system.  ? Of course, as in all SPEC comparisons, it is important to checkh< to see if the compilers and flags were identical across the  two runs to be compared....n -- y9 John D. McCalpin, Ph.D.           mccalpin@austin.ibm.comeF Senior Technical Staff Member     IBM POWER Microprocessor Development-     "I am willing to make mistakes as long ast1      someone else is willing to learn from them."    ------------------------------  % Date: Fri, 12 Jul 2002 15:03:15 +0100 & From: Ken Green <Ken.Green@kgcc.co.uk> Subject: Re: McKinley Cometh...w* Message-ID: <3D2EE1A2.A7C2F537@kgcc.co.uk>   Chris Ruemmler wrote:3  5 > "Ken Green" <Ken.Green@kgcc.co.uk> wrote in messagee& > news:3D2DD1B0.E9A48EA5@kgcc.co.uk... > > Alex Colvin wrote: > >(M > > > >>         Exactly.  You can cook a benchmark to make an UltraSparc III. > lookF > > > >>         fast too, i.e. art.  Hats off to their compiler team. > > >*H > > > >But definitelt hats off to the compiler guys. Since the benchmark > result stillL > > > >stands I assume none of the competitor have shown the optomisation toM > > > >be art specific. Also no one else seems to have managed to pull of the  > same > > > >trick yet.m > > > A > > > any information or unsupported rumors on what the trick is?1 > > >0 > >:B > > They managed to invert a nested pair of loops that no one else> > > has, I believe. The art benchmark forces memory access the@ > > wrong way round, so that it trashes the cache and TLB, Sun'sC > > compiler guys have found a way of putting it into the order theS@ > > CPU finds easy, this is usually easy for a programmer to do,? > > but hard for a compiler to tell whether the change is safe.  > >nE > Actually, you don't quite have your information correct.  What they F > did was to rearrange the allocated memory such that the hot loops inJ > the code walk down memory very efficiently.  This greatly improves cacheE > reuse and makes much better use of the bandwidth between the L2 and-I > L1 caches (art's working set will fit in an 8MB cache).  In particular,.9 > there is the following structure and definition in art:5 >e > typedef struct { >         double *I; >         double W;a >         double X;r >         double V;e >         double U;, >         double P;o >         double Q;1 >         double R;e >                 } f1_neuron; >a > f1_neuron *f1_layer; >1= > The "f1_layer" variable is created via a large malloc call.f@ > Each "I" element is created with a call to malloc that creates= > two doubles (so it creates a two element array of doubles). > > The resulting array of f1_neuron structures is then accessed > in several loops such as:e >K >        cp = 0;" >        for (ti=0;ti<numf1s;ti++)	 >       {aE >           f1_layer[ti].W = f1_layer[ti].I[cp] + a*(f1_layer[ti].U);e5 >           tnorm += f1_layer[ti].W * f1_layer[ti].W; 	 >       }h >:@ > Notice that in this loop, only a few of the structure elements: > are accessed (namely W, I, and U).  In other loops other> > different structure elements are accessed.  The way the codeC > is written, these loops can't be combined together.  The "numf1s"I > value is very large. > ? > What Sun did was to rearrange the way the array of structuresoD > was allocated.  Instead of allocating it as specified in the code,3 > they allocated it as though the code looked like:  >l > double *f1_layer_I0; > double *f1_layer_I1; > double *f1_layer_W;s > double *f1_layer_X;n > double *f1_layer_V;	 > double *f1_layer_U;  > double *f1_layer_P;  > double *f1_layer_Q;  > double *f1_layer_R;  >-; > They then created these arrays in contiguous storage such 4 > as would be done if the following were in the code >R> >        f1_layer_W = (double *)malloc(sizeof(double)*numf1s); > : > for each of these double arrays.  So, now when the above4 > loop is optimized it looks like it was written as: >a >        cp= 0;e" >        for (ti=0;ti<numf1s;ti++)	 >       {iB >           f1_layer_W[ti] = f1_layer_I0[ti] + a*(f1_layer_U[ti]);5 >           tnorm += f1_layer_W[ti] * f1_layer_W[ti];p	 >       }  >-; > So, now they are walking down arrays of doubles and using$? > each cache line fully vs the original allocation where only a < > few doubles out of each cacheline were used.  This greatly= > helps with cache-reuse.  In order to create the "I" portionl? > which was a mini array in each structure, they had to perform < > another optimization that coalesced malloc calls together. >e> > Given they completely rearranged the "normal" representation> > of memory as one would expect it in C, they can only do thisB > optimization if several conditions hold.  The list of conditions > include things like: >u? >       1).  No pointer math can be done on the variables being.J >             modified.  This includes taking the address of the variable.D >             So in the above examples, you can't do something like:5 >                    fscanf(fp,"%lf",&f1_layer[0].W);fE >       2).  The variable modified has to be declared as a global andmL >              has to be allocated directly via a call to malloc/calloc.  It
 > can't beM >              a large statically declared array or allocated via an indirect  > callH >              to malloc such as would be done if error code was wrappedA >              around the malloc call in a personalized function.cI >       3).  You can't pass the variable as a parameter to a function, itd1 >              must only be accessed as a global.nI >       4).  You can't alias the global (ie assign the pointer to a localo
 > pointer)D >       5).  You can't call "free" to deallocate the memory that was3 >              allocated via malloc for the object. B >       6).  User level shared libraries can't be used, only Sun's, >              shared libraries can be used.M >       7).  The program can't dynamically load any library (ie call dlopen). B >       8).  The -xipo=2 compiler option must be used on all filesI >              linked to create the program, including archive libraries.dI >              The -xipo=2 option does all compilation at the link phase.M >SJ > I think I specified all of the current restrictions, there might be someJ > more.  If the code does not meet the restrictions, then the Sun compilerE > does not do the optimizations as done in art.  So, if you have code I > that can meet these restrictions (such as art) and can benefit from the  > structure = > splitting, you may be set if you go with the Sun compilers.o >s > > ? > > I'm sure sooner or later other compiler writers will manageh@ > > the trick and everyone elses SPECfp figures will take a leap/ > > skyward. Until then Sun wins at that trick., > >a7 > It depends.  If the other vendors have overall SPECfpd@ > scores that are much larger than Sun without the optimization,< > then the ROI might not be enough to implement it.  This is? > especially true for this optimization given all of the issues ? > that need to be handled to implement it safely for all codes.i >u	 > --Chriss > My own views   Thanks for that Chris,G I'd obviously misunderstood some of the earlier posting in the origenal ( thread that discussed the Sun art score.  @ I'd thought the issue essentially boiled down to the old fortran       do 10, i=1,1024s        do 10, j=1,1024 10        a(i,j) = ....w  D issue, and that they'd found a more general way of moving to a(j,i).   Thanks for the details     Cheers   Ken    ------------------------------  & Date: 12 Jul 2002 15:38:11 +0100 (BST)4 From: Thomas Womack <twomack@chiark.greenend.org.uk> Subject: Re: McKinley Cometh...n3 Message-ID: <3Zh*0P7sp@news.chiark.greenend.org.uk>   , In article <agl5fd$ost$1@hplms2.hpl.hp.com>,+ Chris Ruemmler <ruemmler@cup.hp.com> wrote:o  D >Actually, you don't quite have your information correct.  What theyE >did was to rearrange the allocated memory such that the hot loops in , >the code walk down memory very efficiently.   [lots of details snipped]r  2 That's lovely! I really *do* raise my hat to them.  B This is the same as the array-of-structures vs structure-of-arraysB issue for vectorisation on the P4, which means I *would* expect atC least Intel to get round to implementing it eventually; it's fairlya> widely applicable in 3D graphics, for instance (ah, unless the0 graphics card wants to be given a pointer to theA array-of-structures). And, whilst it's user-visible, I can see it>E being useful enough that a specialist compiler (say VectorC for PSX2)lE might have it as a "for twice the FPS, who cares about the standard!"3 option.9   Tomk   ------------------------------  % Date: Fri, 12 Jul 2002 11:55:23 -0400o- From: JF Mezei <jfmezei.spamnot@videotron.ca>  Subject: Re: McKinley Cometh...., Message-ID: <3D2EFBEA.D4A407DA@videotron.ca>   Nick Maclaren wrote:E > If that date is real, it is just possible that NEC could be selling J > 32-CPU boxes in Japan before anyone is selling 2-CPU ones in the UK ....  K It is possible that HP doesn't want to commit to dates yet because they arekJ not 100% confident that all bugs have ben worked out , whereas NEC is lessI committed to quality and will ship whatever it has on the promised date ?l   ------------------------------   Date: 12 Jul 2002 16:05:05 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: McKinley Cometh...y0 Message-ID: <agmunh$hhj$1@pegasus.csx.cam.ac.uk>  \ In article <3D2EFBEA.D4A407DA@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: |> Nick Maclaren wrote:iH |> > If that date is real, it is just possible that NEC could be sellingM |> > 32-CPU boxes in Japan before anyone is selling 2-CPU ones in the UK ....  |> oN |> It is possible that HP doesn't want to commit to dates yet because they areM |> not 100% confident that all bugs have ben worked out , whereas NEC is lessiL |> committed to quality and will ship whatever it has on the promised date ?  @ It is possible.  It is not likely, given the corporate attitudesB of the companies concerned.  I suspect that the restricted release@ was a condition imposed by Intel in return for its permission to< launch (and hence scrap the NDA requirement).  Remember that@ Intel's own chipset is scheduled for September, and Intel is not6 reknowned for letting OEMs ship boards before it does.  > I suspect that HP and NEC had to threaten Intel pretty hard to get permission to launch.f     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679r   ------------------------------    Date: 12 Jul 2002 09:07:54 -0700$ From: lindahl@pbm.com (Greg Lindahl) Subject: Re: McKinley Cometh...,& Message-ID: <3d2efeda$1@news.meer.net>  3 In article <3Zh*0P7sp@news.chiark.greenend.org.uk>,s6 Thomas Womack  <twomack@chiark.greenend.org.uk> wrote:  C >This is the same as the array-of-structures vs structure-of-arrays C >issue for vectorisation on the P4, which means I *would* expect at D >least Intel to get round to implementing it eventually; it's fairly? >widely applicable in 3D graphics, for instance (ah, unless they1 >graphics card wants to be given a pointer to the  >array-of-structures).  E Given the enormous number of restrictions, "fairly widely applicable"eC isn't true: the odds of a user program triggering this optimizationiC without the programmer intentionally aiming at it is zero. It's thelC kind of thing that anyone with a clue would rewrite the source for,o= which is one of McCalpin's complaints about the SPEC process.n   greg   ------------------------------  & Date: 12 Jul 2002 17:22:35 +0100 (BST)4 From: Thomas Womack <twomack@chiark.greenend.org.uk> Subject: Re: McKinley Cometh...13 Message-ID: <BXx*sc8sp@news.chiark.greenend.org.uk>d  L In article <3d2efeda$1@news.meer.net>, Greg Lindahl <lindahl@pbm.com> wrote:4 >In article <3Zh*0P7sp@news.chiark.greenend.org.uk>,7 >Thomas Womack  <twomack@chiark.greenend.org.uk> wrote:   E >> This is the same as the array-of-structures vs structure-of-arraysyE >> issue for vectorisation on the P4, which means I *would* expect attF >> least Intel to get round to implementing it eventually; it's fairlyA >> widely applicable in 3D graphics, for instance (ah, unless thea= >> graphics card wants to be given a pointer to the array-of-d >> structures).   F >Given the enormous number of restrictions, "fairly widely applicable"D >isn't true: the odds of a user program triggering this optimization; >without the programmer intentionally aiming at it is zero.   A But, if it's there, I'd be rather tempted to aim at it; arrays ofvD structures feel *much* more natural objects to me than structures of= arrays. I wonder if the C++ vector<> could be convinced to do'C something similar; it looks to me as if its interface doesn't imply F that it doesn't repack structures internally. I think it would have toD be done on the compiler level rather than in an implementation as .h files.  B > It's the kind of thing that anyone with a clue would rewrite theB > source for, which is one of McCalpin's complaints about the SPEC
 > process.  D Certainly that would be true for really large-scale simulations; butA it seems the sort of rewrite which would uglify the source a fair F amount, so not something you'd do in a university-like "let's see what+ we can simulate interestingly" environment.   E Or would it be an automatic optimisation if I were writing Fortran95?c   > greg   ------------------------------    Date: 12 Jul 2002 09:30:21 -0700$ From: lindahl@pbm.com (Greg Lindahl) Subject: Re: McKinley Cometh...i& Message-ID: <3d2f041d$1@news.meer.net>  3 In article <BXx*sc8sp@news.chiark.greenend.org.uk>,p6 Thomas Womack  <twomack@chiark.greenend.org.uk> wrote:  G >>Given the enormous number of restrictions, "fairly widely applicable"nE >>isn't true: the odds of a user program triggering this optimization < >>without the programmer intentionally aiming at it is zero. > B >But, if it's there, I'd be rather tempted to aim at it; arrays ofE >structures feel *much* more natural objects to me than structures ofo >arrays.  C If you don't care about portable performance, then you get what you F deserve; writing to a weird idiom also makes your code unmaintainable,F because you change the slightest thing and the optimization goes away.  F >Or would it be an automatic optimisation if I were writing Fortran95?  = Fortran now has the same problem that C does. This particulartD situation is my favorite question for speakers who like to extol howF pretty arrays of structures are compared to a few arrays: I don't find? the former prettier, and the performance hit can be substantial D (depending on the context). But then again, that's what happens when9 you mix computational scientists and computer scientists.    greg   ------------------------------  # Date: Fri, 12 Jul 2002 17:08:16 GMT.5 From: "Fred Kleinsorge" <kleinsorge@star.zko.dec.com>k Subject: Re: McKinley Cometh...e2 Message-ID: <42EX8.26$Gt7.453649@news.cpqcorp.net>  = JF Mezei wrote in message <3D2CBDAF.C0490C36@videotron.ca>...d > J >Lets assume that Capellas decided at the time Windows was killed on Alpha thatK >Alpha would be ditched as soon as IA64 was capable of taking over. At that1H >time, how come he didn't kill off the EV8 team right way and decided toG >continue to keep and fund them ?  Handing the EV8 team to Intel sooner  woulda9 >have helped Intel with the introduction of its new chip.h >dJ >So, why did Compaq keep the EV8 team funded and in place even though they knewI >that Alpha would be killed ? They probably didn't trust Intel to deliverP and I >wanted to keep their options opened. Remember that Alpha was starting tof takeJ >off in the high performance area, especially with the successes of celera	 genomics.p >i  J You are making  giant leap here that Alpha was being lined up to be killedJ when Windows was killed on it.  I think you can make a stronger connectionK that Compaq tried to continue Alpha, and that Windows was killed because of3J a lack of profitability.  Compaq then spent a lot of money to try to buildH UNIX marketshare as a last ditch effort to save that business.  And whenJ that didn't have the desired result, it decided that future investments toL keep the architecture competetive, would still not result in the marketshareI growing fast enough to make it a lucrative business, and competetive with  Sun, HP, and IBM.l  L The EV8 team wasn't moved to Intel until the painful decision was reached to5 drop Alpha and to align with Intel for high-end CPUs.m   ------------------------------   Date: 12 Jul 2002 17:25:57 GMT( From: nmm1@cus.cam.ac.uk (Nick Maclaren) Subject: Re: McKinley Cometh... 0 Message-ID: <agn3f5$lb9$1@pegasus.csx.cam.ac.uk>  2 In article <42EX8.26$Gt7.453649@news.cpqcorp.net>,7 "Fred Kleinsorge" <kleinsorge@star.zko.dec.com> writes:D |> 2M |> You are making  giant leap here that Alpha was being lined up to be killednM |> when Windows was killed on it.  I think you can make a stronger connectionxN |> that Compaq tried to continue Alpha, and that Windows was killed because ofM |> a lack of profitability.  Compaq then spent a lot of money to try to build K |> UNIX marketshare as a last ditch effort to save that business.  And whengM |> that didn't have the desired result, it decided that future investments tomO |> keep the architecture competetive, would still not result in the marketsharesL |> growing fast enough to make it a lucrative business, and competetive with |> Sun, HP, and IBM.   Grrk.  Well, yes, but ....  @ I shan't go deeply into this, because it would start being a bitB sensitive, but it is fair to say (a) that much of the money wasn'tB spent in the right ways, (b) that there wasn't as much of it spentA as the profits justified, and most importantly (c) that corporatet@ politics negated much of the effect of the money that was spent.  @ As an example, consider API.  It was a disaster, largely because@ it should have been pushing low-end products HARD and never did.? Samsung openly complained about that.  Now, one can ask why thet? major shareholder in a wholly owned company complained publicly @ and yet did nothing.  My suspicion is that Compaq actually owned@ most of the voting shares (set up that way so that API was a USAA company and so could sell to the DoD etc.) and wasn't keen on theh competition.  A Whether or not I have the politics right, it was clearly politics A that made API fail.  If it was API's politics, then whose job was @ it to replace API's management?  Samsung's and Compaq's.  But it was never done.   O |> The EV8 team wasn't moved to Intel until the painful decision was reached to 8 |> drop Alpha and to align with Intel for high-end CPUs.  " That was pretty clear, even to me.     Regards, Nick Maclaren,* University of Cambridge Computing Service,> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email:  nmm1@cam.ac.uk/ Tel.:  +44 1223 334761    Fax:  +44 1223 334679;   ------------------------------  # Date: Fri, 12 Jul 2002 17:49:09 GMT]* From: "Bill Todd" <billtodd@metrocast.net> Subject: Re: McKinley Cometh...[A Message-ID: <pEEX8.99805$Im2.4900023@bin2.nnrp.aus1.giganews.com>p  . "Dan Allen" <dallen@nist.gov> wrote in message4 news:OPEPIPEJGHNICIJKJFEAAEIHEOAA.dallen@nist.gov... >r > Ah yes, 60's overlays ;-)c  F Well, sort of.  The overlaying operation is a simple memory-map changeB rather than a disk access, and in cases such as the one I cited isF considerably more straight-forward than the general-purpose overlayingD mechanisms I worked with in the '70s (some of which involved similar' in-memory rather than disk overlaying).e   - bill   >  > > -----Original Message-----3 > > From: Bill Todd [mailto:billtodd@metrocast.net]l) > > Sent: Thursday, July 11, 2002 4:43 PM* > > To: Info-VAX@Mvb.Saic.Comr# > > Subject: Re: McKinley Cometh...h   ...   K > > Or if one or more individual applications want access to more than 2 orl 3 GBG > > of physical memory for data storage (since having more than 2 GB ofeI > > executing code is, I would hope, a rare occurrence), they can use the G > > Windows or Linux address windowing extensions to map (not copy) thee largerH > > memory as required into virtual address ranges within their normal 2 GB - 3F > > GB address space.  While the overhead of this mapping might becomeI > > noticeable for, say, random access within very large arrays, using ite for L > > something like an expanded database cache (where once you get a page you doG > > at least some actual work with it before needing another) makes ther overheadJ > > negligible, and the managing of such a cache adds very little relative: > > complexity to that of managing a cache in flat memory.   ------------------------------  % Date: Fri, 12 Jul 2002 08:45:59 +0100l% From: Alan Greig <a.greig@virgin.net>u4 Subject: Re: McKinley tops SpecFP AND SpecInt charts8 Message-ID: <d52tiucsn71el9mk9ut3eh254sa9opksm0@4ax.com>  F On Thu, 11 Jul 2002 16:16:19 GMT, "John Smith" <a@nonymous.com> wrote:   >b; >"JF Mezei" <jfmezei.spamnot@videotron.ca> wrote in message ' >news:3D2DACBF.E9EC6B7C@videotron.ca...o >>J >> Yes, Compaq was guilty of statements that Windows would rule the world, >butL >> then again Carly is equally guilty of such statements, although since theF >> merger, she seems to have toned down her pro-wintel stance, perhaps >becauseK >> she has realised the mess she got herself into and that the only way out  >wasK >> to focus on the real enterprise systems, the ones that generate profits.i >rM >Do you really think she realizes this? Why only now, when Walter et al. wereu' >saying the same things last September?   F Because the board only backed her against Walter if she agreed to takeB on-board his view that concentrating heavily on Windows as planned would likely kill HP?o  = Just a suggestion but both Hewelett and various analysts havee suggested something like this.  F Notice we have heard nothing from Capellas since his last "eviscerate" speech. Maybe a good sign?     -- Alan   ------------------------------  % Date: Fri, 12 Jul 2002 09:00:18 +0100n% From: Alan Greig <a.greig@virgin.net>e4 Subject: Re: McKinley tops SpecFP AND SpecInt charts8 Message-ID: <fc2tiu4qmuv0ke8mre1jd902ejcn570l8a@4ax.com>  F On Thu, 11 Jul 2002 15:23:50 GMT, "John Smith" <a@nonymous.com> wrote:     >c >iJ >Short of standing up in a VERY public way to dispell *any* doubt, HP willK >continue to be severely questioned on its commitment to VMS. Certainly thecE >act of NOT actively advertising, selling, and marketing VMS to *new*n( >accounts speaks volumes in that regard.  F While I agree with virtually everything you say below the fact remainsF that a very senior European HP manager went to some trouble to talk toF me in depth about VMS. I have never had any senior (non ex-DEC) Compaq1 management seek me out for a long chat about VMS.l  E HP seem now to be very much aware of how much money VMS generates andtF how upset much of the customer base is at much of the treatment by itsE previous two owners. Be absolutely sure that if nothing substantiallytE positive appears within the next few months, I'll no longer give themz the benefit of the doubt.e  C Note that UK Computer Weekly carried the headline "HP will not dropuC former Compaq Enterprise Operating Systems". The article went on to E principally talk about NSK but that may have been the reporters bias.   F Someone at HP does seem to be on the ball in chasing up negative pressC reports and rewording migration related documents. It remains to be40 seen if this is just window (Windows?) dressing.  M >When HP and DEC/Compaq were competitors, short of saying the same old mantrahK >that VMS doesn't do streams and spawn costs a lot of overhead on VMS, I'll+H >bet they didn't have a lot to say that was bad about VMS other than theE >commitment of its owners to the product, and hence the the long-termrM >economic cost to prospective users of VMS. And that was often enough to maker9 >those prospects become relatively happy HP-UX customers.r >fI >Now that HP owns the product, what do they say? Image activation doesn'tcK >cost anything after its instantiated? Streams are vastly overrated anyway?tK >HP is 100% committed to OpenVMS and it's better for most business-critical K >missions than HP-UX and Linux and Windows? Everything we said before was ao >lie?r >tJ >The current amount of effort in raising awareness in the market about VMSB >neither comforts the existing customer base, nor does it give anyG >prospective customers (not that HP is going out of its way to find anyoG >either) anything that they could take with confidence to their capitals >expenditures committees.  >tG >The death of Alpha and the move to an unproven architecture deters anywK >prospective new customers (as if they are being sought), while the current-M >installed base has to wait and see or decide to bail out. If distrust existsfE >about IA-64 and a current customer decides to bail, then the natural-F >alternatives are Sun and IBM, not HP-UX which itself is on a now dead >architecture. >  >t >sJ >Fiorina holds a bachelor's degree in medieval history and philosophy fromK >Stanford University; a master's degree in business administration from themL >Robert H. Smith School of Business at the University of Maryland at CollegeC >Park, Md.; and a MS degree from MIT's Sloan School. Presumably shewI >understands a bit about history, and presumably she took some courses in J >Marketing while stuying for the MBA, and through both those degrees she'sJ >probably picked up a smattering of psychology. She should understand whatM >happens to current and prospective customer perceptions when a company failsvK >to market its products. Perhaps she is well aware of the perception of VMS 0 >in the marketplace and doesn't care either way. >P >oM >I know that people will jump in at this point and say - 'Look at the port tosL >IA-64' and 'Look at the support commitment to 2011', but I think that it isJ >reasonable to say that this activity is funded out of Intel's pocket moreI >than Compaq's (inherited by HP). The bulk of the costs are up-front (the L >port) and that's appears to be covered off by Intel (at least that's what IM >gather from all the announcements a year ago) , whereas the on-going supporteL >can, and will be scaled down as the installed base leaves. First it will beL >layered products that are declared EOL, and then it will be the core OS. AsK >this happens, staff will be let go, and costs will decrease for HP. HP mayuI >sell the EOL'd products to 3rd-parties, but the amount of money realizedtK >will be low due to the declining customer base value to the 3rd-party, andeL >whatever cash is raised by the sale will most likely not go into supporting >VMS itself. >  >.I >> I likely still have a copy of an HP internal marketing document giving-G >> guidelines for handling the Compaq/Digital merger. In big letters onhD >> the front page it said "d|ub|i|o|u|s" (in the d|i|g|i|t|a|l styleF >> obviously). That was to be the first thing HP sales said concerning >> the future of VMS.g >nG >In respect of the Compaq/HP merger, apparently nothing significant hasu >changed for VMS, has it?r >c >iA >> Fascinatingly I got a copy of this HP internal document from a A >> Digital/Compaq employee. So they knew about it but did little.c >e2 >But we knew that then too, just as we see it now. >c >a   -- Alan   ------------------------------  % Date: Fri, 12 Jul 2002 09:18:55 +0100m% From: Alan Greig <a.greig@virgin.net>l4 Subject: Re: McKinley tops SpecFP AND SpecInt charts8 Message-ID: <hv3tiu0bsc2kbvo7i99n468p7odj5a2je8@4ax.com>  , On Thu, 11 Jul 2002 14:29:08 -0400, JF Mezei% <jfmezei.spamnot@videotron.ca> wrote:t   >John Smith wrote:L >> Short of standing up in a VERY public way to dispell *any* doubt, HP willM >> continue to be severely questioned on its commitment to VMS. Certainly thesG >> act of NOT actively advertising, selling, and marketing VMS to *new*1* >> accounts speaks volumes in that regard. >rI >Yes, getting up and admitting past mistakes and saying that things wouldcL >change that that HP would NOT continue "Compaq's plan of record" but ratherL >institute a new plan for VMS that include growth and the ability to compete4 >freely would achieve the desired result very fast.   D Which is why I was impressed that the first thing the HP guy I spokeB to recently said was, "Tell me what you would like us to do." I doF know enough psychology to realise there's another possible explanation here...s  K >Considering that the Compaq folks who had instuituted the "plan of record"uO >have been hired in high level positions at HP (Winkler, capellas etc), I doubtu >HP would take such an action.  B Capellas seems to have gone mute since his last Dalek "EVISCERATE, EVISCERATE, EVISCERATE" speech.t   >eI >So perhaps their intentions is to very slowly change the course and very M >slowly, without making any noticeable suddent changes, turn the tide around.eM >This will take longer and be less convincing, so HP will have to continue to H >hear "digital is killing VMS" complaints for a while longer before some- >credibility in HP's actions begins to build.m >m >In on   -- Alan   ------------------------------    Date: 12 Jul 2002 07:35:11 -0600- From: koehler@encompasserve.org (Bob Koehler)m4 Subject: Re: McKinley tops SpecFP AND SpecInt charts3 Message-ID: <oEf$1vegJpBA@eisner.encompasserve.org>   \ In article <3D2DACBF.E9EC6B7C@videotron.ca>, JF Mezei <jfmezei.spamnot@videotron.ca> writes: > Bob Koehler wrote:I >>    Why?  We've just seen HP do a much better job of promoting VMS thatu4 >>    Compaq ever did, or DEC in its last few years. > P > Sorry, but even under Compaq, there had been press releases. And when 7.2 cameL > out with the proprietarized Apache for VMS, there was also much visibility > about it.   K    As has already been discussed, there were presss releases, but few ever p)    saw them.  The difference is stunning.r   ------------------------------  # Date: Fri, 12 Jul 2002 14:02:45 GMTl# From: "John Smith" <a@nonymous.com>s4 Subject: Re: McKinley tops SpecFP AND SpecInt chartsF Message-ID: <9kBX8.1392$WsS.1313@news01.bloor.is.net.cable.rogers.com>  2 "Alan Greig" <a.greig@virgin.net> wrote in message2 news:d52tiucsn71el9mk9ut3eh254sa9opksm0@4ax.com...H > On Thu, 11 Jul 2002 16:16:19 GMT, "John Smith" <a@nonymous.com> wrote: >n > H > Notice we have heard nothing from Capellas since his last "eviscerate" > speech. Maybe a good sign?  J Perhaps he's in the throes of being 'eviscerated' himself. Not a bad thing if you ask me.   ------------------------------  # Date: Fri, 12 Jul 2002 14:06:21 GMTo# From: "John Smith" <a@nonymous.com>i4 Subject: Re: McKinley tops SpecFP AND SpecInt chartsF Message-ID: <xnBX8.1396$WsS.1058@news01.bloor.is.net.cable.rogers.com>  : "Bob Koehler" <koehler@encompasserve.org> wrote in message- news:oEf$1vegJpBA@eisner.encompasserve.org...u >hL >    As has already been discussed, there were presss releases, but few ever+ >    saw them.  The difference is stunning.-  K Press releases are nice, and yes there appears to have been more mention ofkL VMS in the past serveral months from HP than there appears to have been from. CPQ in a similar number of months in the past.  =  Some meatier statement from Carly would be equally in order.    ------------------------------  # Date: Fri, 12 Jul 2002 14:29:26 GMTt# From: "John Smith" <a@nonymous.com>I4 Subject: Re: McKinley tops SpecFP AND SpecInt chartsF Message-ID: <aJBX8.1454$WsS.1166@news01.bloor.is.net.cable.rogers.com>  2 "Alan Greig" <a.greig@virgin.net> wrote in message2 news:fc2tiu4qmuv0ke8mre1jd902ejcn570l8a@4ax.com...H > On Thu, 11 Jul 2002 15:23:50 GMT, "John Smith" <a@nonymous.com> wrote: >dH > While I agree with virtually everything you say below the fact remainsH > that a very senior European HP manager went to some trouble to talk toH > me in depth about VMS. I have never had any senior (non ex-DEC) Compaq3 > management seek me out for a long chat about VMS.e >iG > HP seem now to be very much aware of how much money VMS generates and H > how upset much of the customer base is at much of the treatment by itsG > previous two owners. Be absolutely sure that if nothing substantially G > positive appears within the next few months, I'll no longer give themm > the benefit of the doubt.r >sE > Note that UK Computer Weekly carried the headline "HP will not drop'E > former Compaq Enterprise Operating Systems". The article went on totG > principally talk about NSK but that may have been the reporters bias.r >nH > Someone at HP does seem to be on the ball in chasing up negative pressE > reports and rewording migration related documents. It remains to bed2 > seen if this is just window (Windows?) dressing.     Alan,h  I If indeed HP is taking a far more serious and pro-active approach to VMS,7I what on earth is wrong about making a top-level statement to that effect?hJ Not the half-hearted ones that came from Stallard, and later 'amended', orH the one about 'staying with the roadmap', but one that say unequivocally) that VMS is not a poor cousin any longer.g  L If all HP's actions to-date are truly indicative of this, then what possibleI reason could they have of NOT issuing a 1-page press release over Carly'st- name that this is the reality at  The New HP?l   ------------------------------  % Date: Fri, 12 Jul 2002 11:53:01 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca>s4 Subject: Re: McKinley tops SpecFP AND SpecInt charts, Message-ID: <3D2EFB5C.E16420FF@videotron.ca>   Alan Greig wrote:nG > HP seem now to be very much aware of how much money VMS generates andhH > how upset much of the customer base is at much of the treatment by its > previous two owners. n  G Are they aware that much of the damage was caused by Carly purposefullysM omitting VMS from any speech during the merger pregnancy, and when it finally F gave birth on may 7th, the insult on only giving VMS one sentence thatL promised to continue the same mistakes as Compaq, as well as Stallard's memoG stating that he expected all VMS shops to eventually migrate to HP-UX ?n  M Seems to me that the current efforts, if they are true, are more to do damage R control for HP's handling of VMS than they are to correct Compaq's handling of it.  G Marcello, in the letter about the survey, continued to use the "plan ofoN record"  thing, reminding all of us that if HP is to be like Compaq, it should not be trusted.t   ------------------------------  % Date: Fri, 12 Jul 2002 12:03:41 -0400o- From: JF Mezei <jfmezei.spamnot@videotron.ca> 4 Subject: Re: McKinley tops SpecFP AND SpecInt charts, Message-ID: <3D2EFDDC.B760DA32@videotron.ca>   Bob Koehler wrote:L >    As has already been discussed, there were presss releases, but few ever+ >    saw them.  The difference is stunning.>  M I would debate the "fewer saw them" issue, at least for the ones that occured>J when 7.2 was released. Perhaps Sue wasn't so active in this group to pointM them out at that time, but I recall seing them in the newswires, as well as anP few articles written here and there about Compaq releasing a new version of VMS.  M Perhaps you are now more attentive to them because of all the upheaval of the- HP takeover.   ------------------------------  % Date: Fri, 12 Jul 2002 12:35:38 -0400e- From: JF Mezei <jfmezei.spamnot@videotron.ca> 4 Subject: Re: McKinley tops SpecFP AND SpecInt charts, Message-ID: <3D2F0556.6FB2FE9C@videotron.ca>   John Smith wrote:sJ > > Notice we have heard nothing from Capellas since his last "eviscerate" > > speech. Maybe a good sign? > L > Perhaps he's in the throes of being 'eviscerated' himself. Not a bad thing > if you ask me.    M Carly needed Curly's support for the merger. She may even have said stuff sheaK didn't really beleive, but felt it necessary to appear very compatible withnJ Curly. But now that Compaq has been securely captured, she doesn't need to please Curly anymore.i  M Had this merger happened during the .COM boom, I wouldn't be surprised to seePM Curly leave fairly fast to join some upstart as its president/ceo etc. But in L the current economic climate, I suspect that Curly, knwowing he doesn't haveK what it takes to head such a large company, will stay put in his office andB) see no evil, hear no evil and do no evil.a   ------------------------------  % Date: Fri, 12 Jul 2002 12:49:02 -0400g- From: JF Mezei <jfmezei.spamnot@videotron.ca> 4 Subject: Re: McKinley tops SpecFP AND SpecInt charts, Message-ID: <3D2F0879.4DC6F820@videotron.ca>   John Smith wrote:fK > If indeed HP is taking a far more serious and pro-active approach to VMS,yK > what on earth is wrong about making a top-level statement to that effect?    possible scenario:  K top-level still intends to ditch VMS, or keep it low profile enough that ite& evaporates out of existence by itself.  M lower level grunts, realising what HP intends to do try very hard to find anyaK possible way to release marketing about VMS without upper management really,N taking notice, in an effort to maintain the sales and prevent its evaporation.  K The information about the 400k systems, even if that is totally useless and2K perhaps invalid information, is still very good for VMS because it makes ityK much harder for upper management to announce the death of VMS to the press.eG And now, Sue has leaked that VMS has had double digit growth, but won'tg confirm it.e  G As long as the grunts at the low levels can show positive signs for VMSlN (profits, growth, new software), it makes it much harder for top management toM implement their long term strategies. If, in the face of the Alpha murder, HPsL merger, Stallard memo and lack of a real HP branded strategy for VMS ("we'llN continue Compaq's plan of record" translates to "we don't know what to do withK VMS, so for now, we continue whatever Compaq had been doing, even though wet0 doN't have a clue what it was Compaq was doing")  L Lets not forget that VMS was put in the "legacy" department along with Alpha, and Tru64, neither of which have any future.  I So I am not sure whether the VMS folks see a bigger baattle in convincinge. upper managenment, or in convincing customers.   ------------------------------  # Date: Fri, 12 Jul 2002 17:40:57 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com>-4 Subject: Re: McKinley tops SpecFP AND SpecInt charts, Message-ID: <JwEX8.37056$Jp.70765@rwcrnsc53>  8 "Rob Young" <young_r@encompasserve.org> wrote in message- news:WpxFjtZvvMVM@eisner.encompasserve.org...n >uD >         That's right.  Time to eat crow all around.  Perhaps there8 >         may not be enough platters, but who cares, eh? > F >         According to the PPTs and HTMLs found at www.openvms.org oneH >         can find (in the notes field) the Spec numbers embargoed until today. >VF >         Following are base numbers.  So maybe there is a tiny bit of4 >         glory left for Power4 in SpecInt2000 peak? > ; >                 Itanium 2               Power4 at 1.3 GHzo >l- > SpecInt2000     810                     804n. > SpecFp          1356                    1202 >t >r  J Oh, I think it's time for rival spin doctors and naysayers to SET RPM = 78   ------------------------------  % Date: Fri, 12 Jul 2002 15:09:07 +0100 U From: Andrew Harrison SUNUK Consultancy <andrew_nospam.harrison_remove_this@sun#.com>t4 Subject: Re: Only 20% drop in VMS systems (was: wow)0 Message-ID: <agmnt7$7d4$1@new-usenet.uk.sun.com>   Main, Kerry wrote:   > Andrew, Andrew ..l >  > G >>>>Of course you have also forgotten the other rule of consolidations,w >>>>I > its better to consolidate on like version DBMS's so if the old platform H > is running 8.1.6/8.0.5 etc then its better to consolidated to 8.1.6 or4 > whatever the version is on the target platform.<<< >  > Better? Sure. Required? No.  > C > As you know, you can run different versions of Oracle on the samesH > system. You can also use partitioning on systems that support it (likeF > GS Series) to run different OS / Oracle instances. In the case of GSD > Series systems, you can also use OpenVMS Galaxy to share CPU's andH > memory between the OS instances. You can also use the shared memory inI > OpenVMS Galaxy as an extremely fast cluster communications interconnectm > between Oracle instances.o > H > <<< The 70% number is what Oracle consultants that I have delt with onA > 9i RAC put as being the upper bound for scalability for RAC.>>>  > F > Now, lets see .. Are you saying a 50+ cpu SMP system will scale 100%H > with each additional CPU added? Ok, you and I both know that's not theD > case. Ok, how about 85%? Perhaps - if tuned optimally. More likelyA > 75-85% is a more real life target, but it really depends on thex > application workload mix.s >      Well lets examine this claim.o  8 I can produce a ream of examples with actual scalability5 numbers for machines going up to 70+ CPU's. These arei7 all SMP/DBMS examples where no coding changes have been 6 made to make the app scale. Scalability is in the high9 90s%. Prior to the F15000 we had similar experiences withl the E10K with 60+ CPU'sd  6 Your experience of scalability on large SMP systems is6 coloured by the fact that you are using GS's. With all7 their problems 85% is probably optimistic but that does,0 not mean that all SMP systems are like a GS box.  6 I can produce examples of apps that don't scale at all2 or scale very badly as well, but since these don't8 would not scale in a cluster either we can discard them.    / > So, it looks like we are not that far apart. e >     6 So it looks like we are still as far appart as we were8 before. And the possible 70% scalability for Oracle in a cluster is after tuning.     > :-)o > E > <<< I am sure that isn't really the case and I am sure that in youreD > haste to produce a justification for you claims you have abandoned > normal HP practice.>>> e > F > Now, now - I was talking about experienced Customer Oracle DBA's not; > absolutely requiring OPS training .. But, you knew that. p >     < Yes I did realise that ! Still doesn't explain your apparent8 willingness to sanction people adminning a HA system who have not training to do so.4  : Most training is layered, Oracle OPS layered on Oracle DBA< UNIX systems admin layered on UNIX user etc. Very few people; would suggest as you are trying to do that because you have < don the foundation course that you don't then need to do the layers on top.  < As I said you and jlsue are wonderfull, platform "solutions"= that arn't supported by the ISV that the platform is supposed ; to host being adminned by people with Oracle for Dummies orl? OPS for Dummies in their back pocket. I am sure that this isn'te? HP's actual policy however much your posts tend to suggest thatw it is.  = Incedentally you really should try reading Oracles own advicet; on the subject. The course material for RAC is pretty clearn9 and it also requires a course basis which is not just thea5 basic DBA set. You have to have been on the Oracle 9iu7 Performance Tuning Course prior to the RAC course, thisc4 is not a requirment for normal DBA's and should help7 you understand where deploying RAC may well differ froml& a standard single instance deployment.           Regardse   Andrew Harrisone   ------------------------------  # Date: Fri, 12 Jul 2002 17:42:05 GMT 1 From: "Terry C. Shannon" <terryshannon@attbi.com>a4 Subject: Re: Only 20% drop in VMS systems (was: wow)? Message-ID: <NxEX8.331530$R61.295392@rwcrnsc52.ops.asp.att.net>t  2 "Main, Kerry" <Kerry.Main@hp.com> wrote in messageL news:BE56C50EA024184DAF48F0B9A47F5CF40266080B@kaoexc01.americas.cpqcorp.net. .. Bill,e   Re: grammar school ..-  D I am sorry if I offended the comp.os.vms moderator / grand teacher -" I'll try to behave in the future..    G It's not your fault, Kerry... had your parents sent you to a typical US-* Government Skool, you would see the light!   ------------------------------  % Date: Fri, 12 Jul 2002 09:37:51 +0100o% From: Alan Greig <a.greig@virgin.net>   Subject: Re: OpenVMS Ambassadors8 Message-ID: <2q4tiusuggkl371l98mct6etn20kuh62ug@4ax.com>  F On 11 Jul 2002 16:21:37 -0400, fdc@columbia.edu (Frank da Cruz) wrote:  L >In article <3D2D9889.E2E9932D@vcu.edu>, Jim Agnew  <jpagnew@vcu.edu> wrote:G >: i'm glad someone did something for him...  he sounded like a regulart	 >: guy...y >: hH >The old school...  When CEOs cared about such things as their customersL >and employees and the long-term viability of their company.  Legacy notionsG >now discredited and deprecated in the modern fast-paced marketplace in J >which nobody matters but the stockholders.  Hmmm, wait, they don't matter
 >either...  E I was suprised to read that Carly met Ken Olsen back in the days whenoD he still ran DEC and Carly was an MIT student. She said she was veryC impressed by Olsen's DEC. It might be interesting to see what wouldu come out of an updated chat. -- Alan   ------------------------------  # Date: Fri, 12 Jul 2002 11:51:27 GMT.1 From: CSABA  HARANGOZO   <csabah@zipworld.com.au>   Subject: Re: OpenVMS Ambassadors6 Message-ID: <3pzX8.1012$M5.94105@nasal.pacific.net.au>  2 Jerry Leslie <LESLIE@jrlvax.houston.rr.com> wrote:) > Frank da Cruz (fdc@columbia.edu) wrote:gO > : In article <3D2D9889.E2E9932D@vcu.edu>, Jim Agnew  <jpagnew@vcu.edu> wrote:wJ > : : i'm glad someone did something for him...  he sounded like a regular > : : guy... > : : K > : The old school...  When CEOs cared about such things as their customers-O > : and employees and the long-term viability of their company.  Legacy notionsnJ > : now discredited and deprecated in the modern fast-paced marketplace inM > : which nobody matters but the stockholders.  Hmmm, wait, they don't matterD
 > : either...@ > :t  $ > There are 1 or 2 such CEOs left...  M >   http://sitesearch.washingtonpost.com/wp-dyn/articles/A3963-2001Dec19.htmlb8 >   A CEO Who Lives by What's Right (washingtonpost.com)   [...snip...]  : 	Nice. Also, here in Oz, there are still a few such CEO-s.= 	Take for example a company called Kennard Hire. It is in thei< 	news, that the company distributed their ( whole ? ) profit0 	among the 500+ employes, about a million bucks.A 	The employees got a surprise packet containing about 2000 bucks.t8 	( The story is probably in the Sydney Morning Herald. )   						Cheers,   Csaba   I    ----------------------------------------------------------------------pE    * Csaba I. Harangozo     |    'To err is human', said the hedgehogeE    * csabah@zipworld.com.au |           as he dismounted a wirebrush.sI    ----------------------------------------------------------------------:;    EARTH::AUSTRALIA:[SYDNEY]HARANGOZO.CSABA;1, delete? [N]:e   ------------------------------  % Date: Fri, 12 Jul 2002 14:00:41 +0200 9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>e  Subject: Re: OpenVMS Ambassadors' Message-ID: <3D2EC4E9.7AC52F4B@aaa.com>-  E Now, as the cloning technic makes progress, you'll be glad that there@3 are at least on OS that saves multible versions :-) E And you'll better be version ;0 when "someone" decides that the wholeb2 cloning thing was a bad idea and issues a PURGE...   Jan-Erik Sderholm.e     Csaba I. Harangozo wrote :  = >    EARTH::AUSTRALIA:[SYDNEY]HARANGOZO.CSABA;1, delete? [N]:e   ------------------------------  # Date: Fri, 12 Jul 2002 17:33:17 GMTi1 From: "Terry C. Shannon" <terryshannon@attbi.com>a  Subject: Re: OpenVMS Ambassadors? Message-ID: <xpEX8.331454$R61.295854@rwcrnsc52.ops.asp.att.net>e  > "Sue Skonetski" <susan_skonetski@hotmail.com> wrote in message7 news:857e9e41.0207101918.68b3e393@posting.google.com... D > There have been some recent postings about the OpenVMS Ambassadors4 > Program and I just wanted to set matters straight. >M  G This is not surprising. Much of the commentary in this forum comes fromw2 folks who espouse a "ready," "fire," "aim" policy.   ------------------------------  # Date: Fri, 12 Jul 2002 17:40:02 GMT01 From: "Terry C. Shannon" <terryshannon@attbi.com> J Subject: Re: OpenVMS on third-party platforms (was: Re: VMS port delayed!)? Message-ID: <SvEX8.331515$R61.295766@rwcrnsc52.ops.asp.att.net>p  L IMHO if VMS had the same massive apps portfolio that our friends at Sun haveJ at their disposal, Sun would cease to be a significant factor in the grandG scheme of things. My opinion only, our colleague Andrew H. might have ao different opinion!   ------------------------------  # Date: Fri, 12 Jul 2002 14:22:24 GMTi1 From: "Terry C. Shannon" <terryshannon@attbi.com>i$ Subject: Re: OpenVMS Polls are back!; Message-ID: <ACBX8.11871$uw.7076@rwcrnsc51.ops.asp.att.net>   = "Zane H. Healy" <healyzh@shell1.aracnet.com> wrote in messagec% news:aglcr00a1d@enews2.newsguy.com... B > In comp.sys.dec David J. Dachtera <djesys.nospam@fsi.net> wrote:A > > o Should HP (or OpenVMS's current owner) revive OpenVMS-IA32?r >iE > Would you mind explaining *WHY* this makes any sort of sense from aa businessI > standpoint?  I for one would much rather see development money spent on C > porting to iA64 and on improving OpenVMS than on porting to iA32.d > E > Now what I'd really like to see is an affordable iA64-based OpenVMSo> > Workstation!  Something along the lines of the Sunblade-100. >h  * I am sure that such will materialize when:   A) IA64 gets cheaper   B) The VMS-on-IPF port is done.    This is gonna take time.   ------------------------------  + Date: Fri, 12 Jul 2002 15:27:11 +0000 (UTC)n From: david20@alpha1.mdx.ac.uk$ Subject: Re: OpenVMS Polls are back!+ Message-ID: <agmsgf$koa$1@aquila.mdx.ac.uk>l  ` In article <aglcr00a1d@enews2.newsguy.com>, "Zane H. Healy" <healyzh@shell1.aracnet.com> writes:A >In comp.sys.dec David J. Dachtera <djesys.nospam@fsi.net> wrote:.@ >> o Should HP (or OpenVMS's current owner) revive OpenVMS-IA32? > M >Would you mind explaining *WHY* this makes any sort of sense from a businessPH >standpoint?  I for one would much rather see development money spent onB >porting to iA64 and on improving OpenVMS than on porting to iA32. > D >Now what I'd really like to see is an affordable iA64-based OpenVMS= >Workstation!  Something along the lines of the Sunblade-100.n >h >		Zanep  E Well what about the DS10L's available from Island for $950. There old - technology but then so are the Sunblade-100s.nJ The only real difference is they're being sold by a thirdparty rather than the manufacturer.o  t    M If you want to RUN VMS on IA32 compatible machines in the future you would berN better of targeting a port at HAMMER. That way VMS could run on the machine inN 64bit mode whilst the user could also run other OS's in 32bit mode (or as they  become available in 64bit mode).  I It might have made sense to target a port at IA32 four or five years ago. F There doesn't seem much point in porting to a 32bit,  soon to be dead  architecture now.oM All AMDs chips will be variants of the 64bit Hammer whether they are intendede+ to run 32bit or 64bit OSs and applications..    
 David Webb VMS and Unix team leader CCSS Middlesex University   ------------------------------  + Date: Fri, 12 Jul 2002 09:30:54 +0100 (BST)nF From: =?iso-8859-1?q?Tadimeti=20Keshav?= <keshav_tadimeti@yahoo.co.uk> Subject: Oracle RDB on VMS@ Message-ID: <20020712083054.36446.qmail@web21010.mail.yahoo.com>  
 Hello all,3 I downloaded an RDB 7.0.6 ZIP file (62 MB file) fors% Open VMS Alpha  from Oracle Technet. t  2 THe file looks too small. All it has is some files3 with a .a, .d extensions. I'd like to know if this,m6 when installed, will be a working database server. Are- there any special steps to be followed duringu2 installation? Anyone who has tried this map please provide help.    Thanks & regards Keshav  2 __________________________________________________ Do You Yahoo!?+ Everything you'll ever need on one web pagee- from News and Sport to Email and Music Chartsi http://uk.my.yahoo.com   ------------------------------  # Date: Fri, 12 Jul 2002 09:08:44 GMT L From: winston@SSRL.SLAC.STANFORD.EDU ("Alan Winston - SSRL Admin Cmptg Mgr") Subject: Re: Oracle RDB on VMS8 Message-ID: <00A10CD1.83664B55@SSRL04.SLAC.STANFORD.EDU>   In article <20020712083054.36446.qmail@web21010.mail.yahoo.com>, =?iso-8859-1?q?Tadimeti=20Keshav?= <keshav_tadimeti@yahoo.co.uk> writes:a   >Hello all,a4 >I downloaded an RDB 7.0.6 ZIP file (62 MB file) for& >Open VMS Alpha  from Oracle Technet.  >e3 >THe file looks too small. All it has is some filesn4 >with a .a, .d extensions. I'd like to know if this,7 >when installed, will be a working database server. Are . >there any special steps to be followed during3 >installation? Anyone who has tried this map please- >provide help.    , Dude, you gotta read the installation guide.  3 VMS software meant to be installed using VMSINSTAL  5 (hint: @SYS$UPDATE:VMSINSTAL HELP ) comes in multipleD; savesets of which the only required one is the one with the = .A extension.  This contains a KITINSTAL.COM procedure that'sh? executed by VMSINSTAL to unpack the other savesets (if any) andf" install the required components.    K To the best of my knowledge and belief the ZIP file on Technet is complete.r   -- Alan         O =============================================================================== 0  Alan Winston --- WINSTON@SSRL.SLAC.STANFORD.EDUM  Disclaimer: I speak only for myself, not SLAC or SSRL   Phone:  650/926-3056iM  Physical mail to: SSRL -- SLAC BIN 69, PO BOX 4349, STANFORD, CA  94309-0210eO ===============================================================================e   ------------------------------  % Date: Fri, 12 Jul 2002 15:03:30 +0200n$ From: "Peter Flunger" <p-i-b@gmx.at> Subject: Re: Oracle RDB on VMS0 Message-ID: <agmk33$dul$1@newsreader1.netway.at>  / "Tadimeti Keshav" <keshav_tadimeti@yahoo.co.uk>a4 > THe file looks too small. All it has is some files5 > with a .a, .d extensions. I'd like to know if this,o8 > when installed, will be a working database server. Are/ > there any special steps to be followed during 4 > installation? Anyone who has tried this map please > provide help.l   I fully agree with Alan,$ this seems to be the complete works.9 Although it is hard to beliefe if you are used to working 4 with Oracle9i on OpenVMS ( 2 almost full CDs, though6 you certainly do not need 70% of the shi<del><del>tuff you still have to install it ).n0 Farewall Oracle RDB, one more sad example of how< things go if a company fails to market an excellent product. Petere   ------------------------------  % Date: Fri, 12 Jul 2002 15:12:35 +0200-9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>y Subject: Re: Oracle RDB on VMS& Message-ID: <3D2ED5C3.DA3EE90@aaa.com>  8 Whatever might be the problem with the marketing of Rdb,? what does that have to do with the kit on the Oracle web site ?e  > As far as I know, there is no problem with the kit, besides of> that it isn't the latest version. But that have been addressed@ by Oracle, and according to message (see below) on the Rdb list- server, this will be fixed.L  ? The "problem" here seems to be that the original poster have toe> read-up on some documentation and learn how to handle a normal VMSINSTAL kit...   Jan-Erik Sderholm.s    ( From the Rdb list-server (9-July 2002) :  9 -- We will be putting the Rdb 7.1.0.2 kit on OTN shortly  C -- along with the Rdb 7.0.6.4 kit and are planning to keep the site   -- up-to-date with new releases. -- -- Ginger Vollmar  -- Rdb Engineering   Peter Flunger wrote: > 1 > "Tadimeti Keshav" <keshav_tadimeti@yahoo.co.uk>-6 > > THe file looks too small. All it has is some files7 > > with a .a, .d extensions. I'd like to know if this,p: > > when installed, will be a working database server. Are1 > > there any special steps to be followed duringd6 > > installation? Anyone who has tried this map please > > provide help.  >  > I fully agree with Alan,& > this seems to be the complete works.; > Although it is hard to beliefe if you are used to workingS6 > with Oracle9i on OpenVMS ( 2 almost full CDs, though8 > you certainly do not need 70% of the shi<del><del>tuff! > you still have to install it ).m2 > Farewall Oracle RDB, one more sad example of how> > things go if a company fails to market an excellent product. > Peter    ------------------------------  + Date: Fri, 12 Jul 2002 15:33:08 +0100 (MET)u9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>i Subject: Re: Oracle RDB on VMS; Message-ID: <01KK0G3THQRI96Y2PR@sysdev.deutsche-boerse.com>n  2 > Farewall Oracle RDB, one more sad example of how> > things go if a company fails to market an excellent product.  C Rdb is alive and well.  New versions appear regularly, and the 7.1  F release added a lot of new functionality.  (There is a rumour that it I was to be called 8.0 because it added so much new stuff, but was renamed 0@ since some folks don't like to install a ".0 release".  :-)  It > definitely was renamed, but I don't know the official reason.)  F There are two supported streams, the 7.0.x and the 7.1.x stream.  The  former supports VAX as well.  F Yes, it, like VMS (up until now?), is a stealth product.  However, so I much of the world runs on Rdb that there is no danger of it disappearing   any time soon.  A I am definitely a fan of the Good Old Days when everything---OS,  H hardware (CPU and peripherals), terminals, printers---came from Digital G Equipment Corporation.  However, perhaps selling Rdb was a good thing, tH since otherwise DEC would have been a competitor to Oracle, and in turn F Oracle might not have offered Oracle Classic (i.e. not Rdb) for VMS.  G With the present setup, Oracle doesn't have to care which one it sells.   H Rdb still has a very VMS look and feel, and will probably stay that way.  F Those familiar with VMS marketing will feel at home: You think VMS is G not being marketed enough?  There is no way, certainly no easy way, to  G get from http://www.oracle.com to http://www.oracle.com/rdb/ yet it is eA obvious from the design that the web pages know about each other.e   ------------------------------  % Date: Fri, 12 Jul 2002 15:01:03 +0200a= From: Arne =?iso-8859-1?Q?Vajh=F8j?= <arne.vajhoej@gtech.com>i Subject: Re: Oracle RDB on VMS) Message-ID: <3D2ED30F.8CDD18F2@gtech.com>,   Tadimeti Keshav wrote: > Hello all,5 > I downloaded an RDB 7.0.6 ZIP file (62 MB file) fora& > Open VMS Alpha  from Oracle Technet. > 4 > THe file looks too small. All it has is some files5 > with a .a, .d extensions. I'd like to know if this,m8 > when installed, will be a working database server. Are/ > there any special steps to be followed duringe4 > installation? Anyone who has tried this map please > provide help.u   I got it working !  ( .A etc. are VMS save-sets for VMSINSTAL.   Arne   ------------------------------  + Date: Fri, 12 Jul 2002 15:57:33 +0000 (UTC)r From: david20@alpha1.mdx.ac.uk Subject: Re: Oracle RDB on VMS+ Message-ID: <agmu9d$koa$3@aquila.mdx.ac.uk>i  w In article <01KK0G3THQRI96Y2PR@sysdev.deutsche-boerse.com>, Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com> writes:oB >I am definitely a fan of the Good Old Days when everything---OS, I >hardware (CPU and peripherals), terminals, printers---came from Digital hH >Equipment Corporation.  However, perhaps selling Rdb was a good thing, I >since otherwise DEC would have been a competitor to Oracle, and in turn rG >Oracle might not have offered Oracle Classic (i.e. not Rdb) for VMS.  tH >With the present setup, Oracle doesn't have to care which one it sells. >g  < As I recall Oracle classic was originally developed on VMS. N I can't recall the exact timings but Oracle Classic on VMS has not been a tierM one port since RDB was sold to Oracle. Hence to me it looks as though sellingtG RDB to Oracle did absolutely nothing to persuade Oracle to keep VMS as DM a tier one port. If anything it looks like Oracle deemphasised Oracle classicM on VMS after obtaining RDB.   
 David Webb VMS and Unix team leader CCSS Middlesex University    I >Rdb still has a very VMS look and feel, and will probably stay that way.c >.G >Those familiar with VMS marketing will feel at home: You think VMS is  H >not being marketed enough?  There is no way, certainly no easy way, to H >get from http://www.oracle.com to http://www.oracle.com/rdb/ yet it is B >obvious from the design that the web pages know about each other. >i   ------------------------------  % Date: Fri, 12 Jul 2002 15:52:51 +020031 From: Patryk Lorenowicz <loren@icslab.agh.edu.pl>:* Subject: Problem with access to VMS on VAXM Message-ID: <Pine.GSO.4.30.0207121517140.4595-100000@ernie.icslab.agh.edu.pl>u   Hi,:' I have MicroVAX II with VAX/VMS V5.4-3.iJ People whose has been operating this machine, hadn't powered it for a long4 time and now they don't remember superuser password.  2 Is there some method to get/change this password ?  1 I have unlimited physical access to this machine.n@ There is tape drive in it. I have original tapes with VMS binary* and VAX diagnostic tools (other soft too).  F I can reinstall whole system, but i wonder if I can get access without this.a  / Please notice, that i'm beginner in VMS system.d Thanks in advanced.    -- m Loren    ------------------------------  % Date: Fri, 12 Jul 2002 09:27:50 -0500uC From: "Craig A. Berry" <craig.berry@nospam.SignalTreeSolutions.com>,. Subject: Re: Problem with access to VMS on VAXH Message-ID: <craig.berry-28FBC3.09275012072002@news.directvinternet.com>   In article $B <Pine.GSO.4.30.0207121517140.4595-100000@ernie.icslab.agh.edu.pl>,3  Patryk Lorenowicz <loren@icslab.agh.edu.pl> wrote:w  ) > I have MicroVAX II with VAX/VMS V5.4-3..L > People whose has been operating this machine, hadn't powered it for a long6 > time and now they don't remember superuser password. > 4 > Is there some method to get/change this password ? > 3 > I have unlimited physical access to this machine.gB > There is tape drive in it. I have original tapes with VMS binary, > and VAX diagnostic tools (other soft too). > H > I can reinstall whole system, but i wonder if I can get access without > this.t > 1 > Please notice, that i'm beginner in VMS system.E  - Welcome.  Take a look at the FAQ located heret  7 <http://www.openvms.compaq.com/wizard/openvms_faq.html>i  B Specifically you'll want the section entitled "I've forgotten the 5 SYSTEM password - what can I do?" which is located at   @ <http://www.openvms.compaq.com/wizard/faq/vmsfaq_004.html#mgmt5>   ------------------------------  % Date: Fri, 12 Jul 2002 15:36:52 +0100s* From: "Richard Brodie" <R.Brodie@rl.ac.uk>. Subject: Re: Problem with access to VMS on VAX+ Message-ID: <agmphd$q8m@newton.cc.rl.ac.uk>i  > "Patryk Lorenowicz" <loren@icslab.agh.edu.pl> wrote in messageG news:Pine.GSO.4.30.0207121517140.4595-100000@ernie.icslab.agh.edu.pl...z  ) > I have MicroVAX II with VAX/VMS V5.4-3.oL > People whose has been operating this machine, hadn't powered it for a long6 > time and now they don't remember superuser password. >-4 > Is there some method to get/change this password ?   Please see the FAQ: ?  http://www.openvms.compaq.com/wizard/faq/vmsfaq_004.html#mgmt5    ------------------------------  % Date: Fri, 12 Jul 2002 18:37:14 +0200:1 From: Patryk Lorenowicz <loren@icslab.agh.edu.pl>5. Subject: Re: Problem with access to VMS on VAXN Message-ID: <Pine.GSO.4.30.0207121836130.12240-100000@ernie.icslab.agh.edu.pl>  * On Fri, 12 Jul 2002, Craig A. Berry wrote:  / > Welcome.  Take a look at the FAQ located hereh9 > <http://www.openvms.compaq.com/wizard/openvms_faq.html>o   Yes, it worked ! Thanks to all !!!    -- R LorenT   ------------------------------    Date: 12 Jul 2002 09:26:29 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)ME Subject: Re: Problem with access to VMS on VAX (System Password lost)e3 Message-ID: <EnSF4WpD5Wu$@eisner.encompasserve.org>4   In article <Pine.GSO.4.30.0207121517140.4595-100000@ernie.icslab.agh.edu.pl>, Patryk Lorenowicz <loren@icslab.agh.edu.pl> writes:t > Hi,g) > I have MicroVAX II with VAX/VMS V5.4-3.oL > People whose has been operating this machine, hadn't powered it for a long6 > time and now they don't remember superuser password. > 4 > Is there some method to get/change this password ?  2 http://Encompasserve.org/VMS/vmsfaq_004.html#mgmt5   ------------------------------  # Date: Fri, 12 Jul 2002 16:05:36 GMTo- From: goathunter@goatley.com (Hunter Goatley)V Subject: Re: RECALL suggestion0 Message-ID: <3d2efd18.12164101@news.process.com>  - Just to add my own "Me, too" message here....i  D My SD program (loosely based on an old Alan Zirkle SD program) keeps@ a stack of directories visited, as well as allowing all sorts of	 shortcutsc  (   SD ^      Go up one subdirectory levelE   SD @      Go to top level of current directory (enter TOP for help)-2   SD .      Go to login default directory and disk9   SD #n     Go to directory in n'th entry of the SD stackR@   SD #      Set default to stack entry #1 (toggle stack entries)8   SD >X     Set default to [z.X] when currently in [z.y]&   SD .X     Set default to [current.X]5   SD X.Y.Z  Set default to [X.Y.Z] (enter X for help) 3   SD %      Push the current default onto the stacku4   SD *      Show the SD stack (enter STACK for help))   SD ?      Show this SD help informationh$   SD        Show the current default  L Directory names can be abbreviated, and, of course, multiple commands can be	 combined:n    $ SD #3 >Xn  I Visit previous directory #3 then move over to the directory starting witht X at that same level.i  K The ability to shortcut directory names makes life a *lot* easier.  Instead0 of:h  + $ SD .MULTINET_PLUS.MULTINET.KERNEL.DRIVERS   	 I can do:s   $ SD .MUL.MUL.K.DS  P You can find this as HGSD.ZIP in my archives, along with at least one CD utility9 that works similarly, but offers a more UNIX-like syntax.i   http://www.process.com/openvms/O4 ftp://ftp.process.com/vms-freeware/fileserv/hgsd.zip! Also on the last VMS Freeware CD.0     Hunter ------9 Hunter Goatley, Process Software, http://www.process.com/ 8 goathunter@goatley.com    http://www.goatley.com/hunter/< New Robert R. McCammon site: http://www.RobertRMcCammon.com/   ------------------------------  # Date: Fri, 12 Jul 2002 11:08:46 GMT 0 From: George Pagliarulo <georgepag@adelphia.net> Subject: Re: TIMA ) Message-ID: <3D2EBA61.80805@adelphia.net>4   Hi,   8 	I have some responsibility in the VMS ECO release area.  > As others have said TIMA is "Technical Information Management E Architecture".  Over time, because our ECO kits go through the "TIMA" B process, they became known internally as "TIMA" kits - a complete C misnomer that continues to make it into documentation.  I tried to fG correct it for a long time and then just gave up.  Once something like r# that sticks it's hard to eliminate.    George Pagliarulon   Nic Clews wrote:   > What does TIMA mean? > 9 > http://www.openvms.compaq.com/openvms/supportchart.htmln > 7 > e.g. Top line is ES45, saying we need VMS 7.3 + TIMA.i > F > An ex DECcie told me that TIMA was "Technical Information ManagementE > Architecture" but it doesn't make sense in that context. Now, if iteH > meant patches, then ECO (Engineering Change Order) would make a little
 > more sense.s > 1 > The "Digital Dictionary" doesn't have an entry.i >  > So, does anyone know?i >    ------------------------------    Date: 12 Jul 2002 07:52:31 -0600- From: koehler@encompasserve.org (Bob Koehler)-& Subject: Re: VAX Scan on OpenVMS Alpha3 Message-ID: <nDXJHLSJ0Y13@eisner.encompasserve.org>v  b In article <agk71o$c7n$1@web1.cup.hp.com>, "Sue Skonetski" <susan.skonetski@hp.nospam.com> writes: >  Dear Newsgroup, > G > About 5 minutes ago I received the following and thought you might ben
 > interested.m >  > Warm Regards,  > Suee > AlphaScana > VAX Scan on OpenVMS/Alpha M > Good news for VAX Scan users: Software Resources International, the company F > that created the VAX Emulator CHARON-VAX, migrates VAX Scan to Alpha+ > systems. The product is named AlphaScan.    2    I wonder if they'll get out a hobbyist version?   ------------------------------  % Date: Fri, 12 Jul 2002 15:24:43 +0200r0 From: Robert Boers <robert.boers@softresint.com>& Subject: Re: VAX Scan on OpenVMS Alpha- Message-ID: <3D2ED89B.8090002@softresint.com>-   To comment on earlier posts:  G No VAX is required anymore with AlphaScan. Yes, we retain the internal LH n-tuples structure of the VAXScan compiler but redo them completely for @ the Alpha platform. The C code is NOT generated by the n-tuples C interpretation but by *parallel* compilation done by the AlphaScan ?E compiler in parallel. The C code internal representation is not even   visible to the user.  C AlphaScan will not use embedded Scan support in the Alpha debugger  G because that support simply doesn't exist in it. We cannot do anything dE about that since introducing this support would require changing the v Alpha debugger.a  D The main goal is to be able to use the existing VAXScan code on the A Alpha platform, not to design Scan language support in the Alpha iE debugger, as we expect that the focus is more on maintenance than of L! developing new Scan applications.L  C The Scan language on Alpha will be supported by the debugger as an oD unknown language, which should be enough for the ongoing support of H existing SCAN scripts. LSE and SCA support is available to further ease  any development.  G Why is AlphaScan useful? You could VEST the VAXScan compiler to developTD Scan programs on Alpha. But the compiled code will be VAX binaries, I which need also to be VESTed with their RTLs. Some layered products like SB DECforms cannot be VESTed but will require subsitution with Alpha F versions. AlphaScan will allow you to reuse most of the existing Scan < scripts, add the new stuff and generate Alpha code directly.   Robert Boers  Software Resources International   ------------------------------  % Date: Fri, 12 Jul 2002 06:55:51 -07002# From: "Tom Linden" <tom@kednos.com>r& Subject: RE: VAX Scan on OpenVMS Alpha9 Message-ID: <CIEJLCMNHNNDLLOOGNJIIEJIFFAA.tom@kednos.com>    >-----Original Message-----i8 >From: Robert Boers [mailto:robert.boers@softresint.com]$ >Sent: Friday, July 12, 2002 6:25 AM >To: Info-VAX@Mvb.Saic.Com' >Subject: Re: VAX Scan on OpenVMS Alpha  >a >e >To comment on earlier posts:a >tG >No VAX is required anymore with AlphaScan. Yes, we retain the internal H >n-tuples structure of the VAXScan compiler but redo them completely for@ >the Alpha platform. The C code is NOT generated by the n-tuplesC >interpretation but by *parallel* compilation done by the AlphaScan E >compiler in parallel. The C code internal representation is not evenn >visible to the user.O  G Not to beat a dead horse, but that explanation is not very clear.  If IkJ have understood correctly, you have written a program (which happens to be in C) J that interprets the n-tuples.    The n-tuple data structures are certainlyH available in C using SDL.  Have you VESTed the SACN front-end or does it run native on Alpha?  K I don't understand what you mean by parallel compilation with the Alphascane compiler     >eC >AlphaScan will not use embedded Scan support in the Alpha debuggereG >because that support simply doesn't exist in it. We cannot do anything E >about that since introducing this support would require changing ther >Alpha debugger. >LD >The main goal is to be able to use the existing VAXScan code on theA >Alpha platform, not to design Scan language support in the AlphaIE >debugger, as we expect that the focus is more on maintenance than ofu" >developing new Scan applications. > C >The Scan language on Alpha will be supported by the debugger as annD >unknown language, which should be enough for the ongoing support ofH >existing SCAN scripts. LSE and SCA support is available to further ease >any development.s >_H >Why is AlphaScan useful? You could VEST the VAXScan compiler to developD >Scan programs on Alpha. But the compiled code will be VAX binaries,I >which need also to be VESTed with their RTLs. Some layered products like B >DECforms cannot be VESTed but will require subsitution with AlphaF >versions. AlphaScan will allow you to reuse most of the existing Scan= >scripts, add the new stuff and generate Alpha code directly.b >e
 >Robert Boerss! >Software Resources InternationalO >V >---' >Incoming mail is certified Virus Free. ; >Checked by AVG anti-virus system (http://www.grisoft.com). A >Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002  >h ---g& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002   ------------------------------    Date: 12 Jul 2002 09:19:49 -0600- From: Kilgallen@SpamCop.net (Larry Kilgallen)h& Subject: Re: VAX Scan on OpenVMS Alpha3 Message-ID: <2vL$gzNkR$s9@eisner.encompasserve.org>y  ` In article <3D2ED89B.8090002@softresint.com>, Robert Boers <robert.boers@softresint.com> writes:  F > The main goal is to be able to use the existing VAXScan code on the C > Alpha platform, not to design Scan language support in the Alpha tG > debugger, as we expect that the focus is more on maintenance than of -# > developing new Scan applications.   J That viewpoint was not clear in the announcement that started this thread.  E > The Scan language on Alpha will be supported by the debugger as an kF > unknown language, which should be enough for the ongoing support of  > existing SCAN scripts.  I I don't know why you use the term "scripts", but I do get the feeling you H have never made significant changes to an existing complex SCAN program.  E On the other hand, your company will make money from the VAX emulatoreG business for those who need SCAN, especially if you ever go public witha your prices.   ------------------------------  % Date: Fri, 12 Jul 2002 08:22:21 -0700c# From: "Tom Linden" <tom@kednos.com>p& Subject: RE: VAX Scan on OpenVMS Alpha9 Message-ID: <CIEJLCMNHNNDLLOOGNJIMEJNFFAA.tom@kednos.com>    >-----Original Message-----a8 >From: Robert Boers [mailto:robert.boers@softresint.com]$ >Sent: Friday, July 12, 2002 8:23 AM& >To: Tom Linden; Info-VAX@Mvb.Saic.Com' >Subject: RE: VAX Scan on OpenVMS Alphar >e >m >Tom,p >w$ >Your interpretation is not correct. >rC >There is no interpreter of n-tuples. We migrated the SCAN compiler-K >completely to the OVMS/Alpha environment; VESTing procedures are not used.iG >The Bliss code is retained, but the MACRO32 code is either compiled or  >re-written in C.  >2J >We partly migrated the front-end of the VAXScan compiler which deals with= >the SCAN language. We generate our own-designed intermediatea >representation,G >which is similar to the tuples and which then allows us to generate an.> >intermediate representation of the SCAN application in C. The >details of how  >this is done is proprietary.n  L OK, I think it is becomming clearer,  "Similar"  The SCAN front-end producesF a rich set of n-tuples, you have translated those to C, maybe making a	 superset.o! I have understood that correctly?-  I What about the PL/I code of the front-end?  You didn't translate that didi you? >1 >Regards, Robert Boers.O >l >> -----Original Message-----9+ >> From: Tom Linden [mailto:tom@kednos.com]K$ >> Sent: Friday, July 12, 2002 15:56* >> To: Robert Boers; Info-VAX@Mvb.Saic.Com) >> Subject: RE: VAX Scan on OpenVMS Alphaf >> >> >> >> >> >-----Original Message-----; >> >From: Robert Boers [mailto:robert.boers@softresint.com]r' >> >Sent: Friday, July 12, 2002 6:25 AMw >> >To: Info-VAX@Mvb.Saic.Com * >> >Subject: Re: VAX Scan on OpenVMS Alpha >> > >> >  >> >To comment on earlier posts: >> >J >> >No VAX is required anymore with AlphaScan. Yes, we retain the internalK >> >n-tuples structure of the VAXScan compiler but redo them completely forrC >> >the Alpha platform. The C code is NOT generated by the n-tupleslF >> >interpretation but by *parallel* compilation done by the AlphaScanH >> >compiler in parallel. The C code internal representation is not even >> >visible to the user. >>J >> Not to beat a dead horse, but that explanation is not very clear.  If I? >> have understood correctly, you have written a program (whichi >happens to be >> in C)C >> that interprets the n-tuples.    The n-tuple data structures areh
 >certainlyK >> available in C using SDL.  Have you VESTed the SACN front-end or does itV >> run native on Alpha?  >>D >> I don't understand what you mean by parallel compilation with the >> Alphascan >> compilerg >> >> >> >F >> >AlphaScan will not use embedded Scan support in the Alpha debuggerJ >> >because that support simply doesn't exist in it. We cannot do anythingH >> >about that since introducing this support would require changing the >> >Alpha debugger.. >> >G >> >The main goal is to be able to use the existing VAXScan code on the.D >> >Alpha platform, not to design Scan language support in the AlphaH >> >debugger, as we expect that the focus is more on maintenance than of% >> >developing new Scan applications.  >> >F >> >The Scan language on Alpha will be supported by the debugger as anG >> >unknown language, which should be enough for the ongoing support ofmK >> >existing SCAN scripts. LSE and SCA support is available to further easen >> >any development. >> >K >> >Why is AlphaScan useful? You could VEST the VAXScan compiler to developsG >> >Scan programs on Alpha. But the compiled code will be VAX binaries,nL >> >which need also to be VESTed with their RTLs. Some layered products likeE >> >DECforms cannot be VESTed but will require subsitution with AlphapI >> >versions. AlphaScan will allow you to reuse most of the existing ScanX@ >> >scripts, add the new stuff and generate Alpha code directly. >> > >> >Robert Boers$ >> >Software Resources International >> > >> >---a* >> >Incoming mail is certified Virus Free.> >> >Checked by AVG anti-virus system (http://www.grisoft.com).D >> >Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002 >> > >> ---) >> Outgoing mail is certified Virus Free.s= >> Checked by AVG anti-virus system (http://www.grisoft.com).sC >> Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002h >> >t >---' >Incoming mail is certified Virus Free. ; >Checked by AVG anti-virus system (http://www.grisoft.com). A >Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002t >  ---t& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002   ------------------------------  % Date: Fri, 12 Jul 2002 17:25:10 +0200T0 From: Robert Boers <robert.boers@softresint.com>& Subject: Re: VAX Scan on OpenVMS Alpha- Message-ID: <3D2EF4D6.9060404@softresint.com>-  C There is no interpreter of n-tuples. We migrated the SCAN compiler dE completely to the OVMS/Alpha environment; VESTing procedures are not nA used. The Bliss code is retained, but the MACRO32 code is either o compiled or re-written in C.  E We partly migrated the front-end of the VAXScan compiler which deals sB with the SCAN language. We generate our own-designed intermediate H representation, which is similar to the tuples and which then allows us I to generate an intermediate representation of the SCAN application in C. m/ The details of how this is done is proprietary.s   Regards, Robert Boers.   ------------------------------  % Date: Fri, 12 Jul 2002 17:45:44 +0200-0 From: Robert Boers <robert.boers@softresint.com>& Subject: Re: VAX Scan on OpenVMS Alpha- Message-ID: <3D2EF9A8.4060203@softresint.com>s   Tom Linden wrote:g >  >>-----Original Message-----9 >>From: Robert Boers [mailto:robert.boers@softresint.com]0% >>Sent: Friday, July 12, 2002 8:23 AM ' >>To: Tom Linden; Info-VAX@Mvb.Saic.Comh( >>Subject: RE: VAX Scan on OpenVMS Alpha >> >> >>Tom, >>% >>Your interpretation is not correct.R >>D >>There is no interpreter of n-tuples. We migrated the SCAN compilerL >>completely to the OVMS/Alpha environment; VESTing procedures are not used.H >>The Bliss code is retained, but the MACRO32 code is either compiled or >>re-written in C. >>K >>We partly migrated the front-end of the VAXScan compiler which deals withu> >>the SCAN language. We generate our own-designed intermediate >>representation,AH >>which is similar to the tuples and which then allows us to generate an? >>intermediate representation of the SCAN application in C. Ther >>details of how >>this is done is proprietary. >  > N > OK, I think it is becomming clearer,  "Similar"  The SCAN front-end producesH > a rich set of n-tuples, you have translated those to C, maybe making a > superset.g# > I have understood that correctly?: > K > What about the PL/I code of the front-end?  You didn't translate that didt > you? > A The PL/I code (about 30 K lines) is only located in the VAX code o6 generator part, which obviously we don't need anymore.   RB   >>Regards, Robert Boers. >> >> >>>-----Original Message-----u+ >>>From: Tom Linden [mailto:tom@kednos.com]o$ >>>Sent: Friday, July 12, 2002 15:56* >>>To: Robert Boers; Info-VAX@Mvb.Saic.Com) >>>Subject: RE: VAX Scan on OpenVMS Alphae >>>  >>>t >>>r >>>t >>>  >>>>-----Original Message-----; >>>>From: Robert Boers [mailto:robert.boers@softresint.com]a' >>>>Sent: Friday, July 12, 2002 6:25 AMD >>>>To: Info-VAX@Mvb.Saic.Com.* >>>>Subject: Re: VAX Scan on OpenVMS Alpha >>>> >>>>  >>>>To comment on earlier posts: >>>>J >>>>No VAX is required anymore with AlphaScan. Yes, we retain the internalK >>>>n-tuples structure of the VAXScan compiler but redo them completely for C >>>>the Alpha platform. The C code is NOT generated by the n-tuplesdF >>>>interpretation but by *parallel* compilation done by the AlphaScanH >>>>compiler in parallel. The C code internal representation is not even >>>>visible to the user. >>>aJ >>>Not to beat a dead horse, but that explanation is not very clear.  If I? >>>have understood correctly, you have written a program (which  >> >>happens to be  >> >>>in C)C >>>that interprets the n-tuples.    The n-tuple data structures ares >> >>certainly  >>K >>>available in C using SDL.  Have you VESTed the SACN front-end or does itf >>>run native on Alpha?  >>>aD >>>I don't understand what you mean by parallel compilation with the >>>Alphascan >>>compilerm >>>o >>>t >>>aF >>>>AlphaScan will not use embedded Scan support in the Alpha debuggerJ >>>>because that support simply doesn't exist in it. We cannot do anythingH >>>>about that since introducing this support would require changing the >>>>Alpha debugger.T >>>>G >>>>The main goal is to be able to use the existing VAXScan code on thesD >>>>Alpha platform, not to design Scan language support in the AlphaH >>>>debugger, as we expect that the focus is more on maintenance than of% >>>>developing new Scan applications., >>>>F >>>>The Scan language on Alpha will be supported by the debugger as anG >>>>unknown language, which should be enough for the ongoing support of K >>>>existing SCAN scripts. LSE and SCA support is available to further easee >>>>any development. >>>>K >>>>Why is AlphaScan useful? You could VEST the VAXScan compiler to developcG >>>>Scan programs on Alpha. But the compiled code will be VAX binaries, L >>>>which need also to be VESTed with their RTLs. Some layered products likeE >>>>DECforms cannot be VESTed but will require subsitution with AlphaaI >>>>versions. AlphaScan will allow you to reuse most of the existing Scan)@ >>>>scripts, add the new stuff and generate Alpha code directly. >>>> >>>>Robert Boers$ >>>>Software Resources International >>>> >>>>----* >>>>Incoming mail is certified Virus Free.> >>>>Checked by AVG anti-virus system (http://www.grisoft.com).D >>>>Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002 >>>> >>>o >>>---) >>>Outgoing mail is certified Virus Free."= >>>Checked by AVG anti-virus system (http://www.grisoft.com). C >>>Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002o >>>y >> >>---n( >>Incoming mail is certified Virus Free.< >>Checked by AVG anti-virus system (http://www.grisoft.com).B >>Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002 >> >  > ---t( > Outgoing mail is certified Virus Free.< > Checked by AVG anti-virus system (http://www.grisoft.com).B > Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002 >    ------------------------------  % Date: Fri, 12 Jul 2002 09:38:50 -0700<# From: "Tom Linden" <tom@kednos.com>:& Subject: RE: VAX Scan on OpenVMS Alpha9 Message-ID: <CIEJLCMNHNNDLLOOGNJIMEKBFFAA.tom@kednos.com>l   Quite right, my error.   >-----Original Message-----Y8 >From: Robert Boers [mailto:robert.boers@softresint.com]$ >Sent: Friday, July 12, 2002 8:46 AM >To: Info-VAX@Mvb.Saic.Com' >Subject: Re: VAX Scan on OpenVMS Alphae >  >e >Tom Linden wrote: >> >>>-----Original Message-----p: >>>From: Robert Boers [mailto:robert.boers@softresint.com]& >>>Sent: Friday, July 12, 2002 8:23 AM( >>>To: Tom Linden; Info-VAX@Mvb.Saic.Com) >>>Subject: RE: VAX Scan on OpenVMS Alphah >>>p >>>s >>>Tom,s >>>x& >>>Your interpretation is not correct. >>>tE >>>There is no interpreter of n-tuples. We migrated the SCAN compileruC >>>completely to the OVMS/Alpha environment; VESTing procedures aree
 >not used.I >>>The Bliss code is retained, but the MACRO32 code is either compiled or  >>>re-written in C.  >>> L >>>We partly migrated the front-end of the VAXScan compiler which deals with? >>>the SCAN language. We generate our own-designed intermediaten >>>representation,I >>>which is similar to the tuples and which then allows us to generate ana@ >>>intermediate representation of the SCAN application in C. The >>>details of howe >>>this is done is proprietary.o >> >>< >> OK, I think it is becomming clearer,  "Similar"  The SCAN >front-end produceshI >> a rich set of n-tuples, you have translated those to C, maybe making aE >> superset.$ >> I have understood that correctly? >>L >> What about the PL/I code of the front-end?  You didn't translate that did >> you?t >>A >The PL/I code (about 30 K lines) is only located in the VAX code 7 >generator part, which obviously we don't need anymore.- >- >RB  >a >>>Regards, Robert Boers.5 >>>0 >>>r >>>>-----Original Message-----, >>>>From: Tom Linden [mailto:tom@kednos.com]% >>>>Sent: Friday, July 12, 2002 15:56.+ >>>>To: Robert Boers; Info-VAX@Mvb.Saic.Com-* >>>>Subject: RE: VAX Scan on OpenVMS Alpha >>>> >>>> >>>> >>>> >>>> >>>>>-----Original Message-----f< >>>>>From: Robert Boers [mailto:robert.boers@softresint.com]( >>>>>Sent: Friday, July 12, 2002 6:25 AM >>>>>To: Info-VAX@Mvb.Saic.Com+ >>>>>Subject: Re: VAX Scan on OpenVMS Alphan >>>>>  >>>>>r! >>>>>To comment on earlier posts:t >>>>>pK >>>>>No VAX is required anymore with AlphaScan. Yes, we retain the internal L >>>>>n-tuples structure of the VAXScan compiler but redo them completely forD >>>>>the Alpha platform. The C code is NOT generated by the n-tuplesG >>>>>interpretation but by *parallel* compilation done by the AlphaScan I >>>>>compiler in parallel. The C code internal representation is not evenw >>>>>visible to the user.  >>>>K >>>>Not to beat a dead horse, but that explanation is not very clear.  If Il@ >>>>have understood correctly, you have written a program (which >>>a >>>happens to be >>>'	 >>>>in C)dD >>>>that interprets the n-tuples.    The n-tuple data structures are >>>e >>>certainly >>>oL >>>>available in C using SDL.  Have you VESTed the SACN front-end or does it >>>>run native on Alpha? >>>>E >>>>I don't understand what you mean by parallel compilation with thee
 >>>>Alphascan  >>>>compiler >>>> >>>> >>>>G >>>>>AlphaScan will not use embedded Scan support in the Alpha debuggerrK >>>>>because that support simply doesn't exist in it. We cannot do anything I >>>>>about that since introducing this support would require changing thea >>>>>Alpha debugger. >>>>>eH >>>>>The main goal is to be able to use the existing VAXScan code on theE >>>>>Alpha platform, not to design Scan language support in the Alpha I >>>>>debugger, as we expect that the focus is more on maintenance than ofW& >>>>>developing new Scan applications. >>>>>cG >>>>>The Scan language on Alpha will be supported by the debugger as anlH >>>>>unknown language, which should be enough for the ongoing support ofL >>>>>existing SCAN scripts. LSE and SCA support is available to further ease >>>>>any development.A >>>>>nL >>>>>Why is AlphaScan useful? You could VEST the VAXScan compiler to developH >>>>>Scan programs on Alpha. But the compiled code will be VAX binaries,? >>>>>which need also to be VESTed with their RTLs. Some layeredr >products likeF >>>>>DECforms cannot be VESTed but will require subsitution with AlphaJ >>>>>versions. AlphaScan will allow you to reuse most of the existing ScanA >>>>>scripts, add the new stuff and generate Alpha code directly.g >>>>>c >>>>>Robert Boers3% >>>>>Software Resources International: >>>>>0 >>>>>---+ >>>>>Incoming mail is certified Virus Free.0? >>>>>Checked by AVG anti-virus system (http://www.grisoft.com). E >>>>>Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002r >>>>>a >>>> >>>>--- * >>>>Outgoing mail is certified Virus Free.> >>>>Checked by AVG anti-virus system (http://www.grisoft.com).D >>>>Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002 >>>> >>>  >>>---) >>>Incoming mail is certified Virus Free. = >>>Checked by AVG anti-virus system (http://www.grisoft.com).tC >>>Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002n >>>e >> >> ---) >> Outgoing mail is certified Virus Free.h= >> Checked by AVG anti-virus system (http://www.grisoft.com).nC >> Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002t >> >  >s >---' >Incoming mail is certified Virus Free.t; >Checked by AVG anti-virus system (http://www.grisoft.com).mA >Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002t >o ---h& Outgoing mail is certified Virus Free.: Checked by AVG anti-virus system (http://www.grisoft.com).@ Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002   ------------------------------  + Date: Fri, 12 Jul 2002 17:25:59 +0100 (MET)e9 From: Phillip Helbig <HELBPHI@sysdev.deutsche-boerse.com>- Subject: VMS freewareJ; Message-ID: <01KK0K7Z55MY96Y2PR@sysdev.deutsche-boerse.com>F  ? > Hm, it wasn't *that* long-range, Hunters archive is the firsta1 > place I look when searching for VMS freeware...@  F Indeed.  It would be nice if it were the ONLY place one has to look.  I Yes, there are many collections of links to links to links to links...to uE links to other VMS freeware, but it would be nice to have all in one i place.  B For "here's the code---I bequeath this to the world and hope that E someone can use it" type things, surely the BEST solution is to have tD this archived at Hunter's site.  For "maintained" code, there is an H advantage to it having its own site, if there is a lot of supplementary G information and/or if Hunter's site cannot be updated quickly enough.  eF Perhaps in addition to his freeware archive, Hunter (or someone else) F could have The One Big Maintained Page of links to other VMS freeware F packages (LYNX, (La)TeX, OSU HTTP Server etc).  (Many of these run on @ VMS as well as other systems, so a link to a site would be more % appropriate for this reason as well.)   G In other words, whenever a system manager wants to update his freeware  H collection, he just has to have one web page to use as a checklist.  :-)   ------------------------------  % Date: Fri, 12 Jul 2002 11:48:57 -04001 From: norm.raphael@metso.comL Subject: Re: WATCHER (was Re: Command Procedure to logoff inactive users...)? Message-ID: <OF315413A4.46722D0B-ON85256BF4.0056813F@metso.com>r  # I use WATCHER and it calls $FORCEX. E I have found that one of my applications requires that I call $FORCEXj twice to get processes to DCL.H Recently I tried this on the whole user population of that application = andaH found that one of the processes was still not at DCL after this double = hit./ Is there any way to figure out what's going on. F ($FORCEX does not guarantee that a success status has forced an exit.) -Normp      4 Please respond to Jan-Erik S=F6derholm <aaa@aaa.com>   To:    Info-VAX@Mvb.Saic.Com cc:e= Subject:    Re: Command Procedure to logoff inactive users...     2 And WATCHER is the most popular *free* package :-)  < http://vms.process.com/scripts/fileserv/fileserv.com?WATCHER   Jan-Erik S=F6derholm       =s   ------------------------------  % Date: Fri, 12 Jul 2002 18:28:40 +0200c9 From: Jan-Erik =?iso-8859-1?Q?S=F6derholm?= <aaa@aaa.com>yL Subject: Re: WATCHER (was Re: Command Procedure to logoff inactive users...)' Message-ID: <3D2F03B8.DFC41242@aaa.com>   < Any special reason to leave them loggedon at the DCL level ?  0 Why not use /DISCONNECT or /LOGOUT as the defult* ACTION instead of /FORCE_EXIT in WATCHER ?  > And WATCHER used first a FORCEX and then, after a configurable: delay, a DELPRC. If /FORCE_EXIT is set, only the FORCEX is tried.  	 Jan-Erik.        norm.raphael@metso.com wrote:  > % > I use WATCHER and it calls $FORCEX.>G > I have found that one of my applications requires that I call $FORCEXe  > twice to get processes to DCL.L > Recently I tried this on the whole user population of that application andM > found that one of the processes was still not at DCL after this double hit.n1 > Is there any way to figure out what's going on.iH > ($FORCEX does not guarantee that a success status has forced an exit.) > -Normh >e   ------------------------------  % Date: Fri, 12 Jul 2002 13:21:41 -0400S From: norm.raphael@metso.comL Subject: Re: WATCHER (was Re: Command Procedure to logoff inactive users...)? Message-ID: <OF168EA2AD.6A69BCEA-ON85256BF4.005EF766@metso.com>p  H I have them in a DCL menu.  My intent is to "knock them back" to the me= nu.h: There they sit until they need to do some real work again.H The issue for them is not that they are idle on the system, but they ar= erE using up a concurrent license for the application and not doing work.>B So I do not want to totally annoy them by making them login again.? In this case watcher does a FORCEX, then another FORCEX and not:H the DELPRC.  It's just that occasionally even that doesn't force the ex= it.o -Norml        < Jan-Erik S=F6derholm <aaa@aaa.com> on 07/12/2002 12:28:40 PM  4 Please respond to Jan-Erik S=F6derholm <aaa@aaa.com>   To:    Info-VAX@Mvb.Saic.Com cc:>E Subject:    Re: WATCHER (was Re: Command Procedure to logoff inactiven        users...)    < Any special reason to leave them loggedon at the DCL level ?  0 Why not use /DISCONNECT or /LOGOUT as the defult* ACTION instead of /FORCE_EXIT in WATCHER ?  > And WATCHER used first a FORCEX and then, after a configurable: delay, a DELPRC. If /FORCE_EXIT is set, only the FORCEX is tried.  	 Jan-Erik.e       norm.raphael@metso.com wrote:r > % > I use WATCHER and it calls $FORCEX.oH > I have found that one of my applications requires that I call $FORCEX=    > twice to get processes to DCL.H > Recently I tried this on the whole user population of that applicatio= nA andeH > found that one of the processes was still not at DCL after this doubl= eu hit.1 > Is there any way to figure out what's going on. H > ($FORCEX does not guarantee that a success status has forced an exit.= )  > -NormS >            =g   ------------------------------    Date: 12 Jul 2002 09:14:15 -06002 From: cochrane@encompasserve.org (Arthur Cochrane)' Subject: Re: Where to put startup stuff 3 Message-ID: <9r2n51ugovQb@eisner.encompasserve.org>d  @                  -< Where STARTUP.COM converts P1 to MINIMUM. >-P --------------------------------------------------------------------------------: >    The value of P1 passed to SYPAGSWPFILES is MINIMUM orK >    FULL even though the STARTUP_P1 sysgen parameter is "    " or  "MIN ". 3 >    I couldn't find where the translation is done.a     J     It is translated in sys$system:startup.com by the following segment of	     code:      O $stdrv$requests = ",AUDIT_SERVER,CACHE_SERVER,CONFIGURE,CSP,ERRFMT,FULL,JOBCTL">k $stdrv$requests = stdrv$requests + ",MINIMUM,NETWORK,OPCOM,SHADOW_SERVER,SMISERVER,UPGRADE,SECURITY_SERVER"r1 $stdrv$requests = stdrv$requests + ",ACME_SERVER"n* $stdrv$i = f$locate(","+p1,stdrv$requests)) $if stdrv$i .eq. f$length(stdrv$requests)r $theneE $stdrv$say f$fao("%STDRV-F-INVREQ, The parameter !AS is invalid.",P1)  $goto EXIT_FATAL $endif_ $p1 = f$extract(stdrv$i+1,f$locate(",",f$extract(stdrv$i+1,999,stdrv$requests)),stdrv$requests)h     ?     This sets the p1 parameter to the extracted string from the>G     stdrv$requests string above that matches the p1 parameter passed to K     STARTUP.COM or to FULL or MINIMUM based on the STARTUP_P1 paramenter in      SYSGEN.m     A     So if STARTUP_P1 is MIN after the above code P1 passed to thea.     SYS$MANAGER:SY*.COM procedures is MINIMUM.     >                    -< P1 set to FULL if STARTUP_P1 is Null. >-P --------------------------------------------------------------------------------K >    I can see how that section translates MIN to MINIMUM but not "    " tou
 >    FULL.     C     That is easy. Below is some of the lines from the first part ofMJ     SYS$SYSTEM:STARTUP.COM which sets the P1-P8 parameters from the SYSGENB     parameters STARTUP_P1-STARTUP_P8. But in the code if P1 (i.e.,0     STARTUP_P1) is null then p1 is set to "FULL"          # $if p1 .nes. "" then goto got_param-2 $p1 = f$edit(f$getsyi("STARTUP_P1"),"TRIM,UPCASE")  $if p1 .eqs. "" then p1 = "FULL"2 $p2 = f$edit(f$getsyi("STARTUP_P2"),"TRIM,UPCASE")2 $p3 = f$edit(f$getsyi("STARTUP_P3"),"TRIM,UPCASE")2 $p4 = f$edit(f$getsyi("STARTUP_P4"),"TRIM,UPCASE")2 $p5 = f$edit(f$getsyi("STARTUP_P5"),"TRIM,UPCASE")2 $p6 = f$edit(f$getsyi("STARTUP_P6"),"TRIM,UPCASE")2 $p7 = f$edit(f$getsyi("STARTUP_P7"),"TRIM,UPCASE")2 $p8 = f$edit(f$getsyi("STARTUP_P8"),"TRIM,UPCASE") $got_param:>   ------------------------------  # Date: Fri, 12 Jul 2002 17:43:40 GMTo1 From: "Terry C. Shannon" <terryshannon@attbi.com>i1 Subject: Re: XP1000 667Mhz USD2995 !!!!! IncomingN; Message-ID: <gzEX8.13325$uw.7382@rwcrnsc51.ops.asp.att.net>a   Not a bad deal at all...  . "Island" <sales@islandco.com> wrote in message) news:uim1jd5ddshc5a@news.supernews.com...n$ > Order now - only 30 coming in !!!! >a >r > Configured as follows: >  > XP1000 667Mhz 4MB Cachen > 1GB Memory > 18GB Disk Drivef > CDROMo' > 3DLabs VX1 Oxygen 32MB PCI Video Carda > Floppy
 > Keyboard > Mouseu >a
 > Only $2995*oG > (*FYI - the cpu daughter card - dealer to dealer price is over $3000)h >a >i. > Add a new Viewsonic E70 17" Monitor for $230 > (Not flatpanel)  >t >p > -- > David B Turner > Sales Dpta! > Island Computers US Corporationn > 2700 Gregory Streetp > Suite 180u > Savannah GA 31404> > Tel: 912 447 6622> > Fax: 912 201 0096s > sales@islandco.com > www.islandco.com) > http://www.islandco.com/legal-email.htmg >c > We sell Alpha's !n, > All emails are checked for Virus and Worms >o >    ------------------------------   End of INFO-VAX 2002.381 ************************