Server Merging Procedures

Transfer Points

Install all points from the retired system onto the destination system. Digital State Table and Digital Tags

Make all changes to the digital state table before making any changes to the points.

Review the retired system digital-state table. Use piconfig to extract any missing digital-sets and create them on the target system. If a set from the retired system already exists in the target system, make sure both have the same states.

Digital points created on the target system are assigned a digital set by name.

During archive conversion, only the offset is preserved, thus the data is interpreted according to the point’s current digital-set.

Point Editing / Creation

Use piconfig to dump all required point attributes from all points to be merged to the

destination system. Required point attributes are interface specific. If in doubt, dump all point attributes for all points, except the PointID and RecNo attributes. Remember that point attributes depend on the point class, therefore, not all points have the same attributes. All points do not have to be merged - just the points whose history is to be preserved. Tags names issues must be addressed. If a tag name is the same on both systems, for example, sinusoid, which is a standard simulation point, no special steps are required. If the tags are not the same a rename is required. Normally the conflicting retired tag is renamed; although either tag may be renamed. Required renames should be done before starting the merger.

On the destination system, use piconfig and the retired system's point listing to create the points.

PI Batch Subsystem Considerations

Special steps are necessary for systems running pibatch. Batches are stored in automatically created points. The points are in the format of pibaN, where N is an integer unique to the unit. These points must not be converted to the destination system.

Batches must be moved independently of the points. The piconfig utility may be used to move the batches. First, use piconfig to dump all existing batches and unit configuration. Unit name conflicts between the two systems will require renaming the references to the conflicting units in the piconfig dumps.

Use the PIBatch unit table listing to create the units on the destination system. The batches are created after the archives are converted. All pertinent unit configuration information must be listed.

Details of these steps are shown below in the example merger.

Create a Point ID Conversion Table on the Retired System

Converting the retired archives to the destination system requires mapping the retired record numbers to the destination system record numbers. The mapping is established with a text file, which relates the retired system PointIDs, RecNos, and tags. The following piconfig script creates the input for the conversion table:

@table pipoint

@ostr pointid,recno,tag @select tag=*

@ends @exit

Running this script with output redirected to a file is all that is required. This example assumes all tags are being merged. If all tags are not merged, edit the output file or use a tag selection of other than "tag=*".

The ID conversion input file must only have entries of the format:

pointid,recno,tag

Any other entries, such as comments, are not allowed and will cause errors. Therefore, edit the file to remove any piconfig informational messages at the end of the file. Also, a new line must follow the last entry.

If PIUnitBatches are being migrated, rename the UniqueID’s of the old PIUnit to the UniqueID’s of the destination PIUnit as described above.

Cutover Interfaces

At this time, interfaces feeding data to the retired system should be stopped. If appropriate, restart the interfaces pointing to the destination system. If the interfaces are restarted against the destination system, check interface output for errors--address any problems before proceeding.

On the retired system run pishutev to put shutdown events into the Snapshot. This will force the Snapshot value into the Archive.

9.1 - Server Merging - Procedures

Force a Shift on the Retired System

Force a shift on the retired system. This puts a clean end time on the retired system, and makes management of the Archive merge easier.

Run piartool -al to get a listing of all archives. Save this listing for reference when converting the archives.

At this point the retired system is no longer needed. Shutdown the retired system. Move all retired archives to the destination system. For Unix systems this might mean using binary ftp.

Create Binary ID Conversion Table on Destination System

The text file created in the above step is the source for creating the ID conversion table. This table maps the tags from the old system into the new one. The piartool utility creates the ID conversion table; the syntax is:

piartool -idci <full path to text file> -idco <full path to binary file to be created>

This command is run on the destination system.

Convert the Retired Archives

The offline archive features of piarchss are used to convert the archives from the retired system. The syntax is:

piarchss -id <id conversion binary file> -if <retired archive path>

-of <converted archive path>

There are a few things to consider when converting archives. If the retired system and destination system were running simultaneously, there will be overlapping archive dates. Overlapping archives must be combined using offline archive techniques. Also, by default, offline output archives are created as dynamic type. That is, they are not shiftable. The "-f" argument may be used to force output archives to a fixed size.

Convert one archive and register it. If necessary, unregister any overlapping existing archives. Use piconfig or a client product to view data from this archive. Compare the data with the old system and assure correct conversion before proceeding with other archives.

Proceed with the archive processing. This may be time consuming; especially if there are many overlapping archives. Register and view archives as they are completed.

Add Batches from Retired Systems

The text file from the PI Batch dump is now input via piconfig into the system. If all archives were merged, there should be an archive on line to receive the batch. If not all archives were migrated, batches for those dates will not be created.