Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Multiprocessing

Requests addressed to a ROBAR-SV instance are processed asynchronously and simultaneously (multi-processing).

The multi-processing concept employed by ROBAR-SV allows the archive system to be used to the full. While a normal MTC processing request is waiting to be executed, for instance, requests from other processes, such as a request to the archive system, can be executed. A single ROBAR-SV installation can process up to 10 requests per archive system and robot arm at the same time.

You define the number of processes that can be performed simultaneously in the interface-specific ROBAR-SV configuration file. At least one process must, but no more than 10 processes can be defined. The default value is 10 processes (see Info #2).

Parallel processing improves system performance when the request currently being processed by ROBAR-SV cannot be continued until a certain event has taken place (e.g. waiting for NKVT097 UNLOAD INITIATED).

Cleaning up a volume after use

Depending on the tape position, an indefinite period of time may pass between UNLOAD INITIATED and Volume ready (for cleanup). Therefore ROBAR-SV assigned KEEP requests for cleaning up a used volume at relatively short intervals. With the availability of the DISMOUNT MANAGERS (see Reference Guides of the archive systems), this procedure has been changed. The DISMOUNT MANAGER receives the KEEP request and controls the KEEP cycle according to the preset values.

The following paragraph only applies to archive systems without DISMOUNT MANAGER:

KEEP requests can be delayed with delay times that can be defined in the ROBAR rule file. In this way you can avoid the robot being blocked by permanent KEEP requests. This means that longer delay times can be defined without robot processing being interrupted. Longer delay times can be set with the following options:

  • MRV01 for exporting after a normal UNLOAD message

  • MRVFi and MRVGi for dismounting after an emergency unload (if an error occurs)

  • MRVAi for cleaning the MTC device

    i = 3 for device LTO-Ux

    i = 4 for ETERNUS CS


Notes on setting wait times

The adjustment of the wait times in the direction of the maximum MTC rewind times does guarantee the highest level of robot availability (no interruption through unsuccessful UNMOUNT attempts), however the availability of the MTC devices and the cartridges is frequently not satisfactory. Such settings are only practical if there is a large number of MTC devices available and the same cartridge is rarely affected by successive requests. The optimum values for the settings can be determined by observing the behavior of the robot.

The following table contains information on the settings that can be used to eliminate the problems described.


Problem

Option 

Action                         

Cartridge rewind time is too long

MRV01

Increase the value

MTC device not available as the robot is removing the MTC from the MTC device long after unloading

MRV01

Reduce the value

Robot is waiting for the cleaning cartridge to be unloaded

MRVAi1

Increase the value

MTC device not available as the robot is removing the cleaning cartridge from the MTC device long after unloading

MRVAi1

Reduce the value

Archive system timeout (message N206) after message NKVT097 occurred

MRV01

Increase the value

Archive system timeout (message N206) after KEEP for cleaning cartridges

MRVAi1

Increase the value

After a device error (message EXC0858), the robot remains in front of the affected MTC device

MRVFi1
MRVGi1

Increase the value2
Reduce the value2

After a device error (message EXC0858), the robot does not remove the cartridge from the affected MTC device immediately

MRVFi1
MRVGi1

Reduce the value2
Increase the value2

1

i = 3 for device typeLTO-Ux; i = 4 for ETERNUS CS

2

each by the same value

The most frequent reason for time loss in the archive system is the requesting of a robot KEEP operation for an MTC device even though the tape will be removed in a few seconds time. This situation arises in the following cases:

  • A BS2000 task releases a cartridge, NDM then informs the system via console message NKVT097 that the cartridge is being unloaded and instructs the MTC device to rewind and unload the cartridge. ROBAR reacts to message NKVT097 by requesting a robot KEEP operation for this MTC device. The archive system is blocked until the cartridge is unloaded or an archive system timeout occurs.

  • With certain MTC device or cartridge errors (e.g. loss of tape tension) the emergency unload process is initiated for the affected device (by ROBAR using the robot command ULU or using the operator command /UNLOAD). The cartridge is then rewound slowly and then unloaded. If a KEEP operation is requested during this phase, the robot is blocked for the duration of the rewind time (which can last several minutes).

  • ROBAR initiates the mounting of a cleaning cartridge according to the parameters set, but also when eliminating certain MTC device errors. If a KEEP operation is requested for this cleaning cartridge immediately after MOUNT CLEAN, it blocks the robot until the cleaning process is complete.

The default of ten processes defined in the multiprocessing_level configuration parameter (maximum value) need only be replaced with a lower value if the memory of the ROBAR server becomes saturated.