DBS concepts

This topic explains certain concepts of DBS that are important to the planners and implementers for ThruPut Manager. Some of these concepts are explained in the DBS Concepts and Facilities manual, but for convenience we repeat them here.

The DBS View of Tape Subsystems

Before we describe Drive Pools, we first need to explain the structure of the different types of drives, modes of operation of each drive, and the different vendors as seen by DBS. There is nothing particularly unique about DBS’s view but since several choices were available, you should understand the DBS approach.

The DBS view of tape drives is consistent with the way the software support for this type of hardware is generated and referred to. The lowest level is what we call a Drive Pool. The aggregation of Drive Pools is done in four hierarchical levels:

Level 1 (highest level) represents the IBM device types, for example 3590. All devices generated with the generic name 3590-1 (regardless of what physical hardware they truly represent) are aggregated at Level 1 for the 3590 device type.
Level 2 represents the devices associated with a particular vendor. For actual physical drives we have two distinct vendors: IBM and StorageTek. For Virtual Tapes we have two additional vendors with a software solution: CA-Vtape and COPYCROSS.
Level 3 represents the mode each vendor uses to manage the drives: Manual, Automated, and Virtual.
Level 4 represents the type of drive. It has a level and an associated sublevel. The level shows how the system recognizes the device, for example 3480. (This is the same device that is aggregated at Level 1 and is found in the EDT.)

The sublevel represents the actual type of drive. For example, for an IBM 3590-1 the sub-device could be a 3590H or a 3590E. For StorageTek, a 3590-1 could be a T9940A35. Standard system allocation is unaware of the sublevel.

To summarize:

Level 1: Total number of devices for each generic device type, regardless of vendor, mode of operation, or type of drive.
Level 2: The Vendor (IBM, StorageTek, COPYCROSS, CA-Vtape).
Level 3: Mode of Operation (Manual, Automated, Virtual).
Level 4: Generic Device type (e. g. 3590-1).

Sublevel: Actual device (e. g. 3590H).

When defining drives to DBS, you have to be concerned with only the lowest possible level, that is, the Sublevel for Level 4. This represents the device type that the person creating this type of definition is familiar with. DBS then calculates the aggregated values for all other levels.

These levels dictate the sequence in which you define your devices to DBS:

You select the vendor.
You select the mode of operation.
You define your libraries by naming them and selecting the generic device types.
You associate specific device numbers with the device types.

Once you grasp this structure, it is relatively easy to understand DBS Drive Pools.

Drive Pools

A Drive Pool represents the lowest possible group that can satisfy a particular allocation. Any device in the group is interchangeable for the purpose of non-directed allocation (directed allocation takes place when a request is made for an specific device number, for example ‘0380’). To illustrate the point we can use IBM’s Virtual Tape Systems (VTS).

If an installation has only one VTS subsystem then the answer is obvious. All the device numbers associated with the VTS represent a unique DBS Pool.

With two VTS subsystems, even though the devices are homogeneous (all 3490E) the device numbers are not interchangeable across VTS subsystems. This is simply the result of a set of device addresses not having access to a set of volumes. So, at least for specific volume requests, we have two distinct DBS Drive Pools.

In the case of a non-specific request, depending on the installation’s SMS definitions, prior to allocation it might not be possible to determine what DBS Drive Pool will be used to satisfy the allocation. Here is where the next DBS Level plays a role. DBS knows that the allocation will be satisfied by a VTS, so it uses the values of the “aggregated” Virtual Drive Pools until the allocation takes place. Once the allocation has occurred, the actual DBS Drive Pool is known. At that time (immediately after allocation) DBS does the necessary adjustment to reflect the actual DBS Drive Pool.

Work Groups

DBS Work Groups allow the logical segmentation of your workload so that you can control how different types of jobs compete for the devices in a Drive Pool. In simple terms this could be your Production versus Non-Production workloads. This service is optional.

For each Work Group, you assign minimum and maximum values for every Drive Pool. This is organized in a two-level structure, represented in the following DBS work group structure diagram.

What this structure means is that you can first segment your workload into three possible groups. For example: Production, Non-Production, Development. Each of these three groups can then be subdivided into two groups.

What is the purpose of these divisions? In essence it is to “apportion” the existing drives in a manner that recognizes the type of work in question. For simplification, let’s assume the following:

There are only two possible groups: Production, Non-production.
There are 64 available drives.

If you do not define Work Groups then Production and Non-Production will have up to 64 drives at their disposal and they will contend for them. With Work Groups you could decide that Production can allocate any of the 64 drives but Non-production is only allowed 32 drives. In this way you have created an environment where Production has 32 drives for their sole use and another 32 to contend with Non-Production jobs. Non-Production does not have dedicated drives but can contend for up to 32 drives with Production.

Since there is a set of Work Group values for every Drive Pool, you can view the Drive Pool as the description of what is available and the Work Groups as “who gets what.”

The DBS View of Your Installation

DBS manages the tape drive counts for a particular JESplex. The reason for this scope is that batch is managed at the JESplex level. Once the JESplex is identified, the participating systems are then identified. This is for the purpose of verification.

The tape subsystems are defined first to the JESplex. Here, all the possible universe of device numbers that can be seen by any of the participating systems is defined.

