INFO-VAX Sun, 03 Jun 2007 Volume 2007 : Issue 301 Contents: Re: Anyone know why the Alpha market is so so quiet? Re: Anyone know why the Alpha market is so so quiet? Re: HP wasting millions of dollars on itanium! Re: HP wasting millions of dollars on itanium! Re: HP wasting millions of dollars on itanium! Re: HP wasting millions of dollars on itanium! Re: HP wasting millions of dollars on itanium! Re: HP wasting millions of dollars on itanium! Re: HP wasting millions of dollars on itanium! Re: HP wasting millions of dollars on itanium! Re: Infoserver 150 woes Re: Infoserver 150 woes Re: Infoserver 150 woes Re: Infoserver 150 woes Re: Paging and process state Re: Paging and process state Re: Paging and process state Re: Paging and process state Re: Paging and process state Re: Paging and process state Re: SSH port scanners Re: Upgrade to Vista from XP ? Yes or No ---------------------------------------------------------------------- Date: Sat, 02 Jun 2007 14:32:39 -0500 From: David J Dachtera Subject: Re: Anyone know why the Alpha market is so so quiet? Message-ID: <4661C5D7.7ADE4C11@spam.comcast.net> "Main, Kerry" wrote: > > > -----Original Message----- > > From: ultradwc@gmail.com [mailto:ultradwc@gmail.com] > > Sent: June 1, 2007 6:23 PM > > To: Info-VAX@Mvb.Saic.Com > > Subject: Re: Anyone know why the Alpha market is so so quiet? > > > > On May 15, 4:28 pm, "Main, Kerry" wrote: > > > > -----Original Message----- > > > > From: John Smith [mailto:a...@nonymous.com] > > > > Sent: May 15, 2007 2:05 PM > > > > To: Info-...@Mvb.Saic.Com > > > > Subject: Re: Anyone know why the Alpha market is so so quiet? > > > > > > [snip...] > > > > > > > > > > > > > So how many of your customers are doing DC consolidation onto VMS? > > > > > > Customer doing large DC / IT Consolidation are typically risk > > adverse > > > and are under extreme pressures to get it done quickly. Hence the > > > typical strategy is to do like-like platforms consolidation e.g. > > OpenVMS > > > to OpenVMS, Windows to Windows (on VMware where appropriate), Linux > > to > > > Linux, AIX to AIX etc. > > > > and these same customers are tired of being part of the patch > > of the day club, and would move if given a superior alternative ... > > > > however, HP will not market OpenVMS and actually try to sell > > it ... they have relegated VMS to current customer support or > > if forced to sell it ... instead they push their garbage unix which > > what everyone would like to get away from ... > > > > so the above condition is largely true because HP will not sell > > and market VMS to NEW customers, so what other choice do > > they have? > > . > > So the recent announcement of OpenVMS support for Intel based blade > servers is a sign HP does not value OpenVMS? ...to those customers with long-term contractual commitments from OpenVMS, yes. To the market at large (where the *REAL* profits are), no. > [snip] > [insert "yeah, but they should be doing better marketing" comments > here..] As you wish, except that before they can do BETTER marketing they first need to do SOME marketing, then the quality of what they do (currently nothing) can be assessed and evaluated. Think of it as a universal constant: people won't buy, inquire about, etc. what they don't know about. Find a way around THAT one, and you'll rank right up there with the inventors of the perpetual motion machine, the non-battery electrically powered vehicle, cheap/safe recycling of nuclear waste, ... -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Sat, 02 Jun 2007 23:35:24 -0500 From: Ron Johnson Subject: Re: Anyone know why the Alpha market is so so quiet? Message-ID: On 06/02/07 14:32, David J Dachtera wrote: [snip] > cheap/safe recycling of nuclear waste, ... It all depends on your thresholds for cheapness and safety. http://en.wikipedia.org/wiki/Nuclear_Power#Reprocessing http://en.wikipedia.org/wiki/Nuclear_reprocessing -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Sat, 02 Jun 2007 14:49:42 -0400 From: JF Mezei Subject: Re: HP wasting millions of dollars on itanium! Message-ID: <815d0$4661bbf2$cef8887a$8764@TEKSAVVY.COM> Arne Vajhøj wrote: > A 16 core 45 nm EV7 would not be an EV7. Is it correct to state that EV7 is really an EV6 core inside ? When designing a chip, is there a rough percentage of the work required to do the core versus the anciliary stuff (memory controller, cache, IO, packaging) ? I.E. if you don't redesign the core, does that save you much ? ------------------------------ Date: 2 Jun 2007 21:02:59 +0200 From: peter@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) Subject: Re: HP wasting millions of dollars on itanium! Message-ID: <4661db03$1@news.langstoeger.at> In article <46619dcb$0$90267$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: >> "I would say that today's Itanium is so far behind today that it is not that >> interesting for anyone except those strongly tied to Itanium." > >No. If you go an look at SPEC benchmarks then you see that it is not so. Please enlighten. I see it not as you. How does a Itanic compare to a x86(-64) or a POWER6? In performance and price/performace. Or did you mean to compare it with an Alpha? How unfair at now 6 years distance... >The new Itaniums are much faster than Alpha (not a big surprise >considering that they are much newer). But the comparision to the Alpha was not intended above. The intention was to compare the Itanics with the other *current* chips. A similarity with the Alpha, not a comparison. The intention was to look at Itanic compared to other current chips just as Alpha compared to other then current chips in 2001 which led to the death of Alpha (because said to be "way behind in price/performance" and "niche product") just as the Itanic ('will die, cause of the same facts'). >> So where's the difference (even if you believe that Itanium is competitive >> in either price, performance or price-performance...). > >The difference is that Itanium is being developed and are trying to >keep up with the x86's while Alpha was stopped many years ago. Again, you seem to misunderstood. -- Peter "EPLAN" LANGSTOEGER Network and OpenVMS system specialist E-mail peter@langstoeger.at A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist ------------------------------ Date: Sat, 02 Jun 2007 15:10:36 -0400 From: JF Mezei Subject: Re: HP wasting millions of dollars on itanium! Message-ID: <87fe7$4661c0d8$cef8887a$31590@TEKSAVVY.COM> Arne Vajhøj wrote: >> "I would say that today's Itanium is so far behind today that it is not that >> interesting for anyone except those strongly tied to Itanium." > > No. If you go an look at SPEC benchmarks then you see that it is not so. While it is true that IA64 has closed the gap since the days of Merced, I would not say it is a "market leading" technology. For one thing, it is not first to market with features. Power or even Sparc is, and the 8086 is also starting to get to market with features IA64 doesn't yet have. (The CSI being a key one this year, and it isn't even a given that HP will be using the CSI for IA64, but would be using it for its industry standard servers). Also, there is a limit to increasing performance by adding cache. There comes a point where more cache isn't going to make much of a difference. (if you have 2 gigs of RAM, having 3 gigs of cache won't give you anything over having 2 gigs of cache). The other important factor is that other architectures, notably the 8086 are seeing accelerations in their product cycles while IA64 is seeing new iterations further and further apart from each other. Intel won't even mention timeframes for Poulson. Last year, Intel admitted IA64 was not profitable. Is there really much of a point to sink so much money on chip design and compilers for a money losing chip nobody wants ? It didn't take that long for Intel to produce a 64 bit 8086 once AMD's 64 bit offering became very credible. And it won't take that long for Intel to produce an 64 bit 8086 with whatever features are needed to get the 8086 into the enterprise server market in a serious way. If all that is left to differentiate IA64 is its "RAS" features, then gess what happens when AMD produces a server 8086 chip with all those RAS features in it ? Intel will have to follow with its own 8086 with RAS features. If you look at C class blades, those are really designed for 8086s, with IA64 being and aftertought. And all those management and RAS features (such as double power supplies etc) benefit 8086 board just as much as they do IA64. And if you made 8086s with EFI, you'd have pretty much the same booting environment as IA64. (And doesn't Apple use EFI for its 8086 based machines ?) Ask yourself this, what features would an 8086 architecture chip need to be able to be used as a building block for a Superdome that would equal and outperform an IA64 based supedome ? Once Intel adds those features to its 8086 product line, HP will have no reason to continue to build IA64 based superdomes. Intel might wish to delay adding those features as long as possible to delay the inevitable IA64 retirement announcement, but it is a matter of a year or two anyways. As soon as AMD starts to add those features, Intel must fillow suit. Remember that IA64 has a very small installed base. Smaller than Alpha. And definitely smaller than PaRisc. ------------------------------ Date: Sat, 02 Jun 2007 15:12:50 -0500 From: David J Dachtera Subject: Re: HP wasting millions of dollars on itanium! Message-ID: <4661CF42.2A4014D2@spam.comcast.net> Arne Vajhøj wrote: > > Bill Todd wrote: > > Arne Vajhøj wrote: > >> I would say that EV7 is so far behind today that it is not that > >> interesting for anyone except those strongly tied to Alpha. > > > > While I agree that the chances of seeing Alpha resurrected are > > indistinguishable from zero (and have been since HP bought Compaq - > > before that, there was at least *some* hope that Curly could either be > > forced to see reason or given the boot, and Alpha restarted), you really > > shouldn't confuse being behind in technology (which EV7 is not) with > > just being behind in implementation (which EV7 certainly is: most of > > the competition is three full process generations beyond 180 nm. now, > > and Intel is about to make that four full generations with Penryn). > > > > EV7's multi-chip interconnect technology has yet to be matched (Intel > > *may* do so in late 2008/early 2009 when CSI finally appears; POWER has > > gotten a lot closer with the release of POWER6, but my impression is > > still doesn't have the raw aggregate large-system bandwidth that EV7 > > has). EV7's on-chip memory control is at least on a par with the best > > current offerings (those that have on-chip memory support at all). And > > even EV7's raw core performance is no slouch, given the handicap of > > being those three process generations behind now: if you don't want to > > wait for it to be upgraded at least to EV8 standards, just introduce the > > new model in 45 nm. with 16 cores as a stop-gap for throughput-intensive > > applications (I suspect that would give Rock a good run for its money). > > > > Nah, it'll never happen, but not because Alpha couldn't compete - even > > now. As for where it could be if development had continued, well... > > A 16 core 45 nm EV7 would not be an EV7. (Donning dental smock) ..., it would be _______________. (Fill in the blank.) -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Sat, 02 Jun 2007 20:51:53 -0400 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: HP wasting millions of dollars on itanium! Message-ID: <466210a3$0$90267$14726298@news.sunsite.dk> Peter 'EPLAN' LANGSTOeGER wrote: > In article <46619dcb$0$90267$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= writes: >>> "I would say that today's Itanium is so far behind today that it is not that >>> interesting for anyone except those strongly tied to Itanium." >> No. If you go an look at SPEC benchmarks then you see that it is not so. > > Please enlighten. I see it not as you. > How does a Itanic compare to a x86(-64) or a POWER6? > In performance and price/performace. > > Or did you mean to compare it with an Alpha? > How unfair at now 6 years distance... >> The new Itaniums are much faster than Alpha (not a big surprise >> considering that they are much newer). > > But the comparision to the Alpha was not intended above. > The intention was to compare the Itanics with the other *current* chips. > A similarity with the Alpha, not a comparison. > > The intention was to look at Itanic compared to other current chips > just as Alpha compared to other then current chips in 2001 which led > to the death of Alpha (because said to be "way behind in price/performance" > and "niche product") just as the Itanic ('will die, cause of the same facts'). > I objected to a post claiming that Itanium is behind todays CPU's similar to Alpha. I was comparing Alpha with todays CPU's and he claimed that same could be said about Itanium. And that is not the case. If that was the case then a 2007 Itanium would indeed be comparable to the last Alphas. >>> So where's the difference (even if you believe that Itanium is competitive >>> in either price, performance or price-performance...). >> The difference is that Itanium is being developed and are trying to >> keep up with the x86's while Alpha was stopped many years ago. > > Again, you seem to misunderstood. No. I did compare Alpha with todays CPU's. Which should also be obvious from the context (starting EV7 again). I can not say that John W thought I were comparing Alpha with other 2001 CPU's. But: - I do not see any basis for that hypothesis - if it was the case it would be him misunderstanding Arne ------------------------------ Date: Sat, 02 Jun 2007 20:53:29 -0400 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: HP wasting millions of dollars on itanium! Message-ID: <46621101$0$90267$14726298@news.sunsite.dk> JF Mezei wrote: > Arne Vajhøj wrote: >>> "I would say that today's Itanium is so far behind today that it is >>> not that >>> interesting for anyone except those strongly tied to Itanium." >> >> No. If you go an look at SPEC benchmarks then you see that it is not so. > > While it is true that IA64 has closed the gap since the days of Merced, > I would not say it is a "market leading" technology. Nobody said so. I just said that a brandnew Itanium is not behind todays CPU's as a 2001 Alpha is. Arne ------------------------------ Date: Sat, 02 Jun 2007 23:39:56 -0500 From: Ron Johnson Subject: Re: HP wasting millions of dollars on itanium! Message-ID: On 06/02/07 14:10, JF Mezei wrote: [snip] > 8086 is also starting to get to market with features IA64 doesn't yet Why do you insist on referring to x86-64 chips as 8086? If it's an attempt at a back-handed insult, then it's spectacularly outdated and lame. -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Sun, 03 Jun 2007 01:43:14 -0400 From: Bill Todd Subject: Re: HP wasting millions of dollars on itanium! Message-ID: Ron Johnson wrote: > On 05/31/07 22:41, Bill Todd wrote: >> Arne Vajhøj wrote: >> >> ... >> >>> I would say that EV7 is so far behind today that it is not that >>> interesting for anyone except those strongly tied to Alpha. >> >> While I agree that the chances of seeing Alpha resurrected are >> indistinguishable from zero (and have been since HP bought Compaq - >> before that, there was at least *some* hope that Curly could either be >> forced to see reason or given the boot, and Alpha restarted), you >> really shouldn't confuse being behind in technology (which EV7 is not) >> with just being behind in implementation (which EV7 certainly is: >> most of the competition is three full process generations beyond 180 >> nm. now, and Intel is about to make that four full generations with >> Penryn). >> >> EV7's multi-chip interconnect technology has yet to be matched (Intel >> *may* do so in late 2008/early 2009 when CSI finally appears; POWER >> has gotten a lot closer with the release of POWER6, but my impression >> is still doesn't have the raw aggregate large-system bandwidth that >> EV7 has). EV7's on-chip memory control is at least on a par with the >> best current offerings (those that have on-chip memory support at >> all). And even EV7's raw core performance is no slouch, given the >> handicap of being those three process generations behind now: if you >> don't want to wait for it to be upgraded at least to EV8 standards, >> just introduce the new model in 45 nm. with 16 cores as a stop-gap for >> throughput-intensive applications (I suspect that would give Rock a >> good run for its money). > > How is this better/different than AMD's Direct Connect Architecture and > HORUS Interconnect? 1. AMD's on-chip memory controller does not IIRC support as much memory per chip, as much memory bandwidth per chip (though I'd have to check to see where their recent migration to DDR-2 changed this), or (mirrored or parity) redundant memory. 2. Opterons have at most 3 Hypertransport links per chip, at least some chips have to use one of theirs to talk with something equivalent to Northbridge/Southbridge components (i.e., to talk with something besides other Opterons so that real-world work can be performed), and inter-chip cache coherence uses broadcast invalidation for its operation (which scales poorly beyond 4 sockets in this configuration). The result is that Opteron systems don't scale at all linearly beyond 4 sockets. EV7 has four inter-chip links (each with significantly greater bandwidth than a HT 1 link IIRC) per chip, plus an additional per-chip path to talk with peripherals, and use a directory-based cache-coherence protocol (which scales *far* better). The result is that EV7s scale effectively (almost linearly) to 64 (nominally, perhaps in fact 128) sockets. 3. Horus uses some ingenuity to add something resembling a directory-based cache-coherence protocol to connect quad-socket Opteron boards together, allowing a system to scale up to 32 sockets at least somewhat effectively (though still hardly linearly and with far less aggregate system internal bandwidth than and EV7 system). Horus, however, AFAICT never actually had a real commercial release (i.e., it does not exist as a competitive product, merely as a very interesting prototype). 4. Within a year Opteron is supposed to get HT 3.0, with four HT links (or optionally eight HT half-links) per chip (the latter allowing 8-socket systems with direct single-hop paths between all sockets). Even with its hard-to-scale broadcast-invalidate cache-coherence protocol this should support effective 8-socket Opteron systems (unlike the situation at present), though still somewhat bandwidth-constrained (half of even a significantly faster HT 3.0 link may not equal EV7's facilities, and in any event won't scale nearly at high). 5. Significant portions of the Horus team now work for AMD - but I have no idea what that may or may not imply for the more distant future. The bottom line is that Opteron's approach at present (and even as touted for the near future) may well make economic sense for its target market (small multi-socket systems now, perhaps solid mid-range multi-socket systems next year), but in no way compares with EV7's. - bill ------------------------------ Date: Sat, 02 Jun 2007 19:31:18 GMT From: Curtis Rempel Subject: Re: Infoserver 150 woes Message-ID: Ian King wrote: > On 6/1/2007 3:28:04 PM, Curtis Rempel wrote: >> Ian King wrote: >> >> > I swear this thing used to work, but when I fired up my Infoserver 150 >> > a couple of days ago, it did not boot. I've poked about and tried a few >> > things, and now I'm going to turn to the Collective Wisdom to see if >> > anyone has any suggestions (other than using it as a boat anchor). >> >> [ snip ] >> >> Check the boot flags, it might have a case of amnesia: >> >> >>> SHOW BFLG >> >> If it's empty, set it using: >> >> >>> SET BFLG D0000000 >> >> Try booting DKA0 and see what happens. I have a 150 too and if it is >> left powered off for too long, it forgets what to do. >> >> Curtis >> > > Thank you thank you thank you! That did the trick! Interestingly, that > flag isn't really 'documented' in any InfoServer literature I could find - > mentioned, but not discussed or described. Have a look in the "InfoServer System Operations Guide", order number AA-PJXJC-TE. Mine is October 1994. Pages 5-16 and 5-17 in the troubleshooting section talk about the boot flags. Glad to hear you've revived the patient! > > And thanks to the other folks - especially Hoff - who offered help > offline. -- Ian > ------------------------------ Date: Sat, 02 Jun 2007 15:02:10 -0500 From: Dan Foster Subject: Re: Infoserver 150 woes Message-ID: In article , Curtis Rempel wrote: >> >> Thank you thank you thank you! That did the trick! Interestingly, >> that flag isn't really 'documented' in any InfoServer literature I >> could find - mentioned, but not discussed or described. > > Have a look in the "InfoServer System Operations Guide", order number > AA-PJXJC-TE. Mine is October 1994. Pages 5-16 and 5-17 in the > troubleshooting section talk about the boot flags. That particular manual (also October 1994) can be found here: http://www1.aclabs.com/MasterIndex/installation_guide/installation_guide_006a2764.txt Just bring up this document then do a browser search function for '5-16' and you'll quickly land on the correct spot. I *highly* recommend Curtis and other interested people consider saving a copy of this locally as this stuff is becoming non-easy to find as time goes on. They also have a huge number of manuals for various non-current VMS stuff also in text format, just one step higher in the URL hierarchy. That's about 1,400 manuals comprising about 200 MB. Most of them are from the late '80s and early '90s, though there are some from later. -Dan P.S. Thank you, AC Labs. P.P.S. Thank you, Digital. P.P.P.S. Thank you, FSF (for the GNU project and wget). ------------------------------ Date: Sat, 02 Jun 2007 15:20:27 -0500 From: David J Dachtera Subject: Re: Infoserver 150 woes Message-ID: <4661D10B.5682FEE2@spam.comcast.net> Ian King wrote: > > On 6/1/2007 3:28:04 PM, Curtis Rempel wrote: > > Ian King wrote: > > > > > I swear this thing used to work, but when I fired up my Infoserver 150 a > > > couple of days ago, it did not boot. I've poked about and tried a few > > > things, and now I'm going to turn to the Collective Wisdom to see if > > > anyone has any suggestions (other than using it as a boat anchor). > > > > [ snip ] > > > > Check the boot flags, it might have a case of amnesia: > > > > >>> SHOW BFLG > > > > If it's empty, set it using: > > > > >>> SET BFLG D0000000 > > > > Try booting DKA0 and see what happens. I have a 150 too and if it is left > > powered off for too long, it forgets what to do. > > > > Curtis > > > > Thank you thank you thank you! That did the trick! Interestingly, that flag > isn't really 'documented' in any InfoServer literature I could find - > mentioned, but not discussed or described. > > And thanks to the other folks - especially Hoff - who offered help offline. It would helpful for those Googling this group if you could post some of the useful off-line info you received. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ Date: Sun, 03 Jun 2007 00:36:49 -0500 From: Ron Johnson Subject: Re: Infoserver 150 woes Message-ID: On 06/02/07 15:02, Dan Foster wrote: > In article , Curtis Rempel wrote: >>> Thank you thank you thank you! That did the trick! Interestingly, >>> that flag isn't really 'documented' in any InfoServer literature I >>> could find - mentioned, but not discussed or described. >> Have a look in the "InfoServer System Operations Guide", order number >> AA-PJXJC-TE. Mine is October 1994. Pages 5-16 and 5-17 in the >> troubleshooting section talk about the boot flags. > > That particular manual (also October 1994) can be found here: > > http://www1.aclabs.com/MasterIndex/installation_guide/installation_guide_006a2764.txt > > Just bring up this document then do a browser search function for '5-16' > and you'll quickly land on the correct spot. I *highly* recommend Curtis > and other interested people consider saving a copy of this locally as > this stuff is becoming non-easy to find as time goes on. > > They also have a huge number of manuals for various non-current VMS > stuff also in text format, just one step higher in the URL hierarchy. > > That's about 1,400 manuals comprising about 200 MB. Most of them are > from the late '80s and early '90s, though there are some from later. This command should mirror the site, converting the links to local references. Note the "www1" is not "www", and that since it goes up a higher level, it also downloads a bunch of large zip files. $ wget -m -k -L -np http://www1.aclabs.com/ > -Dan > > P.S. Thank you, AC Labs. > P.P.S. Thank you, Digital. > P.P.P.S. Thank you, FSF (for the GNU project and wget). -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Sat, 02 Jun 2007 14:46:43 -0400 From: JF Mezei Subject: Re: Paging and process state Message-ID: IanMiller wrote: > by looking at the process you may be altering its state. Shirley the VMS engineers had been able to overcome the Eisenburg principle when they designed VMS ? What good is the SHOW PROC/CONT's "State" if the mere act of looking at its state changes it ? ------------------------------ Date: Sat, 02 Jun 2007 14:11:35 -0500 From: Dan Foster Subject: Re: Paging and process state Message-ID: In article <1180796049.348259.12720@w5g2000hsg.googlegroups.com>, IanMiller wrote: > by looking at the process you may be altering its state. How so? One could avoid calling $GETJPI in a way that could cause an inswap -- by specifying JPI$M_NO_TARGET_INSWAP. Unless you are referring to other uses of $GETJPI that causes a process state change? -Dan ------------------------------ Date: Sat, 02 Jun 2007 19:46:06 -0000 From: IanMiller Subject: Re: Paging and process state Message-ID: <1180813566.326813.293540@p47g2000hsd.googlegroups.com> The process will be in PFW when waiting for the pages but this can be short lived which is why you may not see it. My comment was was that some ways of obtaining information about a process involve sending a special kernel mode AST which does wake up the process. I don't know what SHOW PROCESS/CONT does. ------------------------------ Date: Sat, 02 Jun 2007 23:35:08 +0200 From: "P. Sture" Subject: Re: Paging and process state Message-ID: In article <1180813566.326813.293540@p47g2000hsd.googlegroups.com>, IanMiller wrote: > The process will be in PFW when waiting for the pages but this can be > short lived which is why you may not see it. > > My comment was was that some ways of obtaining information about a > process involve sending a special kernel mode AST which does wake up > the process. > I don't know what SHOW PROCESS/CONT does. SHOW PROCESS/CONT certainly does enough to cause a swapped out process to enter the balance set. -- Paul Sture ------------------------------ Date: Sat, 02 Jun 2007 23:38:25 +0200 From: "P. Sture" Subject: Re: Paging and process state Message-ID: In article , JF Mezei wrote: > IanMiller wrote: > > by looking at the process you may be altering its state. > > > Shirley the VMS engineers had been able to overcome the Eisenburg > principle when they designed VMS ? > > What good is the SHOW PROC/CONT's "State" if the mere act of looking at > its state changes it ? You can put VMS into quantum physics, but you can't take the quantum out of VMS. -- Paul Sture ------------------------------ Date: Sat, 02 Jun 2007 20:56:44 -0500 From: Ron Johnson Subject: Re: Paging and process state Message-ID: On 06/02/07 16:38, P. Sture wrote: > In article , > JF Mezei wrote: > >> IanMiller wrote: >>> by looking at the process you may be altering its state. >> >> Shirley the VMS engineers had been able to overcome the Eisenburg >> principle when they designed VMS ? >> >> What good is the SHOW PROC/CONT's "State" if the mere act of looking at >> its state changes it ? > > You can put VMS into quantum physics, but you can't take the quantum out > of VMS. Boo hiss!!! -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! ------------------------------ Date: Sat, 02 Jun 2007 23:29:40 +0200 From: "P. Sture" Subject: Re: SSH port scanners Message-ID: In article <00A68872.7A9662E1@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG wrote: > >> $ tcpip disable service ssh > >> $ tcpip set noservice ssh > >> $ tcpip set service ssh /port=2222 /proc=tcpip$ssh/user=tcpip$ssh - > >> _$ /file=tcpip$system:tcpip$ssh_run.com /proto=tcp/limit=10000 - > >> _$ /log=(all,file=tcpip$ssh_device:[tcpip$ssh]tcpip$ssh_run.log) > >> $ tcpip enable service ssh > >> For completeness, I've just compared that with the contents of TCPIP$CONFIG.COM, and the only significant addition that suggests is /reject=message="TCPIP SSH Connection refused" > The > > $ tcpip set noservice ssh > > will query the user with a prompt: > > Service Port Proto Process Address State > > SSH 22 TCP TCPIP$SSH 0.0.0.0 Disabled > Remove? [N]: > > Thus, when you put it into a command procedure this behavior required that > you assign input to come from SYS$COMMAND and not the command procedure. I > don't see any documented qualifer which would turn off this "Micro$oft-like > are-you-sure?" query. > /noconfirm is valid here. (buried in the help for Caveat: The service name accepts wildcards. > > >> I usually put mine at a higher port (22022). > > > >To make life harder for port scanners? > > It doesn't make it any harder. However, higher ports are usually utilized > by clients connecting to external services. The lower port numbers are the > (typically) defined server ports. If you look at the URL I posted several > day ago in the substandard disaster recovery product thread, you will see a > fairly dense population of port numbers defined below 10K. While it is not > a guarantee that a port scanner will NOT find your ssh server, I have found > that my ssh server has been left alone since I started putting that port at > 22022. Understood, thanks. -- Paul Sture ------------------------------ Date: Sat, 02 Jun 2007 15:17:35 -0500 From: David J Dachtera Subject: Re: Upgrade to Vista from XP ? Yes or No Message-ID: <4661D05F.B6810998@spam.comcast.net> Dirk Munk wrote: > > Chris Sharman wrote: > > Katie Tam wrote: > >> Should I upgrade my laptop to Vista ? Good or Bad? > >> > >> Please advise > >> > >> Katie Tam > >> Network Administrator > >> http://www.linkwaves.com/main.asp > >> http://www.linkwaves.com/ > > > > For safety, use vmware. > > > > First install your favourite linux (I use ubuntu 6.10). > > Install vmware server. > > Then you can install xp, vista, and for that matter 2000, 98, 95 and > > anything else you need for compatibility. > > You can run any (or all) of them, each in their own little sandbox. > > > > The only thing that's missing is VMS :( > > Of course not. There are VAX and Alpha emulators that run on Windows. I > know that (at least) the VAX version is even supported by HP. I think it would be safer to say that VMS is supported on those VAX/Alpha emulators validated by OpenVMS Engineering. To my knowledge, HP does not support any of the various CPU emulators. -- David J Dachtera dba DJE Systems http://www.djesys.com/ Unofficial OpenVMS Marketing Home Page http://www.djesys.com/vms/market/ Unofficial Affordable OpenVMS Home Page: http://www.djesys.com/vms/soho/ Unofficial OpenVMS-IA32 Home Page: http://www.djesys.com/vms/ia32/ Unofficial OpenVMS Hobbyist Support Page: http://www.djesys.com/vms/support/ ------------------------------ End of INFO-VAX 2007.301 ************************