IBM® Tivoli® Storage Manager (TSM) supports a wide variety of hardware mass storage devices including the IBM System Storage DR550, which can be used as the fixed content system in support of a P8 fixed storage area.
IBM System Storage DR550 combines storage, server, and software retention components into a lockable cabinet.
NOTE: The IBM FileNet P8 4.5.0 FP2 (4.5.0-002) release supports IBM System Storage DR550 devices that use magnetic disk storage only.
The Content Engine stores the content of Documents that are checked into a TSM Fixed Storage Area as archive objects on the TSM server. Each Content Transfer object of the Document is stored as a separate named object on the TSM server. Retention is applied to the named TSM objects based on the TSM management class associated with the Fixed Storage Area. Content Engine allows either a Chronological or Event-Based management class to be associated with a TSM Fixed Storage Area.
TivoliFixedContentDevice represents a single DR550 server instance. The configuration data contains the IP address, port number of the TSM server, and a client node name (the Content Engine in this case) and password. This data is written to an options file (DSM.SYS on UNIX servers, DSM.OPT on Windows servers), which is used to connect to the DR550 device.
FixedStorageArea represents the staging area for the DR550 device. Content is always uploaded to this staging area before being migrated to the DR550 device.
The Fixed Content Provider (FCP) pool contains a set of FCPs for a given Fixed Content Device.
For information on Fixed Content Device properties for Tivoli Storage Manager and DR550, see the Fixed Content Devices properties (General tab).
Content Engine supports static retention, which is applied when a document is checked in and which prevents deletion until after the retention period expires. When connected to a Tivoli Storage Manager server, such as a DR550 device, CE can use either scheme that is available on the TSM server: Event-Based Retention, or Chronological Retention coupled with the Hold/Release capability. CE leverages the behavior of the TSM management class to control when a document can be deleted. Unless Chronological Retention is explicitly required, you should use Event-Based Retention for the following reasons:
Content Engine always remains in control of the document deletion process. So even though TSM servers, such as the DR550, support the automatic deletion of objects after their retention period has expired, CE will not allow it until after the retention period has expired AND a user specifically deletes the associated document from the CE. When both conditions are met, CE relinquishes control of the TSM object, allowing TSM to automatically delete it.
To control retention while suppressing automatic deletion, Content Engine uses the specific parameters of the two retention schemes available in TSM as shown in the following table.
Parameter and purpose | Value for chronological retention | Value for event-based retention |
---|---|---|
RETINIT Determines when to initiate the retention period defined in the RETVER attribute |
CREATION (start counting when the object is archived) |
EVENT (start counting when the event is triggered) |
RETVER Number of days to retain the archived object after retention is initiated |
1 to 30,000 days, or NOLIMIT | 0 to 30,000 days |
RETMIN Minimum number of days to retain the archived object |
Not applicable | n, where n represents a number of days |
A chronological management class uses the RETVER parameter to protect a TSM object. The RETVER parameter defines the number of days that the object should be retained starting from the date that the object is stored on DR550.
TSM automatically deletes objects when their retention period (RETVER) on the DR550 has expired. To enable CE to retain control of the objects with chronological retention, the CE places a hold on the object after creation. Later, when the document is finally eligible for deletion, after the RETVER has expired and a user deletes the associated document, the CE releases the hold and allows the TSM automatic deletion process to delete the object.
NOTE: Placing a hold on an object requires a TSM retention protection license, so the chronological retention scheme cannot be used without this license. CE filters chronological management classes out of the CmTivoliManagementClassSet if the retention protection flag in the Fixed Content Device is OFF.
When you create a TSM management class to support chronological retention, use the following parameters:
RETINIT=CREATION RETVER=<actual retention period>
NOTE: The minimum value that can be assigned to RETVER in a Chronological Management Class for CE to be able to place a hold and prevent automatic deletion is 1 day. Content Engine automatically filters out all Chronological Management Classes with RETVER=0. Therefore, it is not possible to create a TSM Fixed Storage Area with no retention, based on a Chronological Retention Management Class.
An EBR management class has two retention settings that combine to protect a TSM object. The RETMIN parameter defines the minimum retention period for the object from creation time. The RETVER parameter defines the retention from the time of activation. As long as the EBR "activate" event is not issued, the object is protected from deletion, no matter what the value is for RETMIN. When the EBR "activate" event is issued, the retention period defined in RETVER is applied from that moment. It might or it might not overlap with RETMIN. If RETVER=0, for example, and the "activate" event is issued during the RETMIN period, the object continues to be protected until RETMIN expires.
Content Engine uses the behavior of the EBR management class to control when the TSM object can be deleted. If you set in TSM an EBR class with RETMIN=365 and REVER=0, then you can create in CE a TSM Fixed Storage Area that uses the EBR management class. When a document is checked into this Fixed Storage Area, CE calculates the delete date (today + 365 days) and writes it to the ContentRetentionDate attribute of the document. When a user wants to delete the document more than one year later, the CE delete call sends an "activate" event to the TSM server, and because RETVER=0, the retention expires immediately, which allows the object to be deleted automatically by the TSM background task.
When you create a TSM management class to support event-based retention, use the following parameters:
RETINIT=EVENT RETVER=0 RETMIN=<actual retention period>
NOTE: The minimum value that can be assigned to RETVER in an EBR Management Class is 0, and no hold is placed by CE on the TSM objects binding to such a class. Setting RETVER=0 and RETMIN=0 provides a way to create a Fixed Storage Area with no storage-level retention while protecting the document from tampering and deletion. The CE application remains in full control of retention and deletion. This is the preferred setting for Records Management use cases.
CE creates or updates the TSM options files whenever a Fixed Content Device is created or altered. The shared options files define connection information for one or more TSM servers, and must be accessible to every CE instance in the domain.
NOTE: The shared TSM options files are in the directory referenced by Configuration Files Share property of the the TSM Fixed Content Device. These files are critical to the operation of CE and must not be deleted. They should also be included in all system backups and disaster recovery procedures.
On UNIX servers, the DSMI Directory property of the TSM FCD must be set to the location of the TSM client software directory that contains the dms.sys file (for example, /opt/tivoli/tsm/client/ba/bin). This directory should also be included in all system backups and disaster recovery procedures.
On Windows servers, the DSMI Directory property must not be set.
Each UNIX server where the Content Engine is running must have the TSM client software installed. Within the TSM client installation folders there is a dsm.sys file, which is used by all TSM clients on that server, including the Content Engine, to connect to TSM.
The CE maintains a shared version of the dsm.sys file in the folder defined by the Configuration Files Share property of the TSM Fixed Content Device. The shared file is named IBMFileNetP8.dsm.sys. Each CE instance merges the changes it makes (and changes that other CE instances make) to the shared dsm.sys file into the local dsm.sys file on the server, which keeps all local dsm.sys files in sync with the CE shared dsm.sys file.
Note that it might be necessary to mount the shared options file folder with the uid=(username) option (where username is the user account that CE is running as. Without this option, CEMP could create the shared options files successfully on the mounted folder, but the files might not grant the CE user full control access, and CE would not be able to write the files.
On Windows servers, each TSM Fixed Content Device has a separate options file that is located in the folder referenced by the Configuration Files Share property. The options filename consists of the object identifier of the TSM Fixed Content Device (with the leading and trailing brackets removed) followed by ".opt" file extension. On Windows an additional file is generated (named IBMFileNetP8.opt), which is normally empty.