INFO-VAX Sat, 02 Jun 2007 Volume 2007 : Issue 300 Contents: RE: Anyone know why the Alpha market is so so quiet? Re: CDC software (formerly known as Ross Systems) to drop Gembase VMS support 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: OpenVMS on AlphaPC Paging and process state Re: Paging and process state Re: SSH port scanners Re: SSH port scanners Re: SYSMAN problem Re: Upgrade to Vista from XP ? Yes or No Re: VMS Update going out tomorrow ---------------------------------------------------------------------- Date: Sat, 2 Jun 2007 11:02:28 -0400 From: "Main, Kerry" Subject: RE: Anyone know why the Alpha market is so so quiet? Message-ID: > -----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? >=20 > 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. >=20 > and these same customers are tired of being part of the patch > of the day club, and would move if given a superior alternative ... >=20 > 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 ... >=20 > 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? And OpenVMS based Intel blade system clusters makes for some real interesting solutions for Customers tired of the monthly security patches associated with other platforms. Reference: http://h71000.www7.hp.com/openvms/cclass_support.html "HP is pleased to announce that as of 1 June 2007 OpenVMS version 8.3 supports HP BladeSystems c-Class (BL860c). The HP BladeSystem c-Class was designed from the ground up to deliver the future of scalable infrastructure design today-a clean-slate design and significant leap forward. The HP BladeSystem c-Class portfolio takes advantage of the best technologies across HP and brings them together to fundamentally improve how customers buy, manage, and use their computing resources. HP BladeSystem c-Class infrastructure offers flexibility and scalability by allowing customers to manage server, storage, networking, and power management as a unified environment.=20 OpenVMS base system support for BladeSystems c-Class includes the following features:=20 - Server BladeSystem (all processor speeds) - c7000 enclosure and HP Onboard Administration - Three PCIe mezzanine I/O slots plus core I/O [insert "yeah, but they should be doing better marketing" comments here..] Regards Kerry Main Senior Consultant HP Services Canada Voice: 613-592-4660 Fax: 613-591-4477 kerryDOTmainAThpDOTcom (remove the DOT's and AT)=20 OpenVMS - the secure, multi-site OS that just works. ------------------------------ Date: Sat, 02 Jun 2007 07:45:43 -0700 From: IanMiller Subject: Re: CDC software (formerly known as Ross Systems) to drop Gembase VMS support Message-ID: <1180795543.509584.301750@g4g2000hsf.googlegroups.com> What did CDC say when you contacted them about this? ------------------------------ Date: Sat, 02 Jun 2007 08:55:11 +0200 From: Dirk Munk Subject: Re: HP wasting millions of dollars on itanium! Message-ID: JF Mezei wrote: > Bill Todd wrote: >> And the decision they made was obvious (and pretty much irrevocable - >> that's what "burning your boats" *means*) years ago: I'm not quite >> sure how you managed to miss it but that's your problem, not anyone >> else's. > > La Carly made the decision for fame and glitz. Now that HP is under new > management, it had an opportunity to declare IA64 a mistake right away > and work to keep its customers until the original premise is made: move > your OS to industry standard commodity architecture. > > Losing 30% of your customer base does not sound like a > winning/acceptable proposition to me. Business should come before > stroking of egos of Intel, Microsoft and LaCarly. Let's try to place the whole thing in a historical context. In the late 80's, early 90's, Intel decided that it wanted to go for a new 64 bit architecture to replace the x86 32 bit architecture. In itself not a bad idea, since it would give them the opportunity to leave all the old x86 design faults behind them and start all over again. At the about the same HP came to the conclusion that their PA Risc architecture was nearing its design limits, so they needed something new as well. The two joined up, and started to design a new architecture that included PA Risc backward compatibility as well as x86 backward compatibility design features. The two companies struggled for years and years before the first IA64 was introduced, and when it came out the thing was quite disappointing. The x86 compatibility mode was so slow that it was unusable, which meant that a transition from x86 to true IA64 whereby a new Windows version would support both types of applications, was not feasible. Meanwhile Compaq had taken over Digital, and after a while the new CEO Curly came up with a brilliant idea. Let's forget Alpha, and use a "Industry Standard CPU". Tell a manager that something is "Standard" and not a "Special", and he will go for it, no matter what kind of junk it is. "Standard" is the same as "Saving Costs" in a manager's mind. He couldn't go wrong on this. Intel, the world dominating Big Intel, told him that the IA64 would be the CPU to replace all other CPUs. He concocted a small lie that the Alpha engineers suddenly found out that they had reached the end of the design possibilities with the Alpha architecture. The small fact that the EV8 was well advanced in its design, that EV9 also was being designed, and that there were road maps up to EV12, was easily forgotten. He also did not notice that the IA64 was years behind on schedule, and that the IA64 CPUs that had been produced so far were not very promising to use a euphemism. But it did clear the way for the next step in this drama: HP bought Compaq. After Curly had made this monumental stupid decision, there was lively discussion in this newsgroup about the future of IA64. HP reps promised us a new dawn with this wonderful CPU, almost every one else saw it more as a sunset over OpenVMS and Tru64. Intel still claimed that the IA64 would succeed the x86 architecture, and AMD's announcement that it was designing a 64 bit x86 architecture was welcomed by Intel with a scornful smile. Intel even wouldn't discus this way to extend the life of the x86 architecture. We did discus it in this group, and came to the conclusion that AMD's way was far more promising then Intel's white IA64 elephant. And guess what happened, AMD won the dispute, and Intel had to follow. That also meant that the bottom had dropped out of the potential IA64 market, instead of a Industry Standard CPU, the thing was reduced to a high end server CPU, and only HP was still having faith in its future. When HP took over Compaq, HP management should have taken a very brave decision. They should have known at that time that IA64 wasn't quite the success that had hoped for. They should have noticed that in reality it was a HP only CPU, and no one else was using it in any meaningful numbers. Obviously that had (and still have) a very big dilemma. The IA64 is the only future for HP-UX. The future prospects of IA64 and HP-UX are irrefrangible connected. What they should have done is to resurrect the Alpha, and use Tru64 as the base for a new HP-UX V12. After all, many consider Tru64 as the best Unix ever designed, and with a little rebadging trick, adding some 'old' HP-UX stuff, and a few cosmetic changes, they would have had the perfect Unix on the perfect CPU. However Carly didn't care about enterprise servers. She was more interested in consumer goods, like printers, cameras, TV sets, hair-dryers, vacuum cleaners etc. So now we have to see and wait what will happen to the IA64, and when Intel is going to admit the IA64 is a dead end street with not real prospects of becoming a killer architecture. That will be the end of HP-UX, but it doesn't have to be the end of OpenVMS. After two architecture changes, I'm sure OpenVMS could have a third one. The question is more who will pay for the transition, and who will buy the the new platform with OpenVMS. Is there any customer base left at that time? ------------------------------ Date: Sat, 2 Jun 2007 11:30:06 +0100 From: "John Wallace" Subject: Re: HP wasting millions of dollars on itanium! Message-ID: <1362p26sss4g5ca@corp.supernews.com> "Arne Vajhøj" wrote in message news:465f80eb$0$90263$14726298@news.sunsite.dk... > I would say that EV7 is so far behind today that it is not that > interesting for anyone except those strongly tied to Alpha. > s/EV7/today's Itanium/ s/Alpha/Itanium. and you get, presumably equally validly: "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." So where's the difference (even if you believe that Itanium is competitive in either price, performance or price-performance...). Allegedly there weren't enough customers interested in paying for Alpha for the ongoing costs to be affordable. There don't seem to have been that many customers currently interested in paying for Itanium, and that seems likely to get *worse* (not better) as time goes by, thus all that's happening right now is an inevitable decision is being delayed, and all the while the decision is being delayed (for the sake of protecting a few egos) customers are leaving the Itanium market. Fortunately Itanium has its industry-unique (but apparently undescribable in a published direct Itanic vs "industry standard AMD64" comparison) RAS features to save it. Allegedly. For today . However, RAS stuff is often a feature of an *implementation* - ie if the basic architecture is right on day 1, you can leave out the specialist RAS stuff from the mass-market early *implementations* and add more RAS stuff as time goes by for the higher-margin server-market stuff, knowing that you've built on an affordable platform with widely available affordable software which will bankroll future "enterprise" developments. Let's see whether Intel are still interested in protecting egos for another couple of years, or whether they'd rather protect bank balances. My 2p John ------------------------------ Date: Sat, 02 Jun 2007 12:33:02 -0400 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: HP wasting millions of dollars on itanium! Message-ID: <46619bb8$0$90274$14726298@news.sunsite.dk> 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. Arne ------------------------------ Date: Sat, 02 Jun 2007 12:41:54 -0400 From: =?ISO-8859-1?Q?Arne_Vajh=F8j?= Subject: Re: HP wasting millions of dollars on itanium! Message-ID: <46619dcb$0$90267$14726298@news.sunsite.dk> John Wallace wrote: > "Arne Vajhøj" wrote in message > news:465f80eb$0$90263$14726298@news.sunsite.dk... > > >> I would say that EV7 is so far behind today that it is not that >> interesting for anyone except those strongly tied to Alpha. >> > > s/EV7/today's Itanium/ > s/Alpha/Itanium. > > and you get, presumably equally validly: > > "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. The new Itaniums are much faster than Alpha (not a big surprise considering that they are much newer). > 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. Arne ------------------------------ Date: Sat, 02 Jun 2007 08:03:12 GMT From: "Colin Butcher" Subject: Re: Infoserver 150 woes Message-ID: <4v98i.29623$Ro3.11716@text.news.blueyonder.co.uk> Assuming it's a microVAX in disguise - does it have a NVRAM battery and does that battery need to be changed for a new one? -- Cheers, Colin. Legacy = Stuff that works properly! ------------------------------ Date: Sat, 2 Jun 2007 10:46:08 -0700 From: "Ian King" Subject: Re: Infoserver 150 woes Message-ID: <4661acde$0$3579$ae4e5890@news.nationwide.net> 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. -- Ian -- It's not junk, it's history! Ian King ------------------------------ Date: Fri, 01 Jun 2007 23:09:57 -0700 From: Crabs Subject: Re: OpenVMS on AlphaPC Message-ID: |a|i|e|i|e| wrote: > Hi all, > > I have an AlphaPC, and i would install openvms. > I installed SRM 5.8 Need more information on the AlphaPC, specifically a model number, processor, ram, etc. > > I think that the first problem is the scsi adapter (adaptec now, not > supported), and i don't know if the qlogic 1020/1040 is ok. SRM does not like Adaptec SCSI controllers at all. It does like some flavors of QLogic 1040's, especially the DEC branded ones. > The video card a Diamond FireGL Need more information. SRM likes the Diamond Fire Pro 1000 with the Permedia 2 chip set, it thinks it a Powerstorm 4D10T. VMS works well with this video card. > > So, can i hope to install vms on it? Maybe. Need to know more about your system. Regards, Crabs ------------------------------ Date: Sat, 02 Jun 2007 04:31:27 -0400 From: JF Mezei Subject: Paging and process state Message-ID: <6e206$46612b0a$cef8887a$14680@TEKSAVVY.COM> Mozilla got sluggish (really sluggish). So I do a SHOW PROC MOZILLA/CONT and then type Q to see its quotas. The huge PGFLQUO is down to 0% (due to Mozilla's multiple memory leaks). However when I try to do stuff in Mozilla, the process state in the SHOW PROC/CONT seems to be more in HIB and sometimes COM while the Mozilla window is huffing and puffing and taking forever to do anything. I can see the pagefile drive light being a steady green indicating lots of page file acces happening. (we are talking many seconds of wait for Mozilla to load a new NNTP text message for instance). Shouldn't the process state be in PFW or some other nasty state while the process is busy reading and writing pages from the page file ? If Mozilla was being slowed by a bogged down DECW$SERVER process, wouldn't its state be in LEF while it is waiting for X commands to be acknowledged by the server ? ------------------------------ Date: Sat, 02 Jun 2007 07:54:09 -0700 From: IanMiller Subject: Re: Paging and process state Message-ID: <1180796049.348259.12720@w5g2000hsg.googlegroups.com> by looking at the process you may be altering its state. ------------------------------ Date: Sat, 02 Jun 2007 12:38:55 +0200 From: "P. Sture" Subject: Re: SSH port scanners Message-ID: In article <00A6879D.3CDBF827@SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG wrote: > In article , "P. Sture" > writes: > > > > > >In article , > > moroney@world.std.spaamtrap.com (Michael Moroney) wrote: > > > >> Ron Johnson writes: > >> > >> >On 05/30/07 08:36, Tom Linden wrote: > >> >> These guys are a nuisance, what are others doing, if anything about > >> >> these. > >> > >> >Don't know about firewalls, but Linux distros usually have tools > >> >which detect such break-in attempts and auto-block those IP addresses. > >> > >> I have a half-completed program that gets a breakin attempt notification > >> from the audit server, and does the equivalent of the set serv /reject of > >> the offending IP address, which is being created for this very reason. > >> The portscanner's IP address will automatically be disabled after about 5 > >> attempts. I'll make it available when ready. > > > >That would be gratefully received! > > > >> Another option is to have SSH use a nonstandard port so the portscanners > >> won't find it, but I don't know offhand how to do this on VMS. > > > >From the TCPIP help: > > > >SET > > > > SERVICE > > > > Defines a new entry or modifies an existing entry in the services > > database. > > > > The /FILE, /PORT, /PROCESS_NAME, and /USER_NAME qualifiers are > > required when defining a new entry and optional when modifying an > > existing one. > > > > For changes to service parameters to take effect, you must > > disable and reenable the service. > > > >But: > > > >TCPIP> set serv ssh/port=2222/process=TCPIP$SSH > >%TCPIP-E-SERVERROR, cannot process service request > >-TCPIP-E-QUALREQ, qualifier value for USER_NAME is required > > > >TCPIP> set serv ssh/port=2222/process=TCPIP$SSH/user=TCPIP$SSH > >%TCPIP-E-SERVERROR, cannot process service request > >-TCPIP-E-QUALREQ, qualifier value for FILE is required > > > >TCPIP> set serv ssh/port=2222/process=TCPIP$SSH/user=TCPIP$SSH/ - > > file=TCPIP$SYSTEM:TCPIP$SSH_RUN.COM > >%TCPIP-E-INVRECORD, invalid information > >-RMS-F-DUP, duplicate key detected (DUP not set) > > > >So you need to delete the service, then recreate it. > > > >More coffee required! > > $ 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 > Thank you kind sir. Having been bitten by this one before, with third party products, I decided to put the above in a command file. Oops, the prompt for deleting the service screws up. The following shows procedure execution with verify switched on. The truncated display is presumably the prompt echo: $ tcpip set noservice ssh Service Port Proto Process Address SSH 22 TCP TCPIP$SSH 0.0.0.0 $ tcpip set /file=tc /log=(al $ tcpip enab Interrupt The solution is to insert a define/user before the "set noservice" command: $! ssh_config_port.com $! ------------------- $ tcpip disable service ssh $ define /user sys$input sys$command $ tcpip set noservice ssh $ tcpip set service ssh /port=22022 /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 > I usually put mine at a higher port (22022). To make life harder for port scanners? -- Paul Sture ------------------------------ Date: Sat, 02 Jun 2007 11:45:39 GMT From: VAXman- @SendSpamHere.ORG Subject: Re: SSH port scanners Message-ID: <00A68872.7A9662E1@SendSpamHere.ORG> In article , "P. Sture" writes: > > >In article <00A6879D.3CDBF827@SendSpamHere.ORG>, > VAXman- @SendSpamHere.ORG wrote: > >> In article , "P. Sture" >> writes: >> > >> > >> >In article , >> > moroney@world.std.spaamtrap.com (Michael Moroney) wrote: >> > >> >> Ron Johnson writes: >> >> >> >> >On 05/30/07 08:36, Tom Linden wrote: >> >> >> These guys are a nuisance, what are others doing, if anything about >> >> >> these. >> >> >> >> >Don't know about firewalls, but Linux distros usually have tools >> >> >which detect such break-in attempts and auto-block those IP addresses. >> >> >> >> I have a half-completed program that gets a breakin attempt notification >> >> from the audit server, and does the equivalent of the set serv /reject of >> >> the offending IP address, which is being created for this very reason. >> >> The portscanner's IP address will automatically be disabled after about 5 >> >> attempts. I'll make it available when ready. >> > >> >That would be gratefully received! >> > >> >> Another option is to have SSH use a nonstandard port so the portscanners >> >> won't find it, but I don't know offhand how to do this on VMS. >> > >> >From the TCPIP help: >> > >> >SET >> > >> > SERVICE >> > >> > Defines a new entry or modifies an existing entry in the services >> > database. >> > >> > The /FILE, /PORT, /PROCESS_NAME, and /USER_NAME qualifiers are >> > required when defining a new entry and optional when modifying an >> > existing one. >> > >> > For changes to service parameters to take effect, you must >> > disable and reenable the service. >> > >> >But: >> > >> >TCPIP> set serv ssh/port=2222/process=TCPIP$SSH >> >%TCPIP-E-SERVERROR, cannot process service request >> >-TCPIP-E-QUALREQ, qualifier value for USER_NAME is required >> > >> >TCPIP> set serv ssh/port=2222/process=TCPIP$SSH/user=TCPIP$SSH >> >%TCPIP-E-SERVERROR, cannot process service request >> >-TCPIP-E-QUALREQ, qualifier value for FILE is required >> > >> >TCPIP> set serv ssh/port=2222/process=TCPIP$SSH/user=TCPIP$SSH/ - >> > file=TCPIP$SYSTEM:TCPIP$SSH_RUN.COM >> >%TCPIP-E-INVRECORD, invalid information >> >-RMS-F-DUP, duplicate key detected (DUP not set) >> > >> >So you need to delete the service, then recreate it. >> > >> >More coffee required! >> >> $ 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 >> > >Thank you kind sir. > >Having been bitten by this one before, with third party products, I >decided to put the above in a command file. > >Oops, the prompt for deleting the service screws up. The following shows >procedure execution with verify switched on. The truncated display is >presumably the prompt echo: > >$ tcpip set noservice ssh > >Service Port Proto Process Address > >SSH 22 TCP TCPIP$SSH 0.0.0.0 >$ tcpip set > /file=tc > /log=(al >$ tcpip enab > Interrupt > >The solution is to insert a define/user before the "set noservice" >command: > >$! ssh_config_port.com >$! ------------------- >$ tcpip disable service ssh >$ define /user sys$input sys$command >$ tcpip set noservice ssh >$ tcpip set service ssh /port=22022 /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 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. >> 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. -- VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM "Well my son, life is like a beanstalk, isn't it?" ------------------------------ Date: Fri, 1 Jun 2007 14:40:25 -0400 From: "William Webb" Subject: Re: SYSMAN problem Message-ID: <8660a3a10706011140y2bb35170gb99fcc263fac4a6e@mail.gmail.com> ------=_Part_8195_1240997.1180723225243 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 5/12/07, John wrote: > > Bob Koehler wrote: > > >In article <31781$4643e312$cef8887a$29845@TEKSAVVY.COM>, JF Mezei < > jfmezei.spamnot@vaxination.ca> writes: > > > > > > And the current public roadmap shows plans to VMScluster over an IP > > network. Now that is a change. > > > > > SCS over IP - firt thought is that IP may allow for longer distance > clusters. > > What is the intent of SCS over IP? Any thoughts? > > > > My first thought is that latency over increased distances is inescapable until somebody figures out how to break the speed of light barrier. WWWebb ------=_Part_8195_1240997.1180723225243 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 5/12/07, John <norad869@tx.rr.com> wrote:
Bob Koehler wrote:

>In article <31781$4643e312$cef8887a$29845@TEKSAVVY.COM >, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>
>
>   And the current public roadmap shows plans to VMScluster over an IP
>   network.  Now that is a change.
>
>
SCS over IP - firt thought is that IP may allow for longer distance
clusters.

What is the intent of SCS over IP?  Any thoughts?



 
My first thought is that latency over increased distances is inescapable until somebody figures out how to break the speed of light barrier.
 
WWWebb
 
------=_Part_8195_1240997.1180723225243-- ------------------------------ Date: Sat, 02 Jun 2007 09:21:40 +0200 From: Dirk Munk Subject: Re: Upgrade to Vista from XP ? Yes or No Message-ID: 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. > > Chris ------------------------------ Date: Sat, 02 Jun 2007 07:45:37 -0700 From: IanMiller Subject: Re: VMS Update going out tomorrow Message-ID: <1180795537.021197.278500@q75g2000hsh.googlegroups.com> news can always be submitted to http://www.openvms.org using the submit link at any time. ------------------------------ End of INFO-VAX 2007.300 ************************