HP Archive Backup System for OpenVMS Guide to Operations

HP Archive Backup System for OpenVMS Guide to Operations HP Archive Backup System for OpenVMS Guide to Operations

h71000.www7.hp.com
from h71000.www7.hp.com More from this publisher
06.11.2014 Views

Migrating from SLS/MDMS V2.X to ABS/MDMS V4.X B.2 SLS/MDMS V2.x to ABS/MDMS V4.x Migration Note The device on which the SLS/MDMS V2.x databases are located must be provided for the conversion to proceed further. In a mixed-architecture (Alpha/VAX) OpenVMS Cluster, the SLS/MDMS V2.x TAPEMAST.DAT (volume database file), is typically located on a shared device accessible by both the Alpha and VAX nodes. You need to identify the device where the TAPEMAST.DAT file is located. – During the conversion, any command that caused a conflict or a change in the object when the MDMS$LOAD_DB_.COM was executed, is logged into a node specific conflicts file: Format: MDMS$LOAD_DB_CONFLICTS_.COM To view the conflicts file, you need to give the complete file name: MDMS$SYSTEM:MDMS$LOAD_DB_CONFLICTS_.COM For information on resolving conflicts, see Section B.2.4.1.3, “Resolving Conflicts during the Conversion”. Note This conversion must be executed on every node that has a different TAPE- START.COM and populates the MDMS database. 2. Adding the nodes from the Database Access Authorization file (VALIDATE.DAT) to the Node database. This addition/part of the conversion is executed only once on the database server node. – The conversion process prompts you to restart the MDMS server as the server must be active for the database to be populated with the node objects. On providing your consent, the conversion process automatically restarts the MDMS server. 3. Converting the following SLS/MDMS V2.x database files to ABS/MDMS V4.x database files: – Pool Authorization file (POOLAUTH.DAT) – Slot Definition file (SLOTMAST.DAT) – Volume Database file (TAPEMAST.DAT) – Magazine Database file (SLS$MAGAZINE_MASTER_FILE.DAT) This conversion is executed only once on the database server node. MDMS server should not be active during the conversion of the above-mentioned database files. The conversion process informs you that the MDMS server must be shutdown to proceed with the conversion. On providing your consent, the conversion process automatically shuts down the server and complete the conversion. Note On any other node that does not use the same TAPESTART.COM as the database node, in addition to converting the SBK (SLS System Backup) files, you also convert the TAPESTART.COM. B–20 Migrating from SLS/MDMS V2.X to ABS/MDMS V4.X

Migrating from SLS/MDMS V2.X to ABS/MDMS V4.X B.2 SLS/MDMS V2.x to ABS/MDMS V4.x Migration B.2.4.1.2 Executing the Conversion Command Procedure – This is an interactive command procedure wherein the conversion process prompts you for particular inputs. Based on the inputs received, it provides you the required information and also the intended outputs. The whole concept is about converting SLS/MDMS V2.x Symbols and Database objects into ABS/MDMS V4.x Database objects. When the command procedure is executed, a brief on what exactly are converted from SLS/MDMS V2.x and how they are converted is displayed. For more information, see Section B.2.4.1.1, “Phases in SLS/MDMS V2.x to ABS/MDMS V4.x Conversion”. Note SLS/MDMS V2.x DB server must be shut down before executing the conversion command procedure. Use the following command to shut down the SLS/MDMS V2.x DB server: $ @SLS$SYSTEM:SLS$SHUTDOWN To execute the conversion command procedure, type the following command at the DCL prompt (this command procedure is copied to MDMS$ROOT:[SYSTEM] during the ABS/MDMS installation): $ @MDMS$SYSTEM:MDMS$CONVERT_V2_TO_V4 • The conversion procedure at every stage prompts you on whether you want to proceed with the conversion or cancel it. • The conversion procedure in order to execute or complete certain sections of the conversion has to restart MDMS server. When informed, provide your consent and the conversion process automatically restarts MDMS server to complete the intended task. • The conversion procedure generates a conflicts file to log all the conflicts generated during the conversion. B.2.4.1.3 Resolving Conflicts during the Conversion – The differences between SLS/MDMS V2.x and ABS/MDMS V4.x result in conflicts during the conversion. Instead of stopping the conversion and prompting you to verify every conflict, the conversion program generates a node-specific conflicts file and logs all the conflicts for every conversion: $ TYPE MDMS$LOAD_DB_CONFLICTS_.COM In the above-mentioned file name, is replaced by the actual node name where the conversion procedure is executed. The conflicts file provides you the commands that were executed and which caused a change in the database. The change is flagged because there already existed an object in the database or that particular command changed an attribute of the existing object. Note The conflicts file must not be executed, instead you have to go through each and every conflict logged, and resolve it. Migrating from SLS/MDMS V2.X to ABS/MDMS V4.X B–21

