ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzaki_5.4.0.1/rzakiifsissue.htm

106 lines
9.6 KiB
HTML
Raw Normal View History

2024-04-02 14:02:31 +00:00
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en-us" xml:lang="en-us">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="security" content="public" />
<meta name="Robots" content="index,follow" />
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
<meta name="DC.Type" content="concept" />
<meta name="DC.Title" content="File identifier considerations for working with integrated file system entries" />
<meta name="abstract" content="If you plan to replay the integrated file system operations in the remote journal to objects on the target system, and if you primed that target system with objects that were restored from the source system, then some additional considerations apply to replaying those journal entries." />
<meta name="description" content="If you plan to replay the integrated file system operations in the remote journal to objects on the target system, and if you primed that target system with objects that were restored from the source system, then some additional considerations apply to replaying those journal entries." />
<meta name="DC.Relation" scheme="URI" content="rzakirgetinfo.htm" />
<meta name="DC.Relation" scheme="URI" content="../apis/qgetattr.htm" />
<meta name="DC.Relation" scheme="URI" content="../apis/getpthff.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakivarlength.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakichgjrnstate.htm" />
<meta name="DC.Relation" scheme="URI" content="rzakisaverestre.htm" />
<meta name="copyright" content="(C) Copyright IBM Corporation 2004, 2006" />
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2004, 2006" />
<meta name="DC.Format" content="XHTML" />
<meta name="DC.Identifier" content="rzakiifsissue" />
<meta name="DC.Language" content="en-us" />
<!-- All rights reserved. Licensed Materials Property of IBM -->
<!-- US Government Users Restricted Rights -->
<!-- Use, duplication or disclosure restricted by -->
<!-- GSA ADP Schedule Contract with IBM Corp. -->
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
<link rel="stylesheet" type="text/css" href="./ic.css" />
<title>File identifier considerations for working with integrated file system entries</title>
</head>
<body id="rzakiifsissue"><a name="rzakiifsissue"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">File identifier considerations for working with integrated file system entries</h1>
<div><p>If you plan to replay the integrated file system operations in the remote journal to objects on the target system, and if you primed that target system with objects that were restored from the
source system, then some additional considerations apply to replaying those journal entries.</p>
<p>Integrated file system journal entries on remote journals are only identified by the file identifier in the object name field. They are not identified by path name. When you restore an integrated file
system object on a remote system, the remote system does not maintain the same file identifier that was used on the source system. It assigns that object a new file ID. However, the journal entries in the
remote journal receiver refer to that object's original file ID. Therefore when you replay the journal entries you cannot use the file ID on the remote journal to find the path of the object. That file
ID will either not exist or be the file ID for the wrong object.</p>
<p>To prevent potential problems, it is recommended that you create a table that maps the old and new file IDs with the object's path. The map can be something like the following table:</p>
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><thead align="left"><tr><th valign="top" width="66.66666666666666%" id="d0e29">Object path</th>
<th valign="top" width="16.666666666666664%" id="d0e31">Source file ID</th>
<th valign="top" width="16.666666666666664%" id="d0e33">Target file ID</th>
</tr>
</thead>
<tbody><tr><td valign="top" width="66.66666666666666%" headers="d0e29 ">/myFolder/subFolder/MyObject</td>
<td valign="top" width="16.666666666666664%" headers="d0e31 ">123456...</td>
<td valign="top" width="16.666666666666664%" headers="d0e33 ">789123...</td>
</tr>
<tr><td valign="top" width="66.66666666666666%" headers="d0e29 ">/myNextFolder/anotherFolder/MyObject2</td>
<td valign="top" width="16.666666666666664%" headers="d0e31 ">654321...</td>
<td valign="top" width="16.666666666666664%" headers="d0e33 ">321987...</td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="rzakiifsissue__collectmappingfileids"><a name="rzakiifsissue__collectmappingfileids"><!-- --></a><h4 class="sectiontitle">Collect the information for mapping file IDs</h4><p>You can use different methods to determine the file IDs:</p>
<ul><li>Use local journaling on the target system where you restore the object.</li>
<li>Use the object's path to find its file ID with the Get Attributes (Qp0lGetAttr()) API on the source system.</li>
<li>Use the object's file ID to find its path with the Get Path Name of Object from Its File ID (Qp0lGetPathFromFileID()) API on the source system.</li>
</ul>
</div>
<div class="section"><h4 class="sectiontitle">Use local journaling on the target system</h4><p>If an object is journaled when you restore it to the target system, a B FR journal entry is deposited on the target system's local journal
receiver. The entry-specific data of the B FR journal entry contains the following:</p>
<ul><li>Media file identifier--the file ID of the object on the media. This file ID is the same as the object's file ID on the source system.</li>
<li>Restored file identifier--the object's new file ID after it is restored to the target system.</li>
<li>Restored over file identifier--the file ID of the object that was restored over.</li>
</ul>
<p>If you are concerned about the demand that journaling puts on the remote system's resources and storage space, you can put the journal in *STANDBY state. Even though the journal is
in standby state, the system still deposits B FR entries.</p>
</div>
<div class="section"><h4 class="sectiontitle">Use the object's path to find its file ID with the Qp0lGetAttr() API</h4><p>On the source side, if you know the object's path but do not know its file ID, you can use the Qp0lGetAttr()
API to get the file ID. This is especially helpful if you do not want to use journaling on the remote system. You then need to send that information over to the target system to update the table which must
exist on the target system.</p>
</div>
<div class="section"><h4 class="sectiontitle">Use the object's file ID to find its path with the Qp0lGetPathFromFileID() API</h4><p>On the source side, if you know the object's file ID, but do not know it's path, you can find it
using the Qp0lGetPathFromFileID() API. You can then use this path to replay the journal entries on the target system, assuming that the path on the target system is the same as the path on the source system.
This API will only return an absolute path name of the object. If the object has more than one path name, the API only returns one path. You then need to send that information over to the target system
to build the table which must exist on the target system.</p>
</div>
<div class="section"><h4 class="sectiontitle">Maintain the table as the replicator job applies journal entries</h4><p>Once you have the table created, you must keep it updated. One way to keep the table updated is to update the table
as the replicator job applies journal entries. On the target system, when the replicator job applies entries to do operations such as creating objects, adding links, or removing links, the journal entry
information in these entries has the path name and file ID in it at that time. As the operation is replayed you can use this information to build the table on the target system.</p>
</div>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzakirgetinfo.htm" title="Working with the journal entries in a remote journal is essentially the same as working with the journal entries in a local journal.">Get information about remote journal entries</a></div>
</div>
<div class="relconcepts"><strong>Related concepts</strong><br />
<div><a href="rzakivarlength.htm" title="The following tables contain the variable-length portion of the layouts for journal entries.">Layouts for variable-length portion of journal entries</a></div>
<div><a href="rzakisaverestre.htm" title="The following information describes general considerations for save and restore operations with remote journals:">Considerations for save and restore operations with remote journals</a></div>
</div>
<div class="reltasks"><strong>Related tasks</strong><br />
<div><a href="rzakichgjrnstate.htm" title="Local journals can be in one of two states, active or standby. When the journal state of a local journal is active, journal entries are allowed to be deposited to the journal receiver.">Change the state of local journals</a></div>
</div>
<div class="relref"><strong>Related reference</strong><br />
<div><a href="../apis/qgetattr.htm">Get Attributes (Qp0lGetAttr()) API</a></div>
<div><a href="../apis/getpthff.htm">Get Path Name of Object from Its File ID (Qp0lGetPathFromFileID()) API</a></div>
</div>
</div>
</body>
</html>