On the newer systems, MPE will not use additional processors unless the
model string is changed (SS_Config) to reflect the added processors. So, it
is not just ISVs that would have to change their protection scheme, it is
also HP.

> -----Original Message-----
> From: Ken Cook [mailto:[log in to unmask]]
> Sent: Friday, October 25, 2002 6:47 AM
> To: [log in to unmask]
> Subject: Re: A No for SSConfig
>
>
> If the only issue is whether or not software will run if the
> HPSUSAN or
> HPCPUNAME changes, and HP refuses to release SSConfig, (as is
> their right),
> then can't the software vendors who wish to continue to support the
> MPE/OpenMPE community find another method to secure copies of
> their product?
> Microsoft seems to manage to make a few gazillion dollars a
> year without the
> equivalent of HPSUSAN or HPCPUNAME.
>
> Does SSConfig provide other vital utilities in case of a
> change in CPU?  If
> it does, can the OpenMPE group find a way to emulate/simulate
> SSConfig?
> ----- Original Message -----
> From: Jonathan M. Backus <[log in to unmask]>
> To: <[log in to unmask]>
> Sent: Friday, October 25, 2002 9:19 AM
> Subject: Re: A No for SSConfig
>
>
> >         From my prospective, the topic of SS_Config usage
> isn't so much
> what we
> > consider 'reasonable' to expect from application and
> utility software
> > vendors.  It's more of an issue of implementing a safety net for the
> > exceptions.  Even if there ends up being no exceptions,
> there was no harm
> in
> > having the assurance.  I think, while "virtual CSY" still
> exists there
> > should be an effort to create a policy by which trusted
> entities can use
> > SS_Config (and/or a tool similar to it) beyond 2006 under a
> 'reasonable'
> and
> > well defined set of circumstances.  We then tuck that away
> and maybe it
> > never gets used.
> >
> > Thanx,
> >         Jon
> >
>