Unlock Objects in Task Tracking

When controlling changes, the concept of task tracking is based on locking objects to a task. When an object is locked by a Task ID, it cannot be allocated to another Task ID until the lock is released. Hence you can control when changes are being made.

Normal Task IDs, that are used with the Full Task-Oriented Tracking approach, support only status-based unlocking.

For the specialized Task IDs, LANSA supports two basic approaches:

Status-based Unlocking

• By default, all tasks use a status-based unlocking mechanism. When a task has a status of Open (OPN), Work (WRK) or Closed (CLS), associated objects are locked to the task. Once a task status is changed to Finished (FIN), the objects are unlocked. (Refer to Task Status.)

• If you are using status-based unlocking, you will typically be creating many different tasks. As work is completed you must set tasks to finished or Transfer Object Locks.

• This form of unlocking ensures that a group of objects are locked and unlocked as a unit of work. You can create an export list of objects using a Task ID.

• Status-based tracking must be used if you wish to use a Full Task-Oriented Tracking approach.

Note: All normal tasks can use only this method of unlocking.

PC Name Unlocking

• By default, all tasks will allow this form of unlocking. When an object is checked out, in addition to being (or remaining) locked to a task, it is also (or remains) locked to a PC Name.

• This form of unlocking is primarily used to ensure that an object is being updated on only one PC at a time.

• If a developer wants to check-in source changes to be archived before they have finished development on the object, they can use the Keep locked to PC option on check-in. This will retain a PC Name lock for the object both on the server (Master) and PC (Slave). This can be used to ensure no other PCs can check-out the object until development has been completed on the original PC. In RDML partitions, it will also ensure that no other development on the object can be done in LANSA for i.

• Check-in Unlocking will also perform PC Name Unlocking.

Note: If you are using an Independent System, the PC Name is not used to lock the object permanently. Refer to Task Tracking on Independent Systems.

Check-in Unlocking

• This form of unlocking can only be used with Special Task Ids and must be set up on the IBM i Master. (Refer to Set Special Task ID.)

• By default, an object is unlocked from a task both on the server (Master) and workstation (Slave) system when it is checked into the server. At the same time, it is changed to read-only on the workstation system. To change an object again on the workstation, you must check it out for update.

• This form of unlocking is primarily used to ensure that an object is not being updated by more than one developer at a time. The task is not being used to group objects under a task.

• If a developer wants to check-in source changes to be archived before they have finished development on the object, they can use the Keep Locks option on check-in. This will retain an update lock for the object both on the server (Master) and workstation (Slave). This can be used to ensure no other developer can allocate a different task to the object until development has been completed.

• Note: If you are using an Independent System, you cannot use this type of unlocking. Refer to Task Tracking on Independent Systems.

When you decide to unlock objects will determine the types of controls you are able to implement.

Also See

Transfer Object Locks