In this subsection the prerequisites and the processes required to create an RDB environment from an existing system is outlined. The assumption is that there is an existing system that becomes the primary system.
It is also assumed that the logistics associated with moving from a non-RDB to an RDB environment have been made, including the manner in which the database is cloned.
When using configure to convert the existing system to the primary system, the secondary database can be established in the either of the following ways:
The configure process can include taking of an offline dump of the entire primary system to disk, transfer that file to the host that houses the secondary copy of the database and load the data into the secondary database.
Or
An offline dump of the existing system can be taken immediately prior to the configure that is used to convert the existing database to a primary database. This dump (probably on tape) should then be available on the host where the secondary database resides when the configure is done that converts the existing system to a primary system.
To create an RDB environment from an existing system, you have to:
Configure the Base and Existing Systems
Convert an Existing System to RTU
Setup Configuration Required to Implement RDB
Implement RDB
Configuring the Base and Existing Systems
You have to first identify a base system. If you have an existing system that is suitable for use then this can be used. Any system that always contains the current production code and can at any time be used to transfer code to the existing system (both currently and after it becomes a primary system) is suitable.
If no such system exists, you should first create a system. Note that the database used for the base system is not transferred anywhere; therefore the database might contain any or no data.
If the existing system is already maintained using RTU from a system that fulfils the role of base system then no further preparation is required.
However if the existing system is currently maintained through builds, you should now perform a full system transfer from the base system to the existing system. The existing system should never again be generated directly from Developer.
Converting an Existing System to RTU
If the existing system (that is to become the Primary) is already maintained through RTU from an existing base system then the process outlined here is not required.
If you have created a new base system then the process described here should be carried out to ensure that the base and existing systems are using exactly the same code and database structure.
If the existing system has been maintained through builds, then the process described here should be carried out to ensure that the base and existing systems are using exactly the same code and database structure.
To configure an existing system to RTU, perform the following:
In the Configuration properties for the Segment Select Deployment then Configure/ BNA for the Configuration set that was used for the existing system.
Set the following fields:
Set the Configuration set type to Configure.
Set the Host Builder Usercode, Configure Work Pack, and Host Builder Dict. Pack. Under General, select the Retain Existing Database check box.
In the Folder Configuration properties, the Deploy Application Components, Deploy Database and Deploy Reports should be false. Set Generate Runtime Transfer Utility File to true and enter the filename and the Base Configuration set in the Runtime Transfer section.
Click OK to save the settings.
Create an RTU file as explained in the RTU topic.
Run the RTU Utility as explained in the Using the RTU topic.
On the Transfer Startup screen, perform the following:
Enter the name of segment in the Business Segment field.
Enter name of the base system Configuration set in the Generate Set used for generate field.
enter name of the existing Configuration set in the Configure Generate Set field.
Enter the name of the transferred RTU file in the RTU File Title field.
The RDB Generate Set field should be left blank.
Press XMIT. The Transfer Selection Screen appears.
Ensure that the data at the bottom of the screen reflects the data appropriate for the existing system (if not then the wrong genset has been used or settings are incorrect). Ensure that Retain Existing Database field is set to Y (if this is set to N then the 'Configure/BNA gen' settings set earlier are incorrect).
If corrections are necessary type a BYE on the Action Line field to exit the RTU, correct the settings above and create another RTU file.
If the settings are correct, then change the Transfer Medium field to DISK. Make a note of the Configure work pack field and press XMIT. The Transfer Creation Screen appears.
Enter the appropriate transfer data in the Usercode and Password fields and press XMIT.
The RTU completes after starting a transfer job. Once this job completes files are ready for installation against the existing system. Log on to the usercode you specified above and RUN the following program.
RUNTIMETRANFER/<host name>/<existing system Configuration set name>/ <base system name>/CONFIGURE
This installs all the transferred files.
By default, the entire system (including all reports) should have been transferred. The existing system is now therefore has the same code as the base system.
Setting up Configuration Required to Implement RDB
At this stage, the following assumptions are made:
The base system is configured.
The existing system which is set to become the primary system, is configured.
An RTU transfer of the entire system and all reports has been done from the base to the existing systems.
Notes:
These changes are made once only and then maintained as needed as is normal for Configuration sets.
If your existing system specifies, in the subsystem list on the segment, a non-zero value in the 'MIN copies' field for any subsystem, this should be set to zero after noting down the current settings (for restoring later). This is important as having MIN copies field set causes the system to be brought up at inconvenient times while a configure is in progress.
There are currently two configuration sets - one for the base system and one for the existing system.
To create and configure a third configuration set, perform the following:
Create a new configuration set as a copy of the existing system's configuration set. The maximum length of the name is limited to ten characters.
Select the new configuration and access the configuration properties for the segment.
Set Deployment to True, then Configure/BNA, and perform the following:
Set the Configure Set Type to RDB.
Select the Configure New Clone option for the Retain existing database property.
Complete the remaining properties in the Configure section with the details about host and the location of the MCP Runtime software on the host that will house the secondary copy of the database.
Under Installation category, set the values for the DMSII usercode and pack fields
Select the Remote Database category and set the values for the fields to define the RDB settings. The fields on this dialog box are described in the Agile Business Suite Developer User Guide. Refer to the ClearPath Enterprise Servers Remote Database Backup Planning and Operations Guide for more information on these fields and their significance to RDB.
Select General and under Persistence category, perform the following:
Set the Alternate Name and database names fields to the same value as primary.
Note: If DMSII is unusercoded on DISK then a usercode of * and a pack of DISK must be specified.
Set the Usercode for the system and any other required settings.
Select Deployment, and under Installation category, perform the following:
Set the required pack names to be used for all non-database files – Audit, Duplicate Audit, Dictionary, Reorg, Default, Object, Extract, ROC Output.
Any database file settings are ignored as the packs used for the secondary database are established using pack mapping as identified below for the primary system generate set settings.
In the Pack Mapping Segment configuration property, enter any required mapping of database packs. This is a facility that allows the packs used in the primary database to be substituted for a different pack name for the secondary database. If no pack mapping is entered, the primary and secondary databases uses the same pack names on both hosts. The format is <primary pack name> = <secondary pack name>; <prim pk 2> = <sec pk 2>
Select the existing system configuration set and for the segment, and perform the following:
Select Deployment, and under Installation category, set Clone Database to True.
Under Remote Database, enter the name of the new configuration set just created above as the RDB configuration set.
You are now ready to proceed with creating the primary from the existing system and creating the entire secondary database and system.
Implementing RDB
This process converts the existing database to an RDB primary and create the secondary database. Note that creating a secondary system is a separate process, but it is highly recommend that both processes be done together as a single unit of work.
Note: The core assumption here is that the sole purpose of this transfer be to implement RDB. The base and existing systems should therefore be identical and unchanged since the last transfer.
The existing system should be brought down for the duration.
Perform the following:
If the cloning of the database is to use an offline dump taken manually then this dump should be taken now and then transported to the secondary host.
An RTU transfer should now be done from the base to the existing system. The following steps describe processes unique to this transfer compared to previous transfers.
An RTU file should be created. The Secondary Configuration set should specify the Base and the RDB configuration set.
When running the RTU, on the Transfer Startup Screen, enter the names of the three Configuration set names (that is, base, existing and RDB). Select a full system transfer (that is, reports are not needed) and allow the transfer to complete.
The configure should be run as normal except that towards the end a utility called NGEN28/RDB is run. You will be asked to specify a tape name for the offline dump or a response of OK (as in <mix number>AX OK. If you specify OK then an offline dump is taken now, the dump is transferred to the secondary and loaded. If you do not respond with OK then the load of the secondary database is started using your response to the AX as a DMUTILITY dump tape name.
When the configure completes, the system can be brought up as normal. This results in the secondary database being brought up as well as the new primary system. You now have a primary and secondary database up and running.
Return to the Segment Configuration properties for the primary. Select Deployment and under Installation category, set the Clone Database property to False.
On the Folder Configuration properties for the RDB set, set Runtime Transfer Utility file to true and fill in the Runtime File name and the Configuration set used in the Build should be the Primary Configuration set. The Retain Database property should be set to Configure New Clone and the Configure Set Type property should be set to Configure. Create the RTU file.
Perform another RTU and configure process to deploy all system files to the secondary host and perform the following:
On the Transfer Startup screen, specify the name of the primary system generate set in the Generate Set used for generate field and the name of the secondary system generate set in the Configure Generate Set field. The RDB Generate Set should be left blank.
On the Transfer Selection Screen, set the Transfer Medium field to DISK and also specify that the system and all reports should be transferred.
On the Transfer Creation Screen, ensure that the Target computer (host) Name field is set to the name of the secondary host.
The transfer process proceeds and create the RUNTIMETRANSFER files on the secondary host.
Log on to the secondary host and run the configure as normal. The <genset name> is that of the secondary system and the <system name> is that of both the primary and secondary systems. This installs all the system files needed to have a fully functional system available on the secondary system.
Use the COMS DISABLE command to DISABLE the DB and WINDOW of the secondary system to ensure that the secondary system is not brought up accidentally.
Earlier, if you have changed the subsystem MIN copies field value, the original settings might be restored now. These settings are re-implemented the next time that RTU transfers are done to the primary and secondary system.
Once the first configure of the Secondary system is done, in the Segment Configuration properties for RDB, change the option of the Retain Existing Database property to Retain Existing Cloned option.
Create an RTU file and place the file as normal on the primary host.
The above processes that you have completed are not repeated again. The settings in every generate set will now only change as circumstances demand it.