teachers:

I am a beginner in using the Cadence to draw schematic, in the past I can descent into a sub schematic for editting from a symbol, but resently when I descent into a sub schematic, I find that it can not be edited, I don't know what happend, and who can tell me how to correct this.

Thanks a lot

Andrew,

Thank you very much! It is OK now, just as you said, each time I needed to select the "make editable" to edit the sub schematic yesterday, but this morning the work-station was reset, and every thing is OK.

And last Friday I can not close my computer normally, maybe some schematics are still openning, so it result in sub schematic not editable.

Regards and have a nice day

In general you should not need to delete lock files, and in fact you should be very cautious when doing so.

Provided there is a daemon "clsbd" running on each machine which can run the IC tools - this is normally auto-started the first time you run the software, but it's a good idea to start it at boot time - things should work smoothly.

What happens is that when you try to open a cellView with a lock file, it sees from the lock file which machine it was locked on, and the process id of the process which locked it. It then tries to ask the clsbd on that machine whether that process is still running. If it manages to talk to clsbd and clsbd indicates that the process is no longer running, the lock can be reclaimed. If the process is still running, or it can't communicate with clsbd, then the lock remains.

So, provided that clsbd is running, and your network is responding properly, the only things that should require lock files to be removed are:

a) the machine which formerly had the lock is no longer on the network (for example, it has died and has gone to meet its maker)
b) somebody tarred up something from their network with lock files in and sent it to you (which happens to us in customer support all the time!).

If you are sure that this is the case, then it is safe to remove the locks. It's a good idea to use clsAdminTool to find and inspect the locks first, and then delete them. Note, clsAdminTool doesn't check that it's safe to remove the locks - because you wouldn't be running it if it could determine that!

The danger of removing lock files is that somebody else might be editing the files, and there's a chance of lost data since both editing sessions think they control the file. For example:

1. User A opens and locks the cellView, and starts making
   edits.
2. User B finds that the cellView is locked, and so blows away the locks and starts editing.
3. User B saves his changes and closes the cellView (which clears the lock).
4. User A  saves his changes (which re-locks the cellView).

As if by magic, everything user B did got lost. I saw this recently at a customer who was blindly deleting lock files without considering the impact, and then complaining about things going missing...

Regards,

Andrew.

Because the lock files have global permissions on them (if I remember rightly). Normally you would not delete the locks, as I said, but it would be a right pain if we required a sysadmin to cleanup stray locks for a user that didn't exist (and the machine keeping the lock doesn't exist either).

Most importantly, the stranded lock recovery mechanism needs to be able to delete locks "owned" by other users. Imagine the scenario where user A opened a design in edit mode, and then has a DFII crash which leaves the lock behind. He then goes on vacation for 2 weeks. User B opens the same design, and the locking mechanism will check (via the clsbd process) whether the process owning the lock still exists; if it doesn't, the lock will be removed and user B will re-lock it. If only user A could delete the lock file, then the stranded lock recovery could not proceed, and lots more manual intervention would be necessary (which users hate ; this used to be necessary with previous locking systems we had).

Regards,

Andrew.

Are you using IC446 or earlier? You may be using the old locking system in conjunction with the new locking system. The old (cdsd) based locking system was using a lock daemon, and old versions were pretty poor at releasing stranded locks.

I'm surprised you need sysadmin involvement for recent versions though.

Andrew.