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" <Kerry.Main@hp.com>
Subject: RE: Anyone know why the Alpha market is so so quiet?
Message-ID: <FA60F2C4B72A584DBFC6091F6A2B8684023E87AB@tayexc19.americas.cpqcorp.net>
> -----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" <Kerry.M...@hp.com> 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 <gxys@uk2.net>
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 <munk@home.nl>
Subject: Re: HP wasting millions of dollars on itanium!
Message-ID: <f3r48l$n94$1@news3.zwoll1.ov.home.nl>
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" <johnwallace4@yahoo.spam.co.uk>
Subject: Re: HP wasting millions of dollars on itanium!
Message-ID: <1362p26sss4g5ca@corp.supernews.com>
"Arne Vajhøj" <arne@vajhoej.dk> wrote in message
news:465f80eb$0$90263$14726298@news.sunsite.dk...
<snip>
> 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?= <arne@vajhoej.dk>
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?= <arne@vajhoej.dk>
Subject: Re: HP wasting millions of dollars on itanium!
Message-ID: <46619dcb$0$90267$14726298@news.sunsite.dk>
John Wallace wrote:
> "Arne Vajhøj" <arne@vajhoej.dk> wrote in message
> news:465f80eb$0$90263$14726298@news.sunsite.dk...
>
> <snip>
>> 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" <colinDOT.butcherAT@xdeltaDOT.coDOT.uk>
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" <iking@killthewabbit.org>
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 <iking@killthewabbit.org>
------------------------------
Date: Fri, 01 Jun 2007 23:09:57 -0700
From: Crabs <IHateSpam@SpamSucks.com>
Subject: Re: OpenVMS on AlphaPC
Message-ID: <W8CdnWPXF6AolPzbnZ2dnUVZ_oWdnZ2d@comcast.com>
|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 <jfmezei.spamnot@vaxination.ca>
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 <gxys@uk2.net>
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" <paul.sture.nospam@hispeed.ch>
Subject: Re: SSH port scanners
Message-ID: <paul.sture.nospam-96DF8F.12385502062007@mac.sture.ch>
In article <00A6879D.3CDBF827@SendSpamHere.ORG>,
VAXman- @SendSpamHere.ORG wrote:
> In article <paul.sture.nospam-BB32F5.08161001062007@mac.sture.ch>, "P. Sture"
> <paul.sture.nospam@hispeed.ch> writes:
> >
> >
> >In article <f3kd6h$rfu$1@pcls4.std.com>,
> > moroney@world.std.spaamtrap.com (Michael Moroney) wrote:
> >
> >> Ron Johnson <ron.l.johnson@cox.net> 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 <paul.sture.nospam-96DF8F.12385502062007@mac.sture.ch>, "P. Sture" <paul.sture.nospam@hispeed.ch> writes:
>
>
>In article <00A6879D.3CDBF827@SendSpamHere.ORG>,
> VAXman- @SendSpamHere.ORG wrote:
>
>> In article <paul.sture.nospam-BB32F5.08161001062007@mac.sture.ch>, "P. Sture"
>> <paul.sture.nospam@hispeed.ch> writes:
>> >
>> >
>> >In article <f3kd6h$rfu$1@pcls4.std.com>,
>> > moroney@world.std.spaamtrap.com (Michael Moroney) wrote:
>> >
>> >> Ron Johnson <ron.l.johnson@cox.net> 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" <william.w.webb@gmail.com>
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 <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
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<br><br>
<div><span class="gmail_quote">On 5/12/07, <b class="gmail_sendername">John</b> <<a href="mailto:norad869@tx.rr.com">norad869@tx.rr.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Bob Koehler wrote:<br><br>>In article <<a href="mailto:31781$4643e312$cef8887a$29845@TEKSAVVY.COM">31781$4643e312$cef8887a$29845@TEKSAVVY.COM
</a>>, JF Mezei <<a href="mailto:jfmezei.spamnot@vaxination.ca">jfmezei.spamnot@vaxination.ca</a>> writes:<br>><br>><br>> And the current public roadmap shows plans to VMScluster over an IP<br>> network. Now that is a change.
<br>><br>><br>SCS over IP - firt thought is that IP may allow for longer distance<br>clusters.<br><br>What is the intent of SCS over IP? Any thoughts?<br><br><br><br></blockquote></div>
<div> </div>
<div>My first thought is that latency over increased distances is inescapable until somebody figures out how to break the speed of light barrier.</div>
<div> </div>
<div>WWWebb<br> </div>
------=_Part_8195_1240997.1180723225243--
------------------------------
Date: Sat, 02 Jun 2007 09:21:40 +0200
From: Dirk Munk <munk@home.nl>
Subject: Re: Upgrade to Vista from XP ? Yes or No
Message-ID: <f3r5qa$ufq$1@news3.zwoll1.ov.home.nl>
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 <gxys@uk2.net>
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
************************