If the clone unit is a complete copy of the original unit, all the data on the clone unit is available to an application. While an application is working with the data on the original unit, no other application can use the copied data on the clone unit. If more than two applications are to be able to access the data, multiple clone sessions can be set up so that each application can work with its own data.
In the BS2000 environment, the main concern is to process or save the data of a pubset. Consequently, in this section it is always assumed that complete pubsets are processed and mirrored/copied homogeneously. A copy of a pubset’s data is made on the clone units which are assigned to the original units of the pubset. For simplicity’s sake, the clone units of a pubset are referred to as a clone pubset.
A clone pubset made from split clone units should always be renamed.
Processing of the data by multiple applications
With this utilization it is assumed that an application processes the pubset’s data on the original units. This will generally be the main application with the longest access times and the largest update volume. A separate clone session is set up for every further application which is to access the data. Before an application accesses the data, the original and clone units are synchronized.
Example for QuickOPC
Pubset A comprises three units. In addition to the main application (“Main”), two further applications (“Save” and “Report”) sporadically access the data of pubset A. Two clone sessions are started.
In normal operation only the “Main” application accesses the data. When the “Save” application wants to access the data, the clone session is started. The clone units are activated automatically. The pubset is renamed (a synchronization point should be created beforehand, see "Activating clone pairs"):
/START-CLONE-SESSION UNIT=*BY-PUBSET (PUBSET=A,NEW-PUBSET=B,HOLD-IO=*UNTIL-ACTIVATED),
CLONE-UNIT=(2000,2001,2002)
The “Save” application can now access the data of clone pubset B directly. This data is the original data from activation time. After access has been terminated, the clone session remains unchanged.
If the “Save” option is to access the updated data again, the /RESTART-CLONE-SESSION command is entered once more:
/RESTART-CLONE-SESSION UNIT=*BY-PUBSET
(PUBSET=A,NEW-PUBSET=B,HOLD-IO=*UNTIL-ACTIVATED),
CLONE-UNIT=*BY-PUBSET(CLONE-PUBSET=B)
The procedure for the “Report” application is the same except that the clone pubset name here is C:
/START-CLONE-SESSION UNIT=*BY-PUBSET
(PUBSET=A,NEW-PUBSET=C,HOLD-IO=*UNTIL-ACTIVATED),CLONE-UNIT=(1000,1001,1002)
Updating the data on the clone units:
/RESTART-CLONE-SESSION UNIT=*BY-PUBSET (PUBSET=A,NEW-PUBSET=C,HOLD-IO=*UNTIL-ACTIVATED),
CLONE-UNIT=*BY-PUBSET(CLONE-PUBSET=C)
The “Main”, “Save” and “Report” applications access the data relatively independently of each other. Interruptions occur only when a synchronization point is created ahead of an /RESTART-CLONE-SESSION command.
Example for EC
Pubset A comprises three units. In addition to the main application (“Main”), two further applications (“Save” and “Report”) sporadically access the data of pubset A. Two clone sessions are started:
/START-CLONE-SESSION UNIT=*BY-PUBSET(PUBSET=A),CLONE-UNIT=(2000,2001,2002)
/START-CLONE-SESSION UNIT=*BY-PUBSET(PUBSET=A),CLONE-UNIT=(1000,1001,1002)
In normal operation only the “Main” application accesses the data. When the “Save” application wants to access the data, the clone units of a session are activated. The pubset is then renamed (a synchronization point should be created beforehand, see "Activating clone pairs"):
/ACTIVATE-CLONE UNIT=*BY-PUBSET (PUBSET=A,NEW-PUBSET=B,HOLD-IO=*UNTIL-ACTIVATED),
CLONE-UNIT=(2000,2001,2002)
The “Save” application can now access the data of clone pubset B directly. This data is the original data from activation time. After access has been terminated, the clone session is restarted so that the data can once more be synchronized between the original and clone units:
/RESTART-CLONE-SESSION UNIT=*BY-PUBSET(PUBSET=A),CLONE-UNIT=*BY-PUBSET(CLONE-PUBSET=B)
If the “Save” option is to access the updated data again, the /ACTIVATE-CLONE command is entered once more.
The procedure for the “Report” application is the same except that the clone pubset name here is C:
/ACTIVATE-CLONE UNIT=*BY-PUBSET (PUBSET=A,NEW-PUBSET=C,HOLD-IO=*UNTIL-ACTIVATED),
CLONE-UNIT=(1000,1001,1002)
After the application has terminated:
/RESTART-CLONE-SESSION UNIT=*BY-PUBSET(PUBSET=A),CLONE-UNIT=*BY-PUBSET(CLONE-PUBSET=C)
The “Main”, “Save” and “Report” applications access the data relatively independently of each other. Interruptions occur only when a synchronization point is created ahead of an /ACTIVATE-CLONE command.
Clone units with QuickOPC, EC
QuickOPC, EC can be used in the same way if the clone unit is a complete copy of the original unit.
On ETERNUS DX/AF and for new applications, the usage of the more flexible and strategic QuickOPC function is recommended. It is also the prerequisite for using the “Continuous Copy” function for Storage Clusters.
The EC functionality can be mirrored to ETERNUS DX/AF with some minor restrictions to QuickOPC.
The following table provides an overview of the equivalent commands:
Commands for EC | Commands for QuickOPC |
|
|
| Not required |
|
|
| Not available |
|
|
|
|