Migrating from SLS/MDMS V2.X <strong>to</strong> ABS/MDMS V4.X<br />

B.2 SLS/MDMS V2.x <strong>to</strong> ABS/MDMS V4.x Migration<br />

Note<br />

The device on which the SLS/MDMS V2.x databases are located must be provided <strong>for</strong><br />

the conversion <strong>to</strong> proceed further. In a mixed-architecture (Alpha/VAX) <strong>OpenVMS</strong><br />

Cluster, the SLS/MDMS V2.x TAPEMAST.DAT (volume database file), is typically<br />

located on a shared device accessible by both the Alpha and VAX nodes. You need <strong>to</strong><br />

identify the device where the TAPEMAST.DAT file is located.<br />

– During the conversion, any command that caused a conflict or a change in the object<br />

when the MDMS$LOAD_DB_.COM was executed, is logged in<strong>to</strong> a node<br />

specific conflicts file:<br />

Format: MDMS$LOAD_DB_CONFLICTS_.COM<br />

To view the conflicts file, you need <strong>to</strong> give the complete file name:<br />

MDMS$SYSTEM:MDMS$LOAD_DB_CONFLICTS_.COM<br />

For in<strong>for</strong>mation on resolving conflicts, see Section B.2.4.1.3, “Resolving Conflicts during<br />

the Conversion”.<br />

Note<br />

This conversion must be executed on every node that has a different TAPE-<br />

START.COM and populates the MDMS database.<br />

2. Adding the nodes from the Database Access Authorization file (VALIDATE.DAT) <strong>to</strong> the<br />

Node database. This addition/part of the conversion is executed only once on the database<br />

server node.<br />

– The conversion process prompts you <strong>to</strong> restart the MDMS server as the server must be<br />

active <strong>for</strong> the database <strong>to</strong> be populated with the node objects. On providing your consent,<br />

the conversion process au<strong>to</strong>matically restarts the MDMS server.<br />

3. Converting the following SLS/MDMS V2.x database files <strong>to</strong> ABS/MDMS V4.x database<br />

files:<br />

– Pool Authorization file (POOLAUTH.DAT)<br />

– Slot Definition file (SLOTMAST.DAT)<br />

– Volume Database file (TAPEMAST.DAT)<br />

– Magazine Database file (SLS$MAGAZINE_MASTER_FILE.DAT)<br />

This conversion is executed only once on the database server node.<br />

MDMS server should not be active during the conversion of the above-mentioned database<br />

files. The conversion process in<strong>for</strong>ms you that the MDMS server must be shutdown<br />

<strong>to</strong> proceed with the conversion. On providing your consent, the conversion<br />

process au<strong>to</strong>matically shuts down the server and complete the conversion.<br />

Note<br />

On any other node that does not use the same TAPESTART.COM as the database<br />

node, in addition <strong>to</strong> converting the SBK (SLS <strong>System</strong> <strong>Backup</strong>) files, you also convert<br />

the TAPESTART.COM.<br />

B–20 Migrating from SLS/MDMS V2.X <strong>to</strong> ABS/MDMS V4.X

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!