HP3000-L Archives

December 2003, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Michael Anderson <[log in to unmask]>
Reply To:
Michael Anderson <[log in to unmask]>
Date:
Mon, 8 Dec 2003 11:55:10 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (143 lines)
Thanks to all who responded to my unpleasantness. All is back to
normal.

FYI: We use 3rd party hardware support, and when a hardware problem
occurs it is usually not a big deal. But this time it was not just a
hardware problem, it was the system board that contains the entire
machine licensing data. Our third party hardware support vendor "Surety
System of Houston Texas" had us up and running within a few hours, but
the new system board didn't contain the needed licensing data. This data
can only be updated by the HP SSConfig utility. Surety Systems paid the
HP support costs to have an HP CE come and run the SSConfig utility the
following day. The HP CE required us to have our paper work showing user
license info, rights to the box, and so on. Lots of misconceptions about
this licensing data, where it is/is not, and who has access to it, what
effect will it have on software, how it can be updated. This event as
taught me a thing or two, or three.

Lesson #1: The HP CE with SSConfig is able to update the SUSAN number,
and therefore did give us back our original SUSAN, which BTW SSConfig
refers to the SUSAN as the Software ID.

Lesson #2: If you have third party Hardware Support, make sure all your
paper work is in order, and can be easily retrieved.

Lesson #3: The man that runs (Surety Systems) the third party Hardware
Support Company, (of course I've known this) is a man of his word, he
came through, thanks Keith.


--
Michael Anderson
Spring Independent School District
16717 Ella Boulevard
Houston, Texas 77090-4299
office: 281.586.1105
fax: 281.586.1187
-

>>> "Simpkins, Terry" <[log in to unmask]> 12/04/03 08:00AM >>>
I think you will find that the HPSUSAN number is NOT a hashed
combination,
but rather simply a number (Don't ask how I know this).
There are ways to change the HPSUSAN number and SSCONFIG is one of
them.
HP may tell you this can't be changed, but they are "full of it".

Who is your hardware support vendor?  There is another program that
can
make this change besides SSCONFIG and it does NOT impinge on HP
copyrights.
If you are using HP as your hardware support vendor, they should be
willing
and able to change the HPSUSAN number for you.  Others may be
unable/unwilling.
If they can't/won't then I would find a new vendor.

What I would recommend in your current situation, is to find someone
who will
provide a new (swap) board with your old HPSUSAN and HPCPUNAME (these
are the
only two I have ever seen used for validations) and get them to create
one for you.
Then at a convienient time (soon) swap it in for the one you just
replaced.
Then you will be right back to where you were before the failure, and
all should
work well.  You have not "defrauded" anyone out of revenue, and noone
need know
anything about what happened (as it should be) except for your hardware
support
vendor.

*****************************
Terry W. Simpkins
Director - ISIT
Measurement Specialties
757-766-4278
[log in to unmask]
*****************************


-----Original Message-----
From: Michael Anderson [mailto:[log in to unmask]]
Sent: Thursday, December 04, 2003 2:49 AM
To: [log in to unmask]
Subject: Re: [HP3000-L] 9x9 KS system board replacement


Actually the problem is not a CPU board, it is the system board. The
FLT
3x00 does relate to a CPU board on the K-Class, the x denotes CPU
0,1,2,3. We were getting FLT 3100, 3200, and 3300 randomly. We changed
all 4 of the CPU boards one-by-one, still getting these FLT's. We even
booted up on one CPU and got FLT 3000. The problem was the FEPROM on
the
system board, not a CPU board. The system board is the board that
everything plugs into, Memory, CPU's, FWSC. On this board is the
SSConfig data, HPSUSAN, CPU-String, and User License limit.

SSConfig can fix the Users Lic, the CPU-String, and various other
things, but it can't change the HPSUSAN. The HPSUSAN is a hashed vale
based on  the product number and the serial number.

The end result is we have a new HPSUSAN, and Speedware complains but
(Thank You Speedware) it still runs for us. I don't how long it will
run
like this but I will contact them tomorrow, or is that today.

I haven't noticed any other problems yet, thanks for all your
responses
at this weee hour in the morning.

I still think I'm for getting something,
Mike.



>>> Jeff Kell <[log in to unmask]> 12/04/03 12:05AM >>>
Michael Anderson wrote:

> I hope everyone is awake, and reading the HP3000-L right now ;-)

"It depends".

For 950/955/960/980s the SUSAN is kept on the PDH board, not the
processor.

For the 9x9, it may be an EPROM on the processor board.

If you aren't doing an upgrade, you may be able to scavenge the susan.

If not, some products just quit, others revert to demo mode, and a few

don't really give a sh*t unless you replace it with a 9000 board.

Jeff

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2