Modifications in the ROBAR rule files

If the standard files do not cover all the requirements of your data center, you can modify them before the relevant ROBAR-SV instance is started to suit the needs of your data center at your own responsibility before ROBAR is used for the first time.
The ROBAR-SV service department will only correct errors arising from an original ROBAR rule file in conjunction with the standard maintenance contract.

The ROBAR-SV Manager offers user-friendly functions for editing ROBAR rule files using the ROBAR editor, see section "Editing the ROBAR rule files".

The ROBAR message_file and message_resp shipped with ROBAR-SV can be adapted to user requirements, i.e. you can make optional entries directly in the relevant file in accordance with the options described in the relevant introduction.
The standard maintenance contract, which otherwise relates only to the ROBAR rule files in their original state, extends to these changes.

Responsibility for changes to the supplied ROBAR rule files that go beyond this must be borne by the person that made them (e.g. additional software vendor).
If the ROBAR rule files are shipped to the customer by an additional software vendor, it is the vendor who is responsible for maintenance of the changes made to the ROBAR rule files. The customer must regulate this in the contracts concluded with these vendors.
The standard maintenance contract covers neither diagnosis nor correction of errors arising from modification of a ROBAR rule file. This type of error must be diagnosed and corrected by the person responsible for the modifications, and not by the ROBAR-SV service.

Support for ROBAR-SV installations with customer-specific ROBAR rule files that goes beyond the general customer support and product range can be offered by the manufacturer within the framework of an additional consultancy agreement or customer-specific project. The same is true for additional support for ROBAR rule files that were obtained from additional software vendors.

The BS2000 file SYSPAR.ROBAR-CL.<ver>.PROZPARAM contains default times set for connection monitoring. If these times do not suit your requirements, you can change them before starting ROBAR-CL.

Adding new BS2000 messages

If the message number of the BS2000 system message has not been added to the SYSPAR.ROBAR-CL.<ver>.MESSAGES to add new messages to the default files, the operator must:

• terminate the DCAM application SYSPRG.ROBAR-CL.<ver>.DCAM, see section "Terminating ROBAR-CL-DCAM" in chapter "Operating ROBAR-CL".

• add the message number of the system message to the SYSPAR.ROBAR-CL.<ver>.MESSAGES file (see "File SYSPAR.ROBAR-CL.<ver>.MESSAGES").

• if not already done, allocate the routing code of the new message to the DCAM application before ROBAR-CL-DCAM is started (/ADD-CONSOLE-FILTER command).

• restart the DCAM application (see "Operating ROBAR-CL").

The changes to the SYSPAR.ROBAR-CL.<ver>.MESSAGES file do not take effect until ROBAR-CL-DCAM is restarted.

Modify ROBAR actions

You can modify and reactivate the ROBAR rule files on the ROBAR server during the current ROBAR session without having to terminate the relevant ROBAR-SV instance.

Delete BS2000 messages

If ROBAR is no longer required to process a BS2000 message, this message should be deleted from the files message_file and message_xref as well as from the file
SYSPAR.ROBAR-CL.<ver>.MESSAGES.
If a message is to be deactivated immediately or made ineffective temporarily, the message can be deleted in the message_file only.
If the message is deleted from the SYSPAR file, it is no longer forwarded to the ROBAR server and therefore the archive system is no longer instructed to react to this message.

Example for modifications in the ROBAR rule file message_xref

ROBAR is to deposit cartridges in the output area of the input/output unit for mounting on manually-operated devices. Mount jobs for robot-operated devices should be executed as normal.

Select a new message code from the range of free numbers reserved for you (MFV01) and make the following entries in the message_xref file (see also the section "Special characters in the files" in chapter "Description of the files"):

  :*:MFV01: RC001,MR408;\
  MR416;

The following actions are performed:

  :*:MFV01:

1.

RC001:'<####,MO  , ,FFFF,1,r,0mm,vvvvvv,....   >'F 
MR408: TYPE % ROB4008 TAPE CARTRIDGE MOUNTED (DEV=mmmm / TSN=tttt / 
VSN=vvvvvv) 

2. In the case of an error

MR416: TYPE % ROB4016 TAPE CARTRIDGE NOT MOUNTED (DEV=mmmm /
                     TSN=tttt / VSN=vvvvvv) 

Explanations of the ROBAR actions

1. The statements RC001 and MR408 are only executed if the device is robot-operated.

2. If an error occurs in the statements RC001 or MR408, the MR416 statement is executed. This completes job processing for robot-operated devices.

Example of issuing an archive system command from the BS2000 system

Archive system commands which are usually entered using the MANUAL menu can also be issued directly from the console. The variables expected by the archive system command must be set.

The operator wishes to output the archive record entry of the cartridge with the VSN A0001K on the console.

• The operator issues the following command at the console (see the “Commands” manuals [3]):

  /SEND-MESSAGE TO=OPERATOR,MESSAGE='<T ULV A0001K'

  The routing code T must be included in the list of routing codes defined in the SYSPAR.ROBAR-CL.<ver>.PROZPARAM file under the TypeRoutingcodes parameter.

• Select a new message code from the range of free numbers reserved for you (e.g. MFA99/MRA99) and make the following entries in the ROBAR rule files so that ROBAR can react to this request:

  • in the message_file file

    :*:MFA99: %<T ULV vvvvvv

  • in the message_xref file

    :*:MFA99: RC007,MRA99

    The archive system action RC007 (ULV command) is already in the roboter_cmds file; the BS2000 action MRA99 is redefined:

  • in the message_resp file

    MRA99: TYPE

    % ROBMA99 ARCHIVE RECORD ENTRY FOR VSN vvvvvv: COORDINATE=aaaaaaaa, STATUS=ss