Explicit Lock - Requested by program

Key Characteristics

• • Programmatic Control: The application code (e.g., COBOL, PL/I) explicitly issues commands or API calls (e.g., CICS ENQ, DB2 LOCK TABLE) to acquire and release the lock.
  • Resource Granularity: Can be applied at various levels, from a specific record or segment to an entire database table or a user-defined resource name, offering flexible serialization.
  • Duration and Scope: Locks are held for the duration specified by the program, typically until the resource is no longer needed or the transaction commits/aborts, and their scope can be local to a transaction or global across systems.
  • Deadlock Potential: Requires careful design and management by the programmer to avoid deadlocks, where two or more programs are waiting indefinitely for resources held by each other.
  • Serialization Assurance: Ensures that only one program or transaction can modify a specific resource at a given time, preventing lost updates, inconsistent reads, or other data integrity issues.

Use Cases

• • CICS Resource Serialization: Using EXEC CICS ENQ and DEQ commands to serialize access to application-defined resources (e.g., a counter, a control record, or a logical resource name) within a CICS region or across multiple regions via shared queues.
  • DB2 Table Locking: Employing the LOCK TABLE SQL statement to acquire an exclusive or share lock on an entire DB2 table, typically before performing a large batch update or read operation to ensure consistency and prevent contention.
  • IMS DB Segment Locking: Programs can explicitly request exclusive control over specific IMS database segments using PROCOPT=P or GHU (Get Hold Unique) calls to ensure that no other program can update that segment while it's being processed.
  • Batch Program Serialization: Using z/OS ENQ and DEQ macros directly in batch applications to serialize access to shared datasets, control files, or critical sections of code, preventing concurrent execution conflicts.

Related Concepts