Your Browser is not longer supported

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

{{viewport.spaceProperty.prod}}

RMS REP Mounting System

&pagelevel(2)&pagelevel

Version:

RMS V7.1G

Privileges:

TSOS

The REP Mounting System (RMS) is used for the management, documentation, delivery and mounting of REP packets and preliminary corrections. The product is used both internally by service centers (user groups 1 and 2, see below) and by external customers (user groups 3 and 4, see below).

RMS was conceived as a four-level application for the following four user groups (see also "User groups and operations"):

  • User group 1: development or equivalent

  • User group 2: support center or service center

  • User group 3: customer

  • User group 4: customer’s internal data center

All user groups have access to the same RMS functionality. The administration and implementation of all necessary operations is thus standardized and simplified. No additional effort is required on the part of the customer.
Each user group has its own file (depot) containing the following information specific to each user group:

  • all REP corrections and descriptions

  • their origin and the related product

  • scope of all operations and the time at which they were carried out

  • loader definition and history

All functions can be used in interactive mode and are menu-driven. Some functions can also be used in batch mode. This allows for the automatic operation of all essential functions - for all four user groups - without manual intervention and taking due consideration of all user-specific requirements.

In RMS dialog, the term “system loader” is occasionally used as a synonym for “loader” (subsystem loader).

Use of RMS

The following diagram clarifies the sequence of events with RMS with respect to the four user groups.

Figure 16: Use of RMS
Notes
  1. A packet (or set) of software corrections (REPs) for a specific version of a product is generated from the PULS procedure. This packet is stored in a REP file.

  2. This REP file (RMS delivery packet or RMS revision packet; both terms are used) is received by RMS and placed in a depot. All software product version-specific REPs, comments on these REPs, status (active, not activated) etc. are entered in this depot. The newly-input RMS delivery packets can be edited in the depot using RMS. For instance, they can be supplemented with your own additional REPs or comments or activated and deactivated.

  3. From the depot, in turn an RMS delivery packet can be generated to be forwarded to the next user group. It is forwarded via SOLIS or the customer’s own procedure. The next user group then uses RMS to import this RMS delivery packet into its depot and edit it further, if required.

    A loader can also be generated from the depot. A loader is a REP file whose contents are applied when a product is started. It is generated by RMS as a user-group-specific selection of REPs for a particular product version, and is saved under a fixed, productspecific name.

  4. Point 3 can be carried out by user groups 1, 2 and 3. User group 4 can only generate loaders.