Browse Prior Art Database

# Generalized Scheme for Control Block Relocation

IP.com Disclosure Number: IPCOM000078741D
Original Publication Date: 1973-Feb-01
Included in the Prior Art Database: 2005-Feb-26
Document File: 4 page(s) / 37K

IBM

## Related People

Cwiakala, R: AUTHOR [+2]

## Abstract

Chain integrity within a set of relocated control!O!blocks can be readily maintained. The statement of the problem is twofold, i.e., (1) relocating the actual chained control blocks from one set of locations isomorphically to another, and (2) given a sequential audit trail of "chained control blocks" (including multiple entries of that control block), then this technique provides the capability of relocating these control blocks and preserving the original chain integrity that existed prior to the audit trail.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 36% of the total text.

Page 1 of 4

Generalized Scheme for Control Block Relocation

Chain integrity within a set of relocated control!O!blocks can be readily maintained. The statement of the problem is twofold, i.e., (1) relocating the actual chained control blocks from one set of locations isomorphically to another, and (2) given a sequential audit trail of "chained control blocks" (including multiple entries of that control block), then this technique provides the capability of relocating these control blocks and preserving the original chain integrity that existed prior to the audit trail.

One solution to the problem follows. Given three types of control blocks, A, B and C. Each type has a pointer set as follows: A type: A type pointer; B type pointer; C type pointer; B type: B type pointer; C type pointer; C type: A type pointer; B type pointer. An example is shown in Fig. 1. In this example, let A type pointer = 10 (location of A) B type pointer = 50 (location of B) C type pointer = 100 (location of C). Now suppose these control blocks have to be relocated to locations: 30, 90 and 200, respectively. The control block relocation scheme works as follows. Implicit in this scheme is the creation of the Virtual Address Translation (VAT) table, where the VAT would look like: Old New Control Address Address Block Type 10 30 A 50 90 B 100 200 C.

As a control block is moved from one location to another, both its old and new address are filled into the VAT. Once all of the control blocks have been relocated, the process is not complete as the pointer fields must also be updated to reflect this relocation.

The VAT is scanned by looking at the new address (this is to select a control block to update). Thus, in our example 30, control block type A, would be selected first. The type field in the VAT describes the type of control block being relocated (from 10 to 30 in this example). Based upon the type, it is known further which pointer fields have to be updated within (e.g., since this is an A type = A type pointer, B type pointer, and C type pointer have to be updated).

To accomplish this, the pointer field contents are used as a search argument down the OLD addresses in the VAT. When a match is found, the "old address" in the pointer field is replaced by the corresponding "new address" found in the VAT; e.g., if A type pointer field is to be updated in A, then the contents of A type pointer 10 is used as a search on the VAT, a match is found and the 10 is replaced by the corresponding new address in the VAT 30.

Similarly, this is done for all of the control blocks with entries in the VAT and for all pointer fields within those control blocks. This scheme works when merely moving a set of control blocks from one area isomorphically to another area.

Another solution will now be described. If the mapping is "onto" and not 1-1, then the scheme works as follows: this is the example of the audit; e.g., a tape media containing three copies of control block type A (written out se...