Show TOC

Process Flow of a Token RequestLocate this document in the navigation structure

Use

Assigning a Token to a Token Manager

The CSL assigns a token to a token manager so that it can note the current state of a token. How is a token localized if there is no central token manager for the CSL to contact? Instead of a central token manager, each token has a master system. This is the logical system of the token key where the key is generated by the CSL.

Requesting and Localizing the Token

Before a critical section, programs request a token (also known as a lock) by calling a local function module ( CSLEO_ENQUEUE). The CSL then uses the token manager in this system to determine whether the token already exists or if it existed previously. That is, whether there is an entry for the token in the token manager table. If so, the CSL reacts according to the status:

  1. If the status is FREE (assignment is NOT locked by a standard lock), the CSL assigns the token to the application.

  2. If the status is FREE (assignment is locked by a standard lock) or REFD, the CSL triggers the FOREIGN_LOCK exception.

  3. If the status is MOVD, the token has been moved to another system. The CSL then contacts the token manager in the system that is indicated by the status.

If no entry for the requested token exists in this system, the CSL then contacts the master system to determine the status of the token. The master system determines the CSL from the token key.

There are now two options in the master system:

  • The token already exists. The CSL then proceeds in the same way as the steps above.

  • The token does NOT exist. It is generated by the token manager in the master system and is moved to the system that requested the token.

This means that the token can be determined by the entries in the corresponding token manager. If the token is free, the CSL moves it to the system that requested it; if it is NOT free, the CSL triggers the FOREIGN_LOCK exception.

Note

If a token manager is unable to find the token in the system that is referenced by the MOVD status, the CSL triggers the INCONSISTENCY exception because the CSL database tables are inconsistent.

Moving the Token

Once a free token has been found in a system, the CSL locks this token in this system and in the system that requested the token. The CSL uses a standard lock to do this so that local requests are rejected. The CSL then sets the status in the former system to MOVD and in the latter system to FREE. Strictly speaking, a token is not moved, but the information is updated about the current owner of the token in the linked systems.The function module does not exist yet.