Advanced CA IDMS Programming Topics › Managing Queued Resources

Managing Queued Resources

Resources are objects that your program must explicitly ask for before it can do any work. Multiple resources may be required to perform a logical unit of work. For example, a database area is a resource that you ask for by issuing a READY statement; a database record occurrence is a resource that you ask for by issuing a FIND/OBTAIN statement.

Holding Resources

The number of resources that you hold and the way that you hold them affects other run units. For example, resources can be shared or exclusive.

You should adhere to the following guidelines when holding resources:

• Free resources as soon as you are finished in order that other run units can access them.
• Hold resources for as short a time as possible.
• Acquire the lowest-level lock that you need. For example, use shared locks instead of exclusive locks whenever possible.

Examples of Resources

Typical resources include:

• Database areas
• Database records
• Storage areas
• Common routines
• Queues
• Site-specific functions (for example, database update)

Meaning of Queued Resource

Your site may utilize queued resources. A queued resource is any resource that requires serial access. That is, only one program can access it at a time.

DC allows you to perform the following resource management functions:

• You can test to see if a resource is currently available.
• You can acquire a resource for exclusive use.
• You can release a previously acquired resource.

These functions are explained below, followed by a list of suggestions that you can use to avoid deadlocks.

Testing for Resource Availability

To determine if a resource or list of resources is currently available, perform the following steps:

1. Issue an ENQUEUE request that includes the TEST parameter.
2. Check for the following statuses:
3. 0000 indicates that all the tested resources were available and have now been enqueued for your task.
   • 3908 indicates that at least one of the tested resources is already owned by another task.
   • 3909 indicates that at least one of the tested resources is not yet owned by another task and is available to your task.

Acquiring Resources

To acquire and lock a resource or list of resources, perform the following steps:

1. Issue an ENQUEUE request that includes either the WAIT or the NOWAIT parameter.
2. Check for the following statuses:
   • 0000 indicates that all requested resources have been acquired and locked.
   • 3901 indicates that at least one of the tested resources cannot be enqueued immediately; to wait would cause a deadlock. No new resources have been acquired.
   • 3908 indicates that at least one of the tested resources is currently owned by another task. No new resources have been acquired.

Releasing Resources

After all processing is complete, release resources by issuing a DEQUEUE statement. You can release resources by name or all at once (by including the ALL parameter).

Avoiding Deadlock

One of the conditions of deadlock is that a program is holding resources while waiting for other resources. The following list explains techniques that your site can use to minimize this condition:

• Request all required resources at the same time. Whenever possible, you should try to ensure that your program isn't holding resources while waiting for other resources.
• If you are denied access to a resource, you should release all previously acquired resources and start over. After you release previously acquired resources, you can acquire all resources at the same time, as specified above.
• Your site can follow a protocol of sequential order. All programs follow a protocol that prescribes the order in which database records will be retrieved and updated.

  Note: This protocol will work only if every program in the system follows it.

  For example, all update applications that use an area sweep can agree to enter the database starting with the DEPARTMENT record rather than the OFFICE record.

  This protocol can also specify the order in which locks will be acquired and released.

Sharing Queued Resources Between CA IDMS Systems

In a data sharing environment, queued resources can be shared between CA IDMS systems that are members of a data sharing group. The benefit of sharing these resources is that access to them can be controlled between programs executing on any member of the group. Whether or not a specific queued resource is shared, is determined by specifications made by the CA IDMS system administrator. Programs accessing queued resources are not sensitive to whether or not a resource is shared, since the DML syntax is the same in either case.