Chat now with support
Chat with Support

Stat 6.0 - User Guide

Introduction to Stat Connecting to Stat Change/Service Requests Stat Consoles Tasks and Time Entries Stat Projects Search Engines Reports and Graphs Personal Rules Object Tools and Wizards Change Management for PeopleSoft
Object Management (PeopleSoft) Object Archives (PeopleSoft) Object Migrations (PeopleSoft)
Change Management for Oracle Applications
Object Management (Oracle Applications) Patch Management Object Archives (Oracle Applications) Object Migrations (Oracle Applications)
Change Management for Generic Applications
Object Management (Generic Applications) Object Archives (Generic Applications) Object Migrations (Generic Applications)
Appendix: Troubleshooting Chart Appendix: Migration Options Appendix: User-Specific Parameters Appendix: Supported PeopleSoft Proprietary Objects Appendix: Stat Reports

The Object Locking Process

The object locking process has up to three phases.

When you associate an object with a CSR, Stat automatically requests a lock for that object in the designated environment(s). Stat checks if there are existing locks or reservations on that object. If a lock or reservation exists, Stat issues a tentative reservation. If not, it issues a tentative lock. The lock or reservation remains tentative until you save the CSR.

Immediately after associating objects with a CSR, you should save your work. Upon saving, Stat checks for existing locks or reservations. If a lock or reservation exists, Stat issues a full reservation. If not, it issues a full lock.

The longer you wait to save your CSR, the greater the likelihood you will lose your place in the queue for that object. For example, while you have a tentative lock on an object, another user could add that same object to a CSR and receive a tentative reservation. If the second user then saves his or her CSR before you do, that user receives the full lock for that object, and when you save your CSR, you receive instead a full reservation.

When Stat issues a full lock, it automatically archives a “pre-change” version of the object to the Stat Repository. Archiving objects is discussed in depth in the next chapter.

The third phase is the conversion of reservations into locks. Stat releases an object lock when the status of the CSR changes to a closed-type status, or when the developer manually unlocks the object or the object is reassigned to another developer. After unlocking an object, the Stat Central Agent then determines if there are any pending reservations on the object. If reservations on the object have been given to more than one user, these reservations are handled in chronological order, based on the time each lock was requested. The Stat Central Agent converts the first reservation in line into a lock and performs any applicable object archiving.

Locking Facts

Additional information about locking objects in Stat that you should know:

Physical PeopleSoft Locking Option

Physical PeopleSoft locking works in conjunction with Stat logical locking. When your system administrator activates the Physical PeopleSoft Locking option in Stat, any object you lock in Stat is also locked in PeopleSoft. Stat utilizes PeopleSoft Object Security to secure the locked objects in each PeopleSoft environment.

Your system administrator defines the scope of PeopleSoft physical locking at the service domain level. Depending on the service domain, object types as well as PeopleSoft environments may be excluded from the physical locking option. Even specific PeopleSoft users can be excluded from this functionality.

The developer assigned to the physically locked object is the only user that has Write access to the object in PeopleSoft. Other users are restricted to Read Only access. If the object is reassigned to a different user and the CSR is saved, the new user has Write access and the previous user has Read Only access to the object.

An object that is not physically locked on any CSR can only be opened in Read Only mode in PeopleSoft. In order to make any changes to PeopleSoft proprietary objects, you must first open a CSR and physically lock the objects in that CSR. This ensures that all object modifications are documented.

NOTE: For detailed instructions on setting up physical locking between Stat and PeopleSoft, see the book, Stat System Administration, Chapter 8, “Object Security.”

Physical File Locking Option

Like physical PeopleSoft locking, physical file locking works in conjunction with Stat logical locking. When set up appropriately, physical file locking prevents developers from modifying file objects that have not been locked in a CSR and assigned to them. Stat does this by allowing developers to modify only file objects that are in their working directory. Once a file is locked and assigned to a developer, the developer can only use Stat to migrate the file to their working directory as well as all source directories. This enforces that all changes to the file objects are documented and orchestrated through Stat.

System administrators define the scope of the physical file locking. Source file locations, specific users, and environments can be excluded from physical locking.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating