After the flash copy - assure_mimix - 10.0

Assure MIMIX with FlashCopy Environment User Guide
Product type
Software
Portfolio
Integrate
Product family
Assure
Product
Assure MIMIX™ Software
Version
10.0
Language
English
Product name
Assure MIMIX
Title
Assure MIMIX with FlashCopy Environment User Guide
Topic type
How Do I
First publish date
2020

Once the newly duplicated system is available and on the network, we can start replication. The actions needed for this can be performed manually, or can be scripted.

From a MIMIX perspective, both systems are identical. You must take care to ensure that the Set System After FlashCopy (SETSYSFLSH) and the Start DG After FlashCopy (STRDGFLSH) commands are invoked in the correct order and from the correct system. If you are working with a business partner who has added these commands to custom scripts, the scripts should call the commands in the correct order.

The following main activities need to be performed:
  1. Run the SETSYSFLSH TYPE(*NET) command on the newly created target system to identify it to the MIMIX configuration with the role of a network (*NET) system. This command must complete before continuing with the next activity.
  2. Run the SETSYSFLSH TYPE(*MGT) command on the original source system to identify it to the MIMIX configuration with the role of a management (*MGT) system.
  3. Run the STRDGFLSH command on the newly created target system. This program has to be called after the SETSYSFLSH is complete.

If you are using MIMIX for FlashCopy with scripts from a Precisely business partner, the business partner solution typically scripts the calls to run these commands. 

SETSYSFLSH command details: 

SETSYSFLSHTYPE(*NET|*MGT)HOST(<IP_address>|*NOCHG)

The SETSYSFLSH command identifies the MIMIX system type (*MGT or *NET) to associate with the system on which the command is run and sets the specified type within the associated system definition.

Note: Use care when running the SETSYSFLSH command. After a flash copy is made, this command must be run first on the target system with *NET specified, then from the source system with *MGT specified.

The System type (TYPE) parameter specifies the MIMIX system type to be associated with the local system and updates the local system to that designated type.

You can optionally specify a new IP address to use for the target system in the New IP address for tgt system (HOST) parameter. When the specified system type is *NET and an address is specified, the TCP server is started on the target system using the specified port. When the specified system is *MGT and an address is specified, the transfer definition is updated to reference the specified value. 

Identifying the newly created target to MIMIX as a *NET system

Typical call: SETSYSFLSH TYPE(*NET) 

Run this command from the newly created target.

When run on the target system created by the flash copy, the SETSYSFLSH TYPE(*NET) command updates the MIMIX configuration so that the system definition for the local system (the target) specifies its system type (TYPE) as *NET. The command also applies license keys found in the license key package (LKP), ends all MIMIX processes on the target system for the MIMIX instance, restarts the MIMIXSBS subsystem on the target system, and starts the system manager.

If an optional IP address is specified, the address is used to start the TCP servers (STRSVR command) on the target system (instead of the address specified in the transfer definition). This may be useful, if during the clone process, you were forced to keep the old clone active, and created a new one instead.

Identifying the original source system to MIMIX as a *MGT system

Typical call: SETSYSFLSH TYPE(*MGT)

Run this command from the original source system after the newly created target has been identified as a network system to MIMIX.

When run on the original source system, the SETSYSFLSH TYPE(*MGT) command updates the MIMIX configuration so that the system definition for the local system specifies its system type (TYPE) as *MGT.   

If an optional IP address is specified, the address is used to update the transfer definition to reference the specified value. The IP address specified here must be the same IP address that was specified on the SETSYSFLSH command when run on the target system. If no IP address was specified on the target system, then no IP address should be specified here.

When this activity completes, if you use the WRKSYS command, the resulting Work with Systems display should show active system managers.

Restarting the data group after the flash copy

Typical call: STRDGFLSH DGDFN(*ALL) 

Run this command from the original source system after SETSYSFLSH has been run for both systems in the MIMIX configuration.

The STRDGFLSH command forces a clear pending start of the specified replication processes for a data group after a FlashCopy. The FlashCopy created a copy of the system, so all objects are synchronized with the exception of files that had open commits at the time and which were automatically rolled back by the FlashCopy. This command also allows you to specify how to handle open commit cycles that existed for replicated files at the time the FlashCopy occurred. This command can only be run on a network system.

