Overview

This chapter introduces the resource definitions and describes Group and List, which are resource definition management types. This chapter also describes the resources managed as resource control table type such as Program List Table (PLT) and Transaction List Table (XLT).

1. Resource Definition

The OpenFrame/OSC (hereafter OSC) system provides a variety of resources for application programs to use the functions provided by the OSC system and to rehost the existing application programs which were running on IBM CICS Transaction Server (hereafter CICS).

A resource definition describes which resources will be used by the OSC system, what the characteristics of the resources are, and how to use the resources. In order to use the functions provided by the OSC system, the user has to provide the system resource information such as programs, transactions, and terminals. Each resource has different settings depending on its characteristics, therefore the user has to set the settings and register the resource definition according to the operating environment.

Resource definitions are written as macro scripts and then registered to the OSC SD (OSC System Definition) table using the oscsdgen tool. Then, each resource registered will be loaded to the RTSD (Runtime System Definition) memory when OSC starts.

OSC application servers run based on the resource definitions loaded on the RTSD memory. OSC provides the oscsdgen and oscsddump tools to register/backup the resource definitions to the OSC SD table as well as the oscrtsddump and oscrtsdupdate tools to backup/update the resources loaded in the RTSD memory. OSDC application servers also enables the [OSC] menu in OpenFrame Manager to manage OSC SD and RTSD tables.

Resource Definition Registration and Management

For more information about the [OSC] menu in OpenFrame Manager, refer to OpenFrame Manager User Guide.

OSC SD Table

OSC SD (OSC System Definition) tables store the resource definitions used by the OSC system. The administrator can store the content of resource definition macro files to the OSC SD table by using the oscsdgen tool and can register each resource definition by using the [OSC] menu in OpenFrame Manager.

Depending on the operating environment of OSC, one individual application server can use several different OSC SD tables or several application servers can use one OSC SD table. If one OSC SD table is shared by several application servers, the Group and the List of resources used by each application server can be set differently in order to load only the corresponding resources to the RTSD table when OSC starts.

For more information about creating OSC SD tables, refer to OpenFrame OSC Administrator’s Guide.

RTSD Table

Runtime System Definition (RTSD) memory contains the information stored when the OSC system starts, specifically the resource definitions registered in the OSC SD table. The application server refers to the RTSD table for the resource definitions during operation; it does not connect to the OSC SD table directly during operation.

RTSD data is managed in a database table for multi-node clustering functionality. It is designed for resources with infrequent updates to use Tcache to minimize performance degradation.

The administrator can use the RTSD tool provided by OSC or the [OSC] menu in OpenFrame Manager to manage the RTSD data and to apply the changes to an application server in real time. Therefore the changing of RTSD must be carried out with care. When OSC ends, the resource definitions in the RTSD data will be deleted, therefore in order to store it permanently, the resource definitions of the OSC SD table must be modified.

2. Group and List

The resource definitions registered in the OSC SD table are composed of Group and List. Group and List are the units that the application server uses to manage the resource definitions. Proper resource definitions are written for a specific operation of OSC.

2.1. Group and List Definition

Group is a set of resources provided to manage the related resources easily. Each resource cannot be registered in an OSC SD table without a Group to which each resource will belong, therefore a Group must first be defined. The elements of the resources included in a Group can be set by the user. Similar resources can belong in one Group, or all the resources used in one application can belong in one Group. The OSC system administrator has to define the Groups in such a way that the resource definitions can be managed easily.

List contains the names of the Groups to be loaded to the RTSD table when the OSC system starts. Therefore, set the Groups, which contain the resource definitions required to start the OSC system, to the List. It is not necessary for a Group to belong to a List and therefore a Group can be set independently of a List.

2.2. Relationship between Group/List and Resource

As a sub element of a List, a Group represents a set of related resources. There is no way to create a group directly. A Group can be generated with the GROUP option when defining a resource. List is a resource management unit of the application server. The application server can generate multiple Lists and a Group can belong to several Lists according to the management purpose.

