Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)
From: Dirk Munk (munk_at_home.nl)
Date: 06/15/03
- Next message: Fabio Cardoso: "Re: IBM will buy SUN, it's obvious (Re: IBM won't buy VMS ... has NIH syndrome too!) NIH syndrome too!) NIH syndrome too!)"
- Previous message: Main, Kerry: "RE: problem after upgrading to compaq (DEC) fortran 7.5"
- In reply to: Mark Daniel: "Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)"
- Next in thread: JF Mezei: "Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)"
- Reply: JF Mezei: "Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)"
- Reply: Fred Kleinsorge: "Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 15 Jun 2003 15:25:30 +0200
To start with, you may have noticed that there are not that many people
participating in this newsgroup. It seems there are still something like 450,000
VMS systems around, and if only 1% of those systems would be represented by one
person here, we would see 4,500 name popping up in this newsgroup. There are far
less contributors I'm afraid.
So it may well be that others have the same problems as you, but don't read this
newsgroup.
On the other hand that is not really the issue. The problem you are facing is a
problem that we can see more often, and not just with HP. In your case the
problem is that no one seems to be reponsible for the Motif architecture as a
whole, that is including for instance the TCP/IP changes that have to be made to
bring the Motif environment up to today's standard. Someone should have told
the TCP/IP engineers to make the necesarry changes, and he should have made sure
the work was done. Somehow this did not happen, and that is poor product
management in my view, and that is the real problem. Now you are stuck with an
unfinished product, and you as a customer really don't care who is reponsible
for that, the Motif engineers or the TCP/IP engineers.
I'm facing a similar problem that HP isn't going to solve on short term.
TCP/IP services for VMS can also be used as a BIND server, and it can be used
with dynamic DNS updates. So in that respect TCP/IP services are up to date.
As we all know we can cluster VMS sytems for high availability, and so we can
also make a clustered BIND server. This is great, most likely the only such
product around.
However you can NOT use dynamic updates with such a clustered BIND server.
Now if you want to build a VMS TCP/IP production cluster, it will use the
Loadbroker, and that relies on dynamic DNS updates.
So there we have a high availability clustered VMS BIND server that can not be
used with high availability production clusters, because the BIND server can not
be used with the dynamic DNS updates that the production cluster needs !!
This is just as silly as your problem. If this wasn't the case I could recommend
using VMS BIND servers to our network group. They don't have a sollution for a
failing master BIND server, except by manually 'promoting' a slave BIND server
to master BIND server.
These inconsistencies are very irritating and harm the reputation of the
products, specialy when HP doesn't want to fix them.
Mark Daniel wrote:
> Well, it's been a fortnight (or whatever the metric equivalent of that
> is these days) and this issue has generated only the *slightest*
> interest from the c.o.v. community.
>
> The only conclusion I can draw from this is what is such a *significant*
> problem for our environment is unique to us (I'm tempted to add - in
> contrast to so many, seemingly off-topic threads, that do get
> considerable discussion in this forum). No one else needs to
> interoperate in heterogenous X environments? It would seem then, that
> DEC/Cpq/HP have made the correct call on where their resources need to
> be deployed (and who can blame them for that).
>
> I'll (one more time) need to go, cap-in-hand, to those that administer
> our environment and explain that VMS, yes - once again, cannot be made
> to integrate into that. Oh well, perhaps RLM made the correct call
> after-all. Shame. Never thought I'd be resigned to it, but you can't
> swim against the tide indefinitely.
>
> +--------------------------------------------------------------------+
> Mark Daniel http://wasd.vsm.com.au/adelaide
> mailto:Mark.Daniel@wasd.vsm.com.au (Mark.Daniel@dsto.defence.gov.au)
> +--------------------------------------------------------------------+
- Next message: Fabio Cardoso: "Re: IBM will buy SUN, it's obvious (Re: IBM won't buy VMS ... has NIH syndrome too!) NIH syndrome too!) NIH syndrome too!)"
- Previous message: Main, Kerry: "RE: problem after upgrading to compaq (DEC) fortran 7.5"
- In reply to: Mark Daniel: "Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)"
- Next in thread: JF Mezei: "Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)"
- Reply: JF Mezei: "Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)"
- Reply: Fred Kleinsorge: "Re: SEC:U MIT-MAGIC-COOKIE-1, Motif 1.3 and HP TCP/IP XDM (long)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|