Note: Use this command only after running the SETSYSFLSH command to identify the MIMIX role of the target system. This command also resets internally used work logs and libraries, which means that replication history for the data group prior to running this command is lost.

Parameter details

STRDGFLSH
DGDFN(*ALL|<data-group-name>|<generic-name*>)
PRC(*ALL|*DBSRC|*DBRDR|*ALLSRC|*ALLTGT)
STRJRNDAT(*IPL|<date>|*LAST|*CURRENT *CURCHAIN)
MAXLOOKBCK(120|<minutes>|*NONE)
LDCMTACT(*START|*MSG)
AXAPWAIT(120|<minutes>|*NONE|*NOMAX)

Data group definition (DGDFN):Identifies the data group to be started,

Start Processes (PRC):Identifies the MIMIX processes to start.

Starting jrn entry for commits (STRJRNDAT): Identifies the date and time of the journal entry at which to start checking for open commits that rolled back after the FlashCopy. The oldest open commit ID with rollbacks following the specified starting point is used to determine where to start database replication processes for the data group. This parameter is also used for where to start object replication processes for the data group.

  • *IPL will use the date and time of the J-IA or J-IN journal entry of the IPL. This is the default value.
  • *LAST will use the date and time from the last journal entry in the current journal receiver.
  • *CURRENT will use the date and time of the first entry in the currently attached receiver.
  • *CURCHAIN will use the date and time of the first entry in the receiver chain that includes the journal receiver that is currently attached (all on the target system).
  • You can also specify the date in job date format.

Max time for look-back in jrn (MAXLOOKBCK): Specifies the maximum number of minutes before the specified starting journal entry (STRJRNDAT) to look back within the journal receivers for the start of the oldest open commit ID with rolled back transactions. If the oldest open commit started before this maximum amount of time, the specified value for the Action when old commit exists (OLDCMTACT) determines how the start data group request is processed. The default value is 120 minutes. This parameter is ignored when starting only Object Replication processes.

The maximum value is 9999 minutes, which is just under 7 days. A value this large can affect system performance. We recommend a value that is within a few hours of the flash copy.

Action when old commit exists (OLDCMTACT):Specifies how to proceed with the start data group request when the start time of the oldest open commit with rolled back transactions occurred before the specified maximum look-back time within the journal (MAXLOOKBCK). This parameter is ignored when starting only Object Replication processes.

  • *START - The journal entry sequence number of the oldest open commit with rolled back transactions that was started within the specified maximum look-back time (MAXLOOKBCK) before the starting journal entry (STRJRNDAT) will be used for starting data group replication processes. This is the default value.
  • *MSG - An error is sent to the job log and data group replication processes will not be started.

Max. wait for AP rebuilding (MAXAPWAIT): Specifies the maximum number of minutes to wait to complete rebuilding access paths for the files identified for replication by this data group before starting replication processes. This parameter is ignored if database apply processes are not part of the processes specified on Start processes (PRC) parameter. The default value is 120 minutes.

  • *NOMAX No maximum wait time is specified. The start request waits until rebuilding access paths has completed.
  • *NONE The start request is processed without waiting for access paths to be rebuilt.
  • You can also specify a number of minutes. Valid values are from 1 through 9,999.

Examples

Example 1: this example will search for IPL marker from April 23rd 23h00 onward.

STRDGFLSH DGDFN(*ALL) STRJRNDAT(042320 230000)

Example 2: this example can cause data loss, and is to force-start replication after receivers with J-IA was lost.

STRDGFLSH DGDFN(*ALL) STRJRNDAT(*CURRENT)

Example 3: this example will not start the data groups if a commit-ID older than 120 minutes is found.

STRDGFLSH DGDFN(*ALL) OLDCMTACT(*MSG)

Example 4: this example will start data groups source jobs and remote journal, but not the apply jobs, so you can still run a tape backup.

STRDGFLSH DGDFN(*ALL) PRC(*ALLSRC)

Example 5: this example then complements the previous example, so that as soon as a save-while-active sync point is reached for a set of libraries, you can start the apply jobs.

STRDGFLSH DGDFN(<data-group-name>) PRC(*ALLTGT)