By design, the participating systems inherit all the tape drives that are defined to the JESplex. This assumes that you have a symmetric environment:

If this is the case, then no device specification is necessary at the system level.
If the environment is not symmetric, then the drives that are not visible to a particular system are removed from that system’s list.

DBS supports drives that have one device number on one system but a different device number on another system. It does not support environments that have different devices with the same device number in different systems. Please note:

DBS does not perform tape switching or sharing.

The installation is expected to have a solution to this problem. Either IBM’s Tape Switching facility or CA’s Tape Sharing facility (or any other similar facility) is expected to be in place in environments that share tape drives across multiple systems.

Counts Versus Device Numbers

It should be noted that all this management is done with “counts.” DBS does not direct allocation to particular device numbers. The device numbers are provided to DBS for the purpose of verification after allocation has done its work. This approach greatly simplifies the facility and eliminates any possible conflict between system allocation’s opinion and that of DBS. Allocation is always right, so when DBS finds itself in disagreement with allocation, it discreetly changes its mind.

It is important to understand that the device number list can contain more devices than the Drive Pool count. This means that if the system allocates any of the device numbers in the list, the in-use count for its associated Drive Pool is updated.

The Configuration and Policies

In order to manage your installation’s tape drives, DBS uses a Configuration and one or more Policies:

A configuration provides DBS with a description of the physical and virtual drives to be managed.
A policy describes to DBS how to manage the resources defined in the Configuration.

DBS needs to know what is available to the JESplex under its management. DBS cannot assume that because a device is “visible” to a system it is to be available for batch processing. So the simplest approach is for the installation to inform DBS of what is under its control. This is called a DBS Configuration. It includes all the maximum inventory available to the JESplex. In fact, you can (and should) include future devices in the Configuration.

Within a given Configuration, an installation can create Policies. In a Policy, the installation describes how the tape drives (or a subset) are to be deployed.

You change a Configuration only when your tape subsystems are being modified, for example, when a bank of drives is about to be removed. Think of the Configuration as a static framework in which Policies operate.

Policies are designed to be as fluid as the installation needs them to be. When you define a Configuration, you automatically define your initial Policy, which is called “**BASE**”. This Policy assumes that all systems in the JESplex share all defined drives unless you edit it.

You can have only one Configuration and one Policy active at any given time in the JESplex. Activating a new Configuration is a more restricted action than activating a Policy. The removal of devices can impact jobs that are already in the system, so DBS provides facilities to ensure effective transitions that will not result in jobs being failed. On the other hand, Policies can be activated and deactivated at any time.

DBS Priorities

For jobs that are not managed by SLM, DBS allows you to assign a priority through JAL or JECL:

LOW
MEDIUM, which is the default.
HIGH

When contention occurs, the DBS Priority determines which step gets the drive. See Setting DBS Priorities.

DBS and Started Tasks/Jobs

Started tasks that allocate drives (defined to DBS) can run in one of two modes:

As DBS participants
As poachers

This is not an all-or-nothing situation. You can run some in one mode and others in the other mode. If you do not take any actions, they are treated as poachers.

DBS regularly reviews the status of the drives it is managing. When it finds out that some of the devices it is managing are allocated to a non-registered task it treats that task as a poacher. It collects as much information as possible and records it in the poachers section.

The count adjustments for poachers are done differently from DBS registered users. When a drive is confirmed, after allocation, to have been allocated to a registered user the following takes place:

The available count is reduced.
The in-use count is increased.
The total number of drives is not altered (available + in-use).
The device number is flagged as in-use.

When a drive is found to have been poached, the following takes place:

The count of device numbers in the defined list is compared to the total count.
If there are more drives in the device number list than in the count (the reverse cannot happen), then:
- The particular device number is flagged as in-use by a poacher.
- The device number will be associated with the poaching task until DBS detects that it is no longer allocated.
- No other adjustments are made.
If the count of the device number list matches the total count, then:
- The total count is reduced. It is treated as if DBS has lost a drive.
- The available count, by definition, is equally reduced.
- The device number is flagged as in-use by a poacher.
- DBS will be short of one drive until the poacher gives up the drive.

The installation might prefer to run the started tasks as a DBS participant. A JECL statement is available for that purpose. The type and number of devices can be specified for each step that dynamically allocates drives. For each specified Pool, two values can be coded:

One value represents the static allocation needs.
The other value represents the dynamic allocation needs.

The second value results in DBS reserving the equivalent number of drives for the duration of the step. For started tasks that cannot handle dynamic allocation failures, the RESERVE mechanism is a good solution.

Batch Jobs and Dynamic Allocation

You can let DBS know that a particular job/step allocates drives dynamically. As indicated earlier, DAL directives and a JECL statement are available for that purpose.

The JECL statement has the same format as the one to be used with started tasks. The only difference is that of the two values that can be coded as the count of drives needed, only the first one has meaning. The second value represents static allocation needs for a started task. It is not needed for batch jobs because the static count is calculated at analysis time. If you code a value in the second field for batch jobs it is ignored.

New Descriptors in JAL

A new set of job descriptors have been added to JAL. They more closely parallel the DBS Pools than the traditional UNIT counts. There is a section later in this publication, DBS and Job Limiting (JLS) that outlines the difference between the old UNIT descriptors and the new DBS Pool Descriptors.