I agree to what Ralph said.
The HP ITRC is a phantastic forum.
Even if you have an HP software support contract
you often get quicker responses from fellow sysadmins whose main platform
is HP-UX, most of the times containing a solution or hints that at least will
help you further.
But back to your problem.
I am afraid I have no experience with HP workstations.
Btw, have you looked here for a manual of your workstation model?
It should at least drop a line how you can access maintenance mode.
http://h20000.www2.hp.com/bizsupport...IndexId=179111
That's where you need to get in order to fix your locked root account.
Btw, a locked root account or lost root password is such a common issue
that I am convinced you will find a thread treating it in the afore mentioned
HP ITRC forum.
The ITRC also has a great knowledge base that you can query with regard
to you problem (but I fear this is only accessible to support contract holders).
If all else fails you should at least be able to boot from a Core OS CD
which starts up an ASCII menu from where you can enter a root shell.
I also don't know the Commercial Security Database.
Somewhere in it must be a field that has a lock set for your root account.
Maybe you had entered too many times a wrong password or similar?
But I am convinced that the lock flag can be removed,
mabe even by moving the whole DB out of place or by providing an interim
empty one.
Please search docs.hp.com for your case.
Most of the HP documents are downloadable.
E.g. here are some manpages that may be relevant to you
http://docs.hp.com/en/B2355-60127/isl.1M.html
http://docs.hp.com/en/B2355-60127/hpux.1M.html
http://docs.hp.com/en/B2355-60127/boot.1M.html

If regained access to your workstation and if you have a streamer available
I would strongly advise you to create a disaster recovery tape
by the make_tape_recovery command.
This is part of the freely available Ignite utility.
Search HP site for download and documentation.
Creating an Ignite tape is as easy as issuing one short command.
After successful creation you have a bootable recovery medium
where you either could reinstall the whole OS within half an hour
or where you could access a root shell should your root disks get broken.
HTH

Hi buffonix & Ralph

Thanks again for the reply. Sorry for not getting back to you earlier. I will be looking on the HP ITRC and the links you provided me to see what I can find.

I did look into the Manual for this model, but not much joy. To access the maintenance mode, one needs to be login and get to the prompt and then change the run level to a desired mode (init 0 and so on). The problem I am facing is the initial interaction with ISL and to my mind it was caused by playing up with file permissions.

To give a better picture, this machine has 2 disks vg00 (root disk), vg01(a practice disk) and a floppy and a CD drive. I bought it form a "used HP" dealer 400 - 500 miles away from where I live on the Net, not subject to any support after sale. Once I regained access I will be looking how I can master creating a disaster recovery tape and Ignite tape so that I am able to reinstall the whole OS. I do not know about "streamer" what is it?

I can appreciate both of you are more competent with Sun than HP and the same time thanks again for all the hints and help. Let's I hope, I be in the position of giving you the good news that I am sorted.

Kind regards

MH

good god, UNIX=NO REBOOTS, what kind of data center is this....

"Stale NFS handles, zombie processes, small memory leaks from applications, etc. are all cleaned up by the reboot"

the root cause of these should be found, not band-aided by a reboot...

you should never ever reboot unix servers unless you change the kernal or specific uprgrades require it...

Please let me know where to send my resume. I'd love to work at your datacenter where nothing ever breaks.

Unfortunately, I'm not in that situation. We have 7 admins responsible for a couple hundred servers and several hundred more workstations. We support well over 1000 users and have automounter maps that allow them to connect to several hundred project directories on a SAN with over 100 TB of storage. And we're responsible for EVERYTHING in the Unix and Storage environment from password resets to desktop linux support to system architecture to filling out purchase orders for new equipment.

In a perfect world I agree with you we'd be able to keep machines up constantly by fixing each problem as it happened. But with the thousands of mounts and unmounts that happen every day we get some stale file handles for example. There are plenty of other little problems that come up which really don't need to be solved immediately that the monthly or 90-day reboot clears up. There is absolutely no way we could spend the time having a system administrator track each of them down individually without double the people. And there is no need for us to do it - for over a decade the monthly maintenance policy has been in place and the business units and users we support agree with it. So we let the minor stuff I mentioned go and clean it up during maintenance by rebooting.

Also, we are in the medical industry so there are very strict regulations about reliability and disaster recovery. Many of our machines are required to be rebooted on a schedule to prove that they are configured properly and will come up correctly after an unplanned outage. For example, the Veritas clusters I mentioned rebooting monthly. Our DR policy requires that to prove the clusters are able to function properly in a failover situation where one system crashes. We actually have to sign and file documents verifying the status of each system after it comes back up. Thus it doesn't matter if we think they need it for a technical reason or not, a lot of those reboots are going to happen to satisfy the policies put on us by the regulatory department.

So I'd finish by pointing out my last paragraph of the original message. It all depends on the environment. Just as you said is the right way to do it, most places I've worked did not have scheduled reboots. However, due to specific factors in the environment I work in now we have to do it. You need to know your users, machines and environment well enough to know what reboot policy is best for your situation.