The following is an example of the relationship between a Group and resource definitions. DFHFILE is a Group containing OIVPFILE and TESTFILE which are resources. Resources are managed by the unit of Group.

Relationship between Resource and Group

The following is an example the relationship between three Lists DFHLIST, INITLIST, and OSCLIST and the Groups included in the Lists.

Relationship between Group and List

The left column represents the List view - a list of Lists and the Groups that are registered in those Lists. The right column represents the Group view - a list of Groups and the names of the Lists in which those Groups are registered. By looking at the relationship between resources and Groups, as shown in Relationship between Resource and Group, as well as the relationship between Groups and Lists as shown in the previous figure, the hierarchical structure becomes evident. Several Groups can be registered in a List, the upper class, and several resources can be registered in a Group. For example, the OIVPFILE resource has the following hierarchical structure: DFHLIST-DFHFILE-OIVPFILE.

Groups and Lists starting with DFH are provided by OSC, therefore the DFH string must not be used when creating a name for a Group or List.
A Group and List cannot have the same name, therefore specify different names for each.

2.3. GRPLIST

The application server loads the Lists into RTSD table when it is started, by referring to the GRPLIST element of the environment settings which specifies which Lists to load. The administrator can set up to four Lists to be loaded at startup. At this time, if a resource included in a Group is a duplicate of a resource in another Group in a List, the latter resource will be loaded to the RTSD table. Therefore the administrator has to set the order of Groups and Lists carefully to ensure that the resources are loaded to the RTSD table in the desired order.

For more information about configuring GRPLIST, refer to "6.4.3. SD" in OpenFrame Configuration Guide.

The following example specifies DFHLIST, INITLIST, and OSCLIST sequentially to GRPLIST.

GRPLIST=DFHLIST,INITLIST,OSCLIST

The following shows how the Groups are ordered when specifying the GRPLIST as shown in the previous example.

The order of Groups included in DFHLIST.
```
DFHFILE
DFHTDQ
DFHTSQ
...
```
The order of Groups included in INITLIST.
```
OIVP
INITFILE
INITTDQ
```
The order of Groups included in OSCLIST.
```
OIVP
OSCFILE
```
Because of the order of the Groups included in the GRPLIST, when the OSC application server starts, the resources belonging to DFHFILE will be loaded first, the resources belonging to INITLIST will be loaded next, and the resources belonging to OSCFILE will be loaded last into the RTSD table.
```
DFHFILE
DFHTDQ
DFHTSQ
...
OIVP
INITFILE
INITTDQ
OIVP
OSCFILE
```

The GRPLIST provides convenience for administrators in managing the resource definitions used by the application server. For example, if multiple application servers share one OSC SD, by setting the GRPLIST to be generated by an individual List created for each server the resources can be used without having to register OSC SD resource definitions in the table. Efficient maintenance is also possible by managing the resources by dividing them into several Lists according to the purpose of the OSC function rather than managing all the resources with a single List.

3. Resource Control Table

The resource control table is a macro definition described as a control table type for the parts of resources that are used by CICS.

A user can describe information for the Program List Table (PLT) macro and the Transaction List Table (XLT) macro. For each macro, the OSC system loads the compiled information of the macro and provides the functions. OSC provides the oscpltc and the oscxltc tools to compile the PLT macro and the XLT macro, respectively.

PLT

Program List Table (PLT) is a table which arranges the list of programs. It is used to specify the programs to be executed during the OSC region booting and shutting down process. Each table is classified by the SUFFIX value. If you set the PLTPI and PLTSD value of the GENERAL section in the osc.{servername} subject to the SUFFIX of the table, the tables will be involved in the booting and shutting down processes.
XLT

Transaction List Table (XLT) is a table which describes the list of transactions involved logically. The XLT is used to set a list of transactions which can be requested from the terminal while executing the first stage of the PLT program when shutting down the OSC region. Each table is classified by the SUFFIX value, which can be set in the XLT value of the GENERAL section in the osc.{servername} subject.

For more information about the resource control table, refer to Resource Control Table.