Most intelligent software vendors have a disaster recovery process which
allows for keeping the customers alive - our issue is that our software was
in some large companies who abused the trust we had and were running on
unlicensed machines - our process was derived from necessity so that we can
fund the millions of $ that it takes to keep R&D ahead of the technology
curve.

Frankly this is for the most part a tempest in a teacup - I doubt if there
are more than a handful of incidents that the SS Config would ever be needed
for in each of the next 10 years.

Respectfully,

Birket




----- Original Message -----
From: "Bob J." <[log in to unmask]>
To: <[log in to unmask]>
Sent: Sun,October 20, 2002 9:29 PM
Subject: Re: No Current Plans


> Good point. Not having a disaster recovery plan is
> dangerous. A disaster recovery plan would have instructions
> for the possibility that your system must be replaced.
> The same mechanism that would be used to activate 3rd party
> software during a DR event would have worked for you until
> your software vendor can make the permanent fix.
> Prior planning.....
>
>             Bob J. -- Ideal Computer Services
>             http://www.icsgroup.com
>
>
> Roy Brown wrote:
> >
> > In message <[log in to unmask]>, Bob J. <[log in to unmask]>
> > writes
> > >> > * No plans to make SSCONFIG publicly available
> > >>
> > >> So license it to trusted third parties. Not making it available
> just creates
> > >> nightmare scenarios for HP's customers.
> > >
> > > This item is getting blown way out of proportion. If in
> > >the rare event that (whatever part is housing stable storage)
> > >fails your hardware vendor can replace the SPU. Next
> > >you call a few third party software vendors that use the ss
> > >info and get whatever key they use to lock up their product.
> > >That shouldn't take much effort....hardly a nightmare with just
> > >a little planning.
> > > The fact is (whatever part is housing stable storage) has proven
> > >to be the most reliable part of the systems.
> >
> > Last Christmas (and not exactly Christmas, so it wasn't that everybody
> > was away), we had a hardware failure that led to the replacement of a
> > CPU, with the resulting change in HPSUSAN.
> >
> > HP (for it was they who were supporting us) also thought the above
> true,
> > and suggested we got our 3rd party vendors to give us new keys, rather
> > than HP resetting the box to the old HPSUSAN.
> >
> > On the third working day of attempting to follow this approach, when
> we
> > still had no 3rd party software running again, and we were getting
> next
> > to no useful work out of the box, we *demanded* that HP return and
> reset
> > the HPSUSAN. This they did, and off we went again.
> >
> > And this was at a time, don't forget, when all the 3rd parties were
> > still in business and still in the HP3000 business to boot. As 3rd
> > parties drop out of the marketplace, we can only see this process
> > getting more arduous.
> >
> > No names, no pack drill for the 'guilty' 3rd parties, but don't *ever*
> > try to tell anybody here that the inability to preserve an HPSUSAN is
> no
> > big deal.
> >
> > --
> > Roy Brown        'Have nothing in your houses that you do not know to
> be
> > Kelmscott Ltd     useful, or believe to be beautiful'  William Morris