IBM Content Manager OnDemand and FileNet-2

Name window
In this window (Figure 3-21), specify the names of the application group, application, and
folder. After you enter the names, Content Manager OnDemand queries the library server to
ensure that the names are valid and unique.
Figure 3-21 Specifying names
Wizard complete window

In this window (Figure 3-22 on page 66), you confirm the selections that you made for the
report. Click Display to view a summary of the application group, application, and folder
definitions. From the summary window, choose the Print icon from the toolbar to print a copy
of the definitions.
When you are satisfied with the selections that you made for the report, click Finish to
complete the report definition. Content Manager OnDemand adds the application group,
application, and folder to the library server, closes the report wizard, and returns to the
administrator window.
Chapter 3. Administration 65
Figure 3-22 Completion window
3.2 User and group administration

When you design a Content Manager OnDemand system, you must determine the best way
to implement the many authority structures that are available for users and administrators of
your system. The span of control for the administration of the system must be considered with
the level of user access to the data that is stored in the system. How many different
administrators are required? Will all administrators have system administrator authority or will
different administrators have different levels of authority? What is the most effective way to
restrict a user’s access to only the data that is necessary to do that user’s job?
The answers to these questions depend on the size of the system, the degree of
centralization to be exercised over system administration, and the nature of the data and the
business needs of the users.
Centralized or decentralized
In a system design that exercises centralized control, one or a few administrators are granted
system administrator authority. A centralized system typically is used when the number of
reports and users to be added to the system is small. Centralized administration is also
appropriate where resources are limited and only one person might have the skills and
knowledge to perform the system administration tasks, or where one user group performs all
of the administration tasks.
In a system design with decentralized control, different users are granted different levels of
administrative authority. For example, you might have users that have the authority to create
users and groups. Other users might have the authority to create application groups and
folders, and others might be given full system administration authority.
66 IBM Content Manager OnDemand Guide

The skill level of the users might be a determining factor in the degree of authority that is
granted. It takes a more skilled user to define indexes and report parameters than to set up
users and groups. A decentralized system is typically used when data from different sources
is stored on the same Content Manager OnDemand system but must be maintained
independently of other data. Decentralization also makes sense when report loading and
processing needs are limited to a specific group of users for security purposes or when
administrators that add users and groups must be prevented from accessing report data.
The decision about whether to use a centralized or a decentralized administration model is

best made before any data is set up in the system. Even though the type of administration that
is chosen can be changed later, the amount of work that is involved in that change is greater
than the amount of work that is necessary to study the requirements of the system and
implement the appropriate administration policies from the beginning.
In this section, we describe different types of users, followed by a description of a

decentralized administrative plan. We also introduce a new administrative tool, Content
Manager OnDemand XML Batch Administration, which is a command-line program that is run
on the Content Manager OnDemand server.
3.2.1 User types, authorities, and functions

Four types of users are available in a Content Manager OnDemand system. Each type has a
different level of access, authority, and responsibility in the system:
User: Logs in and queries the system to retrieve documents and reports for viewing.
User administrator: Adds users or other user administrators to the system.
Report administrator: Defines the application groups, applications, folders, and cabinets to
be part of the system. The report administrator is responsible for understanding the report
and document data and for defining the indexes to be extracted from the data and stored.
A report administrator is also responsible for designing the user interface to the reports
through the folder definition process and for controlling access authority to the reports that
the report administrator designs, indexes, and loads.
System administrator: Has the highest level of authority in a Content Manager OnDemand
system. The system administrator has authority for all system functions and can grant
other users the authority to perform various tasks. The system administrator is the only
level of authority that can create storage sets and define system printers.
When the administrative tasks and levels of authorities are understood, you must decide the
span of control in the system. Is it better to have one user control all access and functions in
the Content Manager OnDemand system, or is it better to spread the administrative tasks
among several users to smooth the workload based on system requirements? The answer to
this question depends on whether your environment uses centralized or decentralized
administrative control.
A centralized administrative plan is best suited for a Content Manager OnDemand system
with a few users and relatively few reports to define. In the next section, we focus on the
decentralized system and describe the different aspects of a decentralized administrative
plan.
3.2.2 System administration
Content Manager OnDemand can centralize or decentralize the administration of the system.
A centralized environment means that one type of user, a system administrator, controls the
creation and access to all of the objects that are defined on the system. A decentralized
environment means that the tasks of the system administrator are divided and assigned to
other users. The responsibilities of the other users might vary from user administration, group
administration, application group administration, folder administration, or any combination of
the administrative tasks.
You need to decide whether to centralize or decentralize the administration of the system
before objects are added to the system. Although the decision is reversible, the amount of
work that is required to change from one type of administration to the other can be significant
if many users, groups, folders, and application groups are already defined to the Content
Manager OnDemand system.
Many ways exist to decentralize the administration of the system because of the various user
types and the additional authority levels that can be specified for users. Two specific models
are described in this section: the object type model and the object owner model.
Object type model

In the object type model, which is shown in Figure 3-23, all of the objects on the system are
logically grouped into administrative domains according to the type of the object. The
administrator of a domain maintains all of the objects within the domain. For example, an
application group, folder, or cabinet administrator maintains all of the application, application
group, folder, and cabinet objects on the system.
System Administrator
Application Group/Folder/Cabinet Administrator
Application
Applications Folders Cabinets
Groups
User Administrator with Create Groups Authority
Users Groups
Storage Sets System Printers
Figure 3-23 Decentralized system administration - object type model
In this model, the system administrator defines two new users. One user is responsible for
administering applications, application groups, and folders, and this user is defined as an
application group, folder, and cabinet administrator. The second user is responsible for
administering users and groups, and this user is defined as a user administrator with the
Create Groups authority.
Table 3-1 on page 69 shows the administrative users and the tasks that are assigned to the
users.

Table 3-1 Administrator roles in object type model
Administrator type Administrative tasks
System administrator Creates report administrators.

Creates user administrators with Create Groups authority.
Creates and maintains storage sets.
Creates and maintains system printers.
Application group, folder, and Creates and maintains application groups.

cabinet administrator Creates and maintains applications.
Creates and maintains folders.
Creates and maintains cabinets.
User administrator with Create Creates and maintains users.

Groups authority Creates and maintains groups.
When they are maintaining application groups and folders, the application group, folder, and
cabinet administrator must give other users access to the application groups, folders, and
cabinets. The recommended and simplest way to perform this task is to give access to a
group, rather than to individual users. No additional work is required by the application group,
folder, and cabinet administrator when another user needs access to the application group,
folder, or cabinet. When a new user is added to the group, the user automatically gets access
to the application group, folder, and cabinet. Adding the user to the group is the responsibility
of the user administrator because the user administrator owns all of the groups in this model.
Another reason for giving groups rather than individual users access to application groups
and folders is that the application group, folder, and cabinet administrator does not have
access to the users and groups in this model. Because the application group, folder, and
cabinet administrator must first be granted access to any users or groups that require access
to application groups, folders, or cabinets, it is simpler and less time-consuming to give
access to a few groups rather than hundreds or even thousands of users. The application
group, folder, and cabinet administrator is given access to a group by adding the application
group, folder, and cabinet administrator to the group. This task is performed by the user
administrator with the Create Groups authority. As a group member, the application group,
folder, and cabinet administrator can see the group in the list and can grant group access to
any application groups and folders on the system.
To give an application group, folder, and cabinet administrator access to a user, the user
administrator with the Create Groups authority must update each user and give the
application group, folder, and cabinet administrator access to the user. After access is
granted, the application group, folder, and cabinet administrator can see the user in the list
and can grant the user access to any application groups, folders, and cabinets on the system.
Again, this approach is not recommended because this task must be repeated each time that
a user is added to the system.
Object owner model

In the object owner model, which is shown in Figure 3-24 on page 70, the objects on the
system are logically grouped into administrative domains according to the creator or owner of
the object. An administrator maintains only the objects that they create. For example, a user
with Create Application Groups and Create Folders authority can maintain only the
applications, application groups, and folders that they created.
System Administrator
Department A
User with Create Application Groups, Create Folders, and

Create Cabinets authority
Application
Groups
Users Groups
Department B
User with Create Application Groups, Create Folders, and

Create Cabinets authority
Application
Groups
Users Groups
Storage Sets System Printers
Figure 3-24 Decentralized system administration - object owner model
The object owner model can be used to separate the objects on the system into logical parts,
such as a department, company, or another entity. Each part is independent of the other part
and each part must be maintained separately. Each part typically requires two administrative
users. One user is responsible for creating and maintaining users and groups. The other user
is responsible for creating and maintaining applications, application groups, and folders.
However, you can also define one user with the authority to create and maintain users,
groups, applications, application groups, and folders. In effect, the one user is the system
administrator for a logical part of the system.
In the object owner model, the system administrator defines two users for each logical part of
the system. One user is responsible for maintaining the users and groups for a logical part of
the system. The other user is responsible for maintaining the applications, application groups,
folders, and cabinets for a logical part of the system. With the object owner model, you store
data from several sources on one Content Manager OnDemand system and let only one set
of users access each set of data. Table 3-2 on page 71 shows the administrative users and
the tasks that are assigned to the users.

Table 3-2 Administrator roles in the object owner model
Administrator type Administrative tasks
System administrator Creates a report administrator with Create Application Groups and Create
Folders authority.
Creates a user administrator with Create Groups authority.
Creates and maintains storage sets.
Creates and maintains system printers.
Report administrator Creates and maintains application groups.

Creates and maintains applications.
Creates and maintains folders.
Creates and maintains cabinets.
User administrator Creates and maintains users.

Creates and maintains groups.
To illustrate how the object owner model can be used, assume that a company installs a
Content Manager OnDemand system to provide data archival and retrieval services for other
organizations. The company provides the hardware and software that are required to
administer the system and archive and retrieve the data. An administrator from each
organization defines application groups and folders for their data. Another administrator
defines the users that can access the data. The system must be able to limit access to an
organization’s application groups and folders. Only users that are defined by an organization
must have access to the application groups and folders that are owned by the organization.
The system must also be able to limit access to the data. Only users that are defined by an
organization must have access to the data that is owned by the organization.
Summary
Choosing the correct administration model is an important decision in the design of a Content
Manager OnDemand system. Table 3-3 contains general guidelines to consider when you
decide on an administration model.
Table 3-3 Administration guidelines

Environment Recommendation
The number of reports and users to add to the Content Centralized system administration
Manager OnDemand system is small (fewer than 100).
Resources are limited and only one person performs Centralized system administration
system administrative tasks.
All of the system administration tasks are performed by one Centralized system administration
group.
Data from several independent sources is maintained on Decentralized system administration

the same Content Manager OnDemand system. The data that uses the object owner model
must be kept independent of other data in the system. Data
must be isolated and access is allowed only for users who
must view the data.
Report processing and loading must be limited to a group of Decentralized system administration
users for security reasons. that uses the object type model
The administrator that adds and maintains users must not Decentralized system administration
have access to the report data. A separate administrator that uses the object type model
performs report administration and loading.
3.3 Content Manager OnDemand XML Batch Administration
In addition to the Administrator Client that runs under Windows, Content Manager OnDemand
provides an administrative program that uses Extensible Markup Language (XML). The XML
Batch Administration program (XML batch program) is run on the Content Manager
OnDemand server and provides the same functionality as the Administrator Client.
The difference between the two programs is that for the Administrator Client, the user must
provide input through the graphical user interface (GUI) as opposed to the XML batch
program, which receives input through the XML interface.
In this section, we describe the following items:

Benefits of using the XML batch program
Using the XML Batch Administration program
Special features of the XML batch program
Tips on using the ARSXML command
Benefits of using the XML batch program

Many benefits are possible when you use the XML batch program:
It provides another way to perform the Content Manager OnDemand system
administrative tasks.
It can process different types of objects, such as updating users in a group and application
group permission at the same time.
The Administrator Client is not needed.
It is useful for replicating the same objects to multiple Content Manager OnDemand
servers, and it can even replicate the object when no network connection exists between
the servers.
It simplifies the automation of system administrative tasks.
For Content Manager OnDemand support purposes, the output XML file can be used to
provide information to the support team for problem determination.
3.3.1 Using the XML Batch Administration program

This section provides a brief explanation of how to use the new XML batch program. For more
information, see IBM Content Manager OnDemand for Multiplatforms - Administration Guide,
SC19-3352.
The Batch Administration program is called arsxml. With this XML batch program, you can
export, add, delete, and update Content Manager OnDemand objects.
To use the program, you must have the following files:

The schema file, ondemand.xsd
An input XML file (for example, exportusers.xml)
A password stash file

In XML, the definition and syntax of the markup language are defined in a schema file. For the
Content Manager OnDemand XML batch program, the schema file is called ondemand.xsd. It
contains the definitions for the Content Manager OnDemand objects: users, groups,
applications, application groups, storage sets, folders, printers, and others. Each Content
Manager OnDemand object definition contains one or more child objects. For example, a user
object has a child object for permissions, and a group object has a child object for users in the
group. The schema file (ondemand.xsd) must not be changed in any way by the user.
The input XML file for the XML batch program is parsed to ensure that it is valid according to
the schema file. Each object within the file is examined to ensure that the attributes are valid
according to the object type. The XML batch program generates XML when Content Manager
OnDemand objects are exported. The XML that is generated can be used as an input for the
subsequent arsxml command.
Example 3-1 shows a sample of the file exportusers.xml from the XML samples directory.
You can change the names of the users to the users that you want to export.
Example 3-1 Sample XML input file for exporting users

<?xml version="1.0" encoding="UTF-8"?>
<onDemand xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../ondemand.xsd">
<user name="SAMPLEUSER0" />

</onDemand>
You can export objects by running arsxml export. The following command exports the users
that are listed in the exportuser.xml file, from the server odserver1, to an output file named
users.xml:
arsxml export -u oduser1 -p /my/stash/pwfile -h odserver1 -i exportusers.xml -o
users.xml -v
You can import objects by running arsxml add. The following command imports the users
from the users.xml file (which is generated from the previous command) to server odserver2:
arsxml add -u oduser2 -p /my/stash/pwfile -h odserver2 -i users.xml -v
You can delete objects by running arsxml delete. The following command deletes the users
from odserver2, based on the users that are listed in the users.xml file:
arsxml delete -u oduser2 -p /my/stash/pwfile -h odserver2 -i users.xml -v
For deletion, you are prompted before each object in the XML is deleted, unless the -x
parameter is used.
You can update objects by running arsxml update. For example, you want to update the
description of the user User1 with a new description and add the authority to create users. In
this case, you construct the XML input file that is shown in Example 3-2.
Example 3-2 Input file to update user - updateUser.xml

<?xml version="1.0" encoding="UTF-8" ?>
xsi:noNamespaceSchemaLocation="ondemand.xsd" >
<user name="User1" description="User1" createUsersAuth="Yes" >

</user>
</onDemand>
The following command updates user User1:

arsxml update -u oduser2 -p /my/stash/pwfile -h odserver2 -i updateUser.xml -v
Certain attributes are not allowed to be updated, such as the data type of an application
group field or folder field. If you specify to ignore and continue, the XML batch program
produces a warning message and the rest of the attributes continue to be updated.
You can validate the input XML file by running arsxml validate. When the validate command
is used, only the lines in the input XML file are checked. No call to the Content Manager
OnDemand server is made. The following command validates the input XML file:
arsxml validate -i sample.xml
Note: When you create an input XML file, not all attributes must be specified for each
object.
3.3.2 Special features of the XML batch program

You can add user or group permissions to an application group or folder by adding a
permission child object to the application group or folder group object.
Dependent objects, such as all users that belong to a group, can be exported together when
you choose to export the group rather than having to add a user object to the XML file for
every user in the group. You export the group by specifying the arsxml command option -r d
on the command line.
In a case when no network connection exists between two servers, the XML batch program
can be used to export Content Manager OnDemand objects to an XML file from one server
and later import to another server.
If an error occurs during the processing of one of the objects in the input XML file, the
remainder of the XML file is not processed unless option -e c is used on the arsxml
command line.
Note: Objects must be specified in the correct order. For example, when you add
application groups and applications in the same XML file, you must first specify all of the
application groups and then specify the applications.

3.3.3 Tips on using the ARSXML command
If you are not familiar with the syntax of the ARSXML command, an easier way to begin is to
perform an export of the object. By doing so, you get a working XML input file that you can
modify to suit your needs. Ensure that the export is successful without any errors; otherwise,
the output XML file might be incomplete.
Adding objects to the Content Manager OnDemand server is straightforward. If you are
performing more advanced operations, such as updating the permission of an existing user
for an application group or folder, and you are not getting the results that you are expecting,
the task attribute might be missing. You must include this attribute when you want to update
an existing object, such as removing a user’s permission from an application group or
updating a user’s permission to an application group. The values for the task attribute are add,
delete, and update.
For example, if you want to remove the permission of the user User1 from an application
group, you must use the following line in the input XML file:
<permission user="User1" task="delete" />
Another example is when you want to update the query restriction of the user User1 for the
application group CreditCardAG. In this case, you must use the following line in the input XML
file, with the task attribute set to update.
<permission user="User1" task="update" queryRes="account='000-000-000'" />
The previous line is incorporated in Example 3-3 for the input file updateag.xml.
Example 3-3 Input file updateag.xml

<?xml version="1.0" encoding="UTF-8"?>
xsi:noNamespaceSchemaLocation="../ondemand.xsd">


<applicationGroupname="CreditCardAG" >
<permission user="User1" task="update" queryRes="account=’000-000-000'" />
</applicationGroup>
</onDemand>
The following command updates the query restriction for user User1:
arsxml update -h odserver -i updateag.xml -v -u User1 -p /my/stash/pwfile
Example 3-4 shows the output from the previous command.
Example 3-4 Successful output of updating the query restriction for user User1
ARS6822I Attempting login for userid 'User1' on server 'hodserver'
Updating applicationGroup, CreditCardAG
Update of applicationGroup, CreditCardAG was successful.
Updating applicationGroup-permission, CreditCardAG-User1
Update of applicationGroup-permission, CreditCardAG-User1 was successful.
Finished processing file updateag.xml.
The operation is successful. If you do not specify task="update" in the input XML file, you
see a message that indicates that the object exists, as shown in bold in Example 3-5. In this
scenario, user User1 is not updated with the new query restriction.
Example 3-5 Output of updating the user without using task=“update”

ARS6822I Attempting login for userid 'User1' on server 'odserver'Updating
applicationGroup, CreditCardAG
Update of applicationGroup, CreditCardAG was successful.
An applicationGroup-permission object named 'CreditCardAG-User1' already exists.
Finished processing file updateag.xml.

4
Chapter 4. Database structure

In this chapter, we describe the IBM Content Manager OnDemand (Content Manager
OnDemand) database structure and relationships between the tables. We list the system
control tables and the important data table structures. We explain the relationship between
the tables when you load data, show how a search is performed on the database tables,
describe the system log, and describe special considerations for DB2 on z/OS.
In this chapter, we cover the following topics:

System control tables
Main data table structures
Relationship between tables when data is loaded
Search sequence
System log
Database creation and relationships on z/OS
© Copyright IBM Corp. 2003, 2015. All rights reserved. 77

4.1 System control tables
Content Manager OnDemand creates and uses two sets of tables: a set of system control
tables and a set of application group data tables. All system control tables are created by the
arsdb command (except for the Archive Storage Manager (ASM) tables that are used by
Content Manager OnDemand for IBM i server). The application group data tables are created
when you load data (reports and documents) into the Content Manager OnDemand system.
Table 4-1 shows the Content Manager OnDemand system control tables with their
descriptions.
Note: For a Multiplatform or z/OS server, the complete table name consists of the owner
name, which can be the database name or the instance name, and the table name. For
example, the application group table ARSAG that belongs to the ODARCH instance has a
complete table name of ODARCH.ARSAG.
For the IBM i server, the complete table name is in the format of library/table, where the
library name is always the same as the instance name. For example, the application group
table ARSAG that belongs to the default QUSROND instance has a complete table name
of QUSROND/ARSAG.
Table 4-1 Content Manager OnDemand system control tables

Table name Purpose Description
ARSAG Application group table One row for each application group
ARSAG2FOL Field mapping table One row for each application group field that is
mapped to a folder field
ARSAGFLD Application group field One row for each field that is defined in an
table application group
ARSAGFLDALIAS Application group field One row for each database (internal) and displayed
alias table (external) value in an application group
ARSAGINDEX Application group One row for each composite index on application
composite index table group fields
ARSAGPERMS Application group One row for every user that is granted specific
permissions table permission to an application group
ARSANN Annotation table One row for each annotation that is added to a
database
ARSAPP Application table One row for each application that is defined to
Content Manager OnDemand
ARSAPPUSR User logical views table One row for each logical view that is defined for a
specific user
ARSCAB Cabinet table One row for each cabinet that is defined to Content
Manager OnDemand
ARSCAB2FOL Cabinet to Folder table One row for every cabinet that is defined for a folder
ARSCABPERMS Cabinet permissions One row for every user that is granted specific
table permissions to a cabinet

ARSCFSODWORK Catalog of work One row for the catalog of work between Content
between Content Manager OnDemand and Content Federation
Manager OnDemand Services for Content Manager OnDemand
and Content Federation
Services for Content
Manager OnDemand
table
ARSFOL Folder table One row for every folder that is defined in Content
Manager OnDemand
ARSFOLFLD Folder field table One row for every folder field that is defined for a
folder
ARSFOLFLDUSR Folder user field table One row for every field that is provided for a user
that is granted specific field information for a folder
ARSFOLDPERMS Folder permission table One row for every user that is granted specific
permissions to a folder
ARSFTIWORK Full text search work One row for every application group for full text
table search
ARSGROUP Group table One row for each group that is defined to Content
Manager OnDemand
ARSHOLD Hold table One row for every hold that is defined in Content
Manager OnDemand
ARSHOLDMAP Catalog of documents to One row for every catalog of documents to hold
hold table
ARSHOLDPERMS Hold permissions table One row for every catalog of hold permissions
ARSHOLDWORK Hold work table One row for every catalog of hold work
ARSLOAD Load table The load_ID table
ARSNAMEQ Named query table One row for each private and public named query
that is defined to Content Manager OnDemand
ARSNODE Node table One row for each storage node that is defined
ARSPRT Printer table One row for each printer that is defined in Content
Manager OnDemand
ARSPRTOPTS Printer options table One row for each printer option
ARSPRTUSR Printer user table One row for each user that has access to a specific
printer
ARSRES Resources table One row for each resource ID
ARSSEG Segment table One row for each segment of application group
data
ARSSET Storage set table One row for each storage set
ARSSYS System parameters One row for the entire system

table
ARSUSER User table One row for each user that is defined to Content
Manager OnDemand
Chapter 4. Database structure 79

ARSUSRGRP Users in group table One row for each user that is assigned to a Content
Manager OnDemand group
ARSUSRGRPID User group ID table Maintains the association of users with user
owners and their authority for groups
Dynamic name Application group data One row for each document that is stored in the
table application group
Important: Do not update the tables by using SQL commands or DB2 system tools, such
as SQL Processor Using File Input (SPUFI) or any other tools. The tables must be updated
only by the Content Manager OnDemand Administrator Client or Content Manager
OnDemand commands.
4.2 Main data table structures

The Content Manager OnDemand data tables can grow rapidly. You must understand the
structure of the data tables and the relationships between them.
Two important tables exist that you must examine here: the segment table (ARSSEG) and the
application group data table (ag_internal_id). The segment table contains one row for each
segment of each application group data table. Table 4-2 shows the first four columns of the
ARSSEG table structure.
Table 4-2 ARSSEG table structure

Column name Description
agid Application group ID
table_name Application group segment table name
start_date Segment start date
stop_date Segment stop date
The ARSSEG table points to the application group data table name (second column of the
table, table_name). The application group data table is created or updated during the arsload
process. The application group data table contains a row for each item that is stored in the
application group.
The name of the application group data table is ag_internal_id, which is the identifier that
Content Manager OnDemand assigns to the application group when the application group is
created with the Administrator Client. The three-digit application group identifier is listed in the
Storage Management window of the Administrator Client, as shown in Figure 4-1 on page 81.
In this case, the application group identifier is WBA, AGID 5185.

Figure 4-1 Application group identifier example
Table 4-3 shows the first five columns of the application group data table structure.
Table 4-3 AG_internal_id table structure

Column Data Size Index Description
name type
field_1 Varies Varies N First user-defined field in the application group.
field_n Varies Varies N Last user-defined field in the application group. You
can have up to 128 index fields that are defined in
Content Manager OnDemand.
doc-name varchar 11 Y Document name (object name).
doc_off integer 4 N Document that is offset in the object.
doc_len integer 4 N Document length.
The application group data table is indexed on one or more of the user-defined fields, from
field_1 to field_n.
Four major factors influence the amount of storage that is needed for the Content Manager
OnDemand database:
The number of index and filter fields
The size of the index and filter fields
The number of indexed items per month
The number of months (years) Content Manager OnDemand keeps the indexes in the
database

Three more tables might grow rapidly during the lifetime of a Content Manager OnDemand
system:
The annotation table (ARSANN) grows in proportion to the volume of the annotations that
are added to the documents. The system creates one row for every annotation. Therefore,
every yellow sticker and every graphical annotation add one row to this table.
The resource table (ARSRES) grows in proportion to the volume of AFP data that is
archived and the resources’ (such as formdef, page segments, and overlays) frequency of
change.
The load table (ARSLOAD) grows in proportion to the number of arsload jobs/tasks that
are run. The Content Manager OnDemand system creates one row for each load job/task
that is run. The load table (see Table 4-4) can grow to a multimillion row table during the
lifetime of a Content Manager OnDemand system.
Table 4-4 shows the first four columns for the ARSLOAD table structure.
Table 4-4 ARSLOAD table structure

Column Data type Size Index Description
name
agid integer 4 Y Application group identifier
pri_nid smallint 2 N Primary storage node identifier
sec_nid smallint 2 N Secondary storage node identifier
name varchar 11 Y Name of the load
4.3 Relationship between tables when data is loaded

In this section, we present an example that shows the relationships between the Content
Manager OnDemand tables when you are loading data to a Content Manager OnDemand
system. This example is based on a check application that has four index fields that are
defined as customer_name, account_nbr, check_nbr, and balance. A one-to-one relationship
exists between the application group and the application.
After the application group and the application are defined, the application group gets an
application group identifier, agid, in the ARSAG table and an internal application group
identifier, agid_name. Figure 4-2 on page 83 shows the data that is created in the ARSAG
table; the agid is 5018, and the agid_name is HAA.

ARSAG (application group table)
name (checks)
agid..... (5018)
agid_name (HAA)
...
ARSSEG (segment table)

agid table_name …
5018 HAA1
5018 HAA2
HAA1 (application group data table)

customer_name account_nbr check_nbr balance doc_name doc_offset doc_length
John Smith 123456789 76543 120.78 2FAAA 0 21945
John Doe 234567890 98765 987.98 2FAAA 21945 28063
Jane Doe 345678901 87654 380.98 2FAAA 50008 28595
......... 10 Million row s
HAA2 (application group data table)

customer_name account_nbr check_nbr balance doc_name doc_offset doc_length
Jane Brown 456784949 87643 245.78 4FAAA 0 21945
John Brown 574630988 34512 876.65 4FAAA 21945 28063
Jane Smith 875632091 85094 1380.98 4FAAA 50008 28595
......... 326,098 rows
Figure 4-2 Relationship between system tables and data tables
This application group creates an application group data table every 10 million rows (based
on the seg_rows value in the ARSAG table, which is not shown in Figure 4-2). During the data
loading process, Content Manager OnDemand uses the agid and the agid_name to add a
row into the segment table (ARSSEG) for every 10 million rows that are created in the
application group data table. When the first data load occurs into the HAA application group,
the index values for the stored documents are inserted into table HAA1. A row exists for each
document that is loaded. When table HAA1 reaches its max_rows value (in this case 10
million rows), table HAA1 is closed and table HAA2 is opened.
The important pointer in the ARSSEG table is the name of the application group data table,
table_name, where the index values (in this case, the four defined index values) are stored.
The table_name consists of the agid_name from the ARSAG table, plus a counter.
Figure 4-2 shows the two rows that are created in the ARSSEG table: one row with the
table_name HAA1 and another row with the table_name HAA2. Both HAA1 and HAA2 are the
actual names of the application group data tables that are created.
The application group data table contains the doc_name, which is the actual container
(storage object) for the individual document. The offset and the document length are also kept
in this table. Figure 4-2 shows that the first row has an offset of 0, and the second row has an
offset of the document length of the first row.
Figure 4-2 shows the relationship between the tables.
The architecture of relating one application group to one or more application group data
tables allows Content Manager OnDemand an unlimited growth of index space. The
maximum table size is a limitation of the database subsystem and must be configured for
optimal performance.

Because this architecture enables a system to create tables when the maximum table size is
reached, no logical limitation exists to the system; rather, the limitation is on the physical
resources, such as processing power, disk space, object servers, and storage hardware.
4.4 Search sequence

To better understand the relationship between the various Content Manager OnDemand
tables, we describe a search sequence within a Content Manager OnDemand system in this
section. A search sequence scans through multiple Content Manager OnDemand tables. We
describe the logical flow that the system goes through during a Content Manager OnDemand
search.
By using the Content Manager OnDemand standard Windows client, you can open a search
criteria window (see Figure 4-3). In our example, four index fields exist: Name, Account,
Statement Date, and Balance. The example shows a search for a specific date and balance
amount.
Figure 4-3 Content Manager OnDemand Client search criteria window
After you enter these values, Content Manager OnDemand uses the date information and
searches the segment table ARSEG to find the application group data table that contains that
date. Content Manager OnDemand then searches the identified table_name (in our example
HAA1) for the index values (1994-03-07 and 104.18) and finds the matching Statement_date
and the Balance and returns these values to the client in a search result list.
Any individual document from within this result list can then be retrieved for display on the
client. Content Manager OnDemand locates the document in the archive by using the object
name, document offset, and length. In the background, the document data is automatically
decompressed before it is displayed.
Figure 4-4 on page 85 shows the details of this search sequence from a folder.

folder table Name Description FID
ARSFOL Redbk Credit Credit Card Statement... 5022
folder to
FID AGID
application Identify application group(s) in folder
5022 5020
group
ARSAG2FOL
application Name Description AGID AGID_Name Use application group information to

group table Rbk-Credit Statements 5020 HAA Search ARSSEG table
ARSAG
segment AGID Table_Name Start_date* Stop_Date* Locate application group data table that
table contains the specified date
5020 HAA1 3.05.1994 12.31.1995
ARSSEG * Dates are not shown in real format
5020 HAA2 1.01.1996 6.30.1997
application Index1 Index2 Index3 Index4 Create a hit

Name Acount Statement_date Balance Retrieval_info list that
group data contains
BIKE SHOP A 000-000-123 03.07.1994 697.08 2FAAA
table BIKE SHOP B 000-000-234 03.07.1994 2258.79 2FAAA documents
SPORTS SHOP C 000-000-345 03.07.1994 1892.28 2FAAA that match
HAA1 SPORTS SHOP D 000-000-456 03.07.1994 1868.94 2FAAA the search
SPORTS SHOP E 000-000-567 03.07.1994 104.18 2FAAA criteria
Figure 4-4 Search sequence from a folder
4.5 System log

The system log is used to track all activities in the Content Manager OnDemand Instance.
Examples of these activities include logon and document retrieval. The system log is created
as an application group. It is created by using the ARSSYSCR program. The application group
identification name is SL and a 4-byte agid is added. You will see SLXX in the ARSEG table,
depending on how large your system log is growing. The creation of a new system log table is
based on the number of rows on the Storage Management setting. The default is 10 million
rows. This configuration can be modified.
4.6 Database creation and relationships on z/OS

The database creation, allocation of space for tables, and table space of the Content
Manager OnDemand product are different in the z/OS environment. The database
administrator (DBA) is responsible for the allocation, creation, maintenance, backup, and
recovery of the database subsystem.

4.6.1 System tables for Content Manager OnDemand z/OS
For the Content Manager OnDemand z/OS DB2 database environment, standard database
backup and recovery procedures can be used for the databases, table spaces, and tables that
are created by Content Manager OnDemand. To minimize the effort of creating and
monitoring the Content Manager OnDemand data tables, several automated table creation
and space allocation procedures are part of the product.
All system tables are created by the arsdb program. Each table is created in its own table
space. During the installation, the table space is created by member ARSTSPAC in dataset
V9R5M0.SARSINST. The size of each table space is specified in dataset
V9R5M0.SARSINST. Before you run ARSTSPAC to create the Content Manager OnDemand
table spaces, you must create the storage group and the database. The CREATE for the
storage group and database is in member ARSDB2 in dataset V9R5M0.SARSINST. The
owner of the database (the submitter of the job or the user ID that is set by the “Set current
SQLID =‘username’) must match the entry SRVR_INSTANCE_OWNER in the ARS.INI file.
The arsdb program provides an interface between the database manager and Content
Manager OnDemand. Several parameters are used in the creation and dropping of tables.
For more information about arsdb, see the IBM Content Manager OnDemand for z/OS -
Configuration Guide, SC19-3363.
The arsdb program is in the UNIX System Services file system /usr/lpp/ars/V9R5M0/bin.
When you create the Content Manager OnDemand tables or indexes, the arsdb command
can build the tables and indexes in the default table space or in table spaces that you create
by using the ARSTSPAC member.
When you run the arsdb command, Content Manager OnDemand validates the existence of
the table space. If the table space does not exist, the arsdb command creates the Content
Manager OnDemand system tables in the default table space. After you create the Content
Manager OnDemand table spaces, if changes are required, the best way to change the table
space is by running the ALTER TABLESPACE command.
4.6.2 Data tables for Content Manager OnDemand z/OS

The data tables in Content Manager OnDemand are created under the control of DB2 on
z/OS. Like the system tables, the data tables in Content Manager OnDemand are created
dynamically during the arsload process. It is important to understand how Content Manager
OnDemand on z/OS allocates space for these tables because they can grow large.
During the creation of an application group, a parameter limits the maximum rows for a data
table. If this limit is reached, Content Manager OnDemand creates another data table during
the arsload process. By using the Administrative Client, you can set the maximum row value
for an application group data table. This value is on the Advanced section of the General tab
in the application group configuration. The field is called Maximum Rows.
The space allocation is performed automatically. No further action needs to be performed by

the DBA except to set up the backup of the newly created tables and plan for the new
resources that are needed for the next couple of months.
For more information about space requirements, see the IBM Content Manager OnDemand
for z/OS - Introduction and Planning Guide, SC19-3651.

Content Manager OnDemand for z/OS allocates its table space during the creation of a new
table based on the following space allocation parameters:
DBSIZE/two for primary allocation
Primary allocation/four for the secondary allocation
The allocation of the database is in kilobytes. The allocation values depend on the maximum
row limit that is set when you create the application group. The DBSIZE depends on the
number of index fields that are defined in the application.
DBSIZE is calculated in the following way:
Maximum number of rows * Default Table Factor / records per page
The Default Table Factor is set to “1,2” by the program. The records per page value is a DB2
parameter. For more information about records per page, see Chapter 8, “Estimating Disk
Storage”, in the DB2 Version 10 for z/OS Administration Guide, SC19-2968.
Note: Based on this calculation, when you define the application group, ensure that you
select the appropriate number for Max_Rows:
If you expect the number of documents and indexes that are stored to be low, reduce
the default value of 10 million rows.
If you expect the number of documents and indexes that are stored to be high, increase
the default of 10 million rows.
If you leave the 10-million-row default unchanged, Content Manager OnDemand
allocates 6 million rows as the primary allocation.

5
Chapter 5. Storage management

In this chapter, we explore the storage management options that are available to different IBM
Content Manager OnDemand (Content Manager OnDemand) platforms. Content Manager
OnDemand can manage the usage of local disk-based storage or cache. Additionally, it
supports the usage of various Archive Storage Managers (ASMs) that support external
storage devices. These devices are used to manage long-term copies of data but with the
development of new disk-based archive devices, different options are now available to users
of Content Manager OnDemand.

Content Manager OnDemand cache storage
IBM Tivoli Storage Manager for Multiplatforms
Object access method for z/OS
Archive Storage Manager for IBM i

5.1 Content Manager OnDemand cache storage
Content Manager OnDemand has a built-in cache storage management that is used to store
documents on locally mounted disk subsystems. These subsystems can be network-attached
storage (NAS), storage area networks (SAN), or any type of locally addressable disk that is
available to the supported operating system. The cache storage manager uses a list of
directories or file systems that are available to determine where space is available for storing
and maintaining documents.
Each Content Manager OnDemand object server in the system has a defined set of cache
storage devices on which you can maintain the report data for a period to provide the fastest
access times for system users.
Certain implementations of Content Manager OnDemand use an all cache system to

maintain data for its full retention. Other implementations store to both cache and archive
storage. Other implementations store only to the archive.
You can configure Content Manager OnDemand so that at load time one of the following
methods of data storage occurs:
Data is stored in cache and later is automatically migrated from the cache subsystem to
an archive system.
Data is stored to both local cache and archive storage.
Data is stored directly to archive storage.
These options are described in the following sections.
5.2 IBM Tivoli Storage Manager for Multiplatforms

Content Manager OnDemand for Multiplatforms integrates with Tivoli Storage Manager and a
license for this usage is included with Content Manager OnDemand. Within Tivoli Storage
Manager, documents can be archived on various media, such as disk, optical, tape, and
content-addressable storage (CAS) devices. These archive storage devices must be defined
to the Tivoli Storage Manager system. Content Manager OnDemand uses the archive
application programming interface (API) that is provided by Tivoli Storage Manager to store
and retrieve documents.
To store application group data to the Tivoli Storage Manager ASM, the application group
must be configured within Content Manager OnDemand to a defined storage set. This
storage set contains a storage node that is defined within Tivoli Storage Manager and points
to a specific storage area or media.
With the application group definition, you can specify whether and when the data is migrated
to archive storage. For example, you can specify that the data will be migrated to archive
storage when the document is originally loaded into the system, or that the data migration
occurs the next time that the migration maintenance process is run, or that the data migration
occurs after a certain number of days pass from the date that the data was loaded; or never.

In this section, we describe the following two scenarios:
The steps that you follow to set up and configure Tivoli Storage Manager as the archive
manager for a Content Manager OnDemand for Multiplatforms system.
The configuration of IBM System Storage® Archive Manager to store Content Manager
OnDemand data. It provides data retention policies that help meet regulatory
requirements and uses storage devices, such as EMC Centera or NetApp SnapLock. You
must verify that a particular device is supported on the platform of choice.
Starting with Tivoli Storage Manager V6.1, Tivoli Storage Manager uses DB2 for its database
instead of the built-in B-tree database. Typically, the Tivoli Storage Manager Server is
installed on a separate system. However, for smaller implementations, the Tivoli Storage
Manager server can coexist on the same system as your Content Manager OnDemand object
server.
5.2.1 Tivoli Storage Manager overview

Before we describe the configuration process, we describe a few of the components that
make up a Tivoli Storage Manager system. For a complete description of Tivoli Storage
Manager, see the appropriate Tivoli Storage Manager documentation. For example, on
Microsoft Windows, see the Tivoli Storage Manager for Windows Administrator’s Guide
V6.3.4, SC23-9773.
Figure 5-1 represents a typical Tivoli Storage Manager system. A short description of each
component follows.
Poli cy D omai n Op ti cal Storag e
Pol icy Set Sto rage

C lie nt Node
Da ta Vol ume
Mana geme nt
Cla ss
Archi ve
Co py Gro up Storag e Me dia
Vo lume
De vice
Cla ss
Li brary
Devi ce,
Dr ives
D rive
Figure 5-1 Tivoli Storage Manager storage objects
Chapter 5. Storage management 91

Client node
In Figure 5-1, the client node represents a Content Manager OnDemand object server with an
installed Tivoli Storage Manager archive API. The client node is assigned to a policy domain.
Each Content Manager OnDemand system that stores reports in Tivoli Storage Manager
needs at least one defined client node.
Storage policy
A storage policy consists of the following items:
Policy domain: Contains the policy set, management class, and archive copy group that is
used by the client node
Policy set: Contains management classes, which contain the archive copy groups
Management class: Determines where data is stored and how it is managed
Archive copy group: Used to copy data to Tivoli Storage Manager for long-term storage
Storage devices and media

Storage devices and media consist of the following items:
Library: One or more drives with similar media mounting requirements. Only defined when
you have an external library.
Drive: A drive mechanism, which is defined by Tivoli Storage Manager, that is in an optical
or tape library or stand-alone device.
Device class: Specifies the device type and how the device manages media.
Storage pools and volumes: A named collection of storage volumes of the same media
type that is associated with a device class.
Tivoli Storage Manager installation

For help with installing and configuring IBM Tivoli Storage Manager Version 7.1.1 for
Windows, see the installation guide at the following website:
ftp://public.dhe.ibm.com/software/products/TSM/current/b_srv_install_guide_windows
.pdf
By using this guide, complete the steps that are listed to install the Tivoli Storage Manager
server, Tivoli Storage Manager licenses, Tivoli Storage Manager backup archive client, and
Tivoli Storage Manager Device driver.
When these installations are complete and the Tivoli Storage Manager Server is running, go
to 5.2.2, “Configuring Content Manager OnDemand for Tivoli Storage Manager archive
management” on page 92.
Additional optional components are covered in the guide, such as a Tivoli Storage Manager
Administration Center, that can assist you in supporting your Tivoli Storage Manager Server.
5.2.2 Configuring Content Manager OnDemand for Tivoli Storage Manager

archive management
To enable Content Manager OnDemand to use Tivoli Storage Manager as the archive
manager for the system, you must set Content Manager OnDemand options to allow the
system to recognize that Tivoli Storage Manager is configured for archive storage.

In a Content Manager OnDemand for Windows system, the Content Manager OnDemand
configurator is used to set this parameter. In a Content Manager OnDemand for UNIX or
Linux system, the ars.cfg configuration file is updated to specify that Tivoli Storage Manager
is used.
In this section, we describe how you can configure Content Manager OnDemand to use Tivoli
Storage Manager on both Windows and UNIX or Linux systems.
Content Manager OnDemand for Windows Tivoli Storage Manager

configuration
If you are configuring a Content Manager OnDemand for Windows system to use Tivoli
Storage Manager for archive storage, the Content Manager OnDemand configurator is used.
Either during the creation of the instance or after the instance is created, you can select Tivoli
Storage Manager (TSM) as the storage option (Figure 5-2). Click TSM, click TSM Options,
and then enter the path to the Tivoli Storage Manager program files and the path to the Tivoli
Storage Manager options file.
Figure 5-2 Windows configurator
Content Manager OnDemand for UNIX or Linux Tivoli Storage Manager

configuration
If you are configuring a Content Manager OnDemand for UNIX system to use Tivoli Storage
Manager for archive storage, you must ensure that the ars.cfg file (Figure 5-3 on page 94) is
updated to reflect that Tivoli Storage Manager is used as the storage manager.

The file must also include valid paths for the Tivoli Storage Manager options files and all of the
Tivoli Storage Manager components that are used. The parameters in the file are used to
reference the first Tivoli Storage Manager Server. A single object server can reference
multiple Tivoli Storage Manager servers.
######################################################
# Storage Manager Parameters (Library/Object Server) #
######################################################
#
# Storage Manager for OnDemand to use
#
ARS_STORAGE_MANAGER=TSM
#######################################
# TSM Parameters (Object Server Only) #
#######################################
DSMSERV_DIR=/usr/tivoli/tsm/server/bin
DSMSERV_CONFIG=/usr/tivoli/tsm/server/bin/dsmserv.opt
DSM_DIR=/usr/tivoli/tsm/client/api/bin64
DSM_CONFIG=/usr/tivoli/tsm/client/api/bin64/dsm.opt
DSM_LOG=/tmp
DSMG_DIR=/usr/tivoli/tsm/client/api/bin64
DSMG_CONFIG=/usr/tivoli/tsm/client/api/bin64/dsm.opt
DSMG_LOG=/tmp
DSMI_DIR=/usr/tivoli/tsm/client/api/bin64
DSMI_CONFIG=/usr/tivoli/tsm/client/api/bin64/dsm.opt
DSMI_LOG=/tmp
Figure 5-3 ARS.CFG file for Tivoli Storage Manager configuration
Note: For the Tivoli Storage Manager client that is used by Content Manager OnDemand,
set COMPRESSION NO in the Tivoli Storage Manager client option file (dsm.opt for Windows or
dsm.sys for UNIX). Content Manager OnDemand objects are compressed before they are
sent to Tivoli Storage Manager for archival; therefore, compression by Tivoli Storage
Manager is not required.

5.2.3 Content Manager OnDemand storage management
The storage management criteria that you specify for the Content Manager OnDemand
library server determines where and when Content Manager OnDemand stores reports and
how those reports are maintained.
Figure 5-4 illustrates Content Manager OnDemand storage object relationships. When a
report is loaded into Content Manager OnDemand, it is assigned to an application group. The
application group is associated with a storage set. The storage set contains one or more
storage nodes that can be used by several application groups that have the same archive
storage requirements.
Application Group
Stor age Set
Storage node
Ca che Storage
A rchive Storage
Figure 5-4 Content Manager OnDemand storage objects
For example, a storage set can be used to maintain data from different application groups that
must retain documents for the same length of time and require the data to be kept on the
same type of media. Different storage sets can be created to handle different data retention
requirements. One storage set can be set up to maintain data on cache-only magnetic
storage. Another storage set can be set up to point to a Tivoli Storage Manager client node
that stores a copy of the report in archive storage.
If Tivoli Storage Manager is used as the ASM, the same storage management criteria must
be specified for both Content Manager OnDemand and Tivoli Storage Manager. That is, the
Life of Data and Indexes in Content Manager OnDemand and the retention period in Tivoli
Storage Manager must have the same value.

Note: In Content Manager OnDemand, the date that is used to determine the Life of Data
and Indexes is the date field index value, which is taken from the report that is being loaded
and defined as the segment date.
For Tivoli Storage Manager:

If RETINIT=CREATION, the date that is used for the retention period in Tivoli Storage
Manager is the date that the report is first migrated to Tivoli Storage Manager.
If you are using RETINIT=EVENT, the RETMIN parameter specifies the minimum number of
days that Tivoli Storage Manager stores an object.
The expiration type determines how the data is expired:

If the expiration type value for the application group is load, a command is issued from
Content Manager OnDemand to Tivoli Storage Manager to delete data when the data is
expired from Content Manager OnDemand.
If the expiration type is segment or document, a delete command is not issued from
Content Manager OnDemand to Tivoli Storage Manager when Content Manager
OnDemand expires the data and the data remains in Tivoli Storage Manager until the
Tivoli Storage Manager retention period expires. This data is not accessible from
Content Manager OnDemand because the indexes are expired in Content Manager
OnDemand.
If Tivoli Storage Manager and Content Manager OnDemand are configured to use
event-based archiving, Content Manager OnDemand sends a delete command to Tivoli
Storage Manager when data is due to be expired. Tivoli Storage Manager then checks to
see whether the data is allowed to be deleted based on its RETMIN parameter. The benefit
of this approach is that Content Manager OnDemand is in total control of when deletions
can take place instead of Tivoli Storage Manager deleting data independently.
5.2.4 Storage set definition

A storage set can contain one or more primary storage nodes. A primary storage node is
used to manage reports and resources that are stored in an application group. A storage node
is associated with a specific Content Manager OnDemand object server. When Tivoli Storage
Manager is used for archive storage, each storage node that is associated with storage that is
managed by Tivoli Storage Manager must be registered as a client node in a Tivoli Storage
Manager policy domain. The Tivoli Storage Manager policy domain properties determine the
type of storage devices that are used to maintain the archived data and the length of time that
the data is maintained.
Content Manager OnDemand systems can be set up to run as cache-only hard disk drive
systems with no migration of the data or indexes, or with an archive system that uses Tivoli
Storage Manager to maintain and manage the archive of Content Manager OnDemand
documents and indexes over a predetermined period.
When Content Manager OnDemand is installed and the system is initialized, a default
cache-only storage set is created. Additional cache storage sets can be defined. Storage sets
that are associated with Tivoli Storage Manager client nodes that are tied to specific
management policies on the Tivoli Storage Manager servers are used for long-term archive
storage.

The Content Manager OnDemand administrator defines and maintains storage sets
(Figure 5-5). The load type is the storage set parameter that we examine.
Figure 5-5 Storage set definition
Load Type parameter

The Load Type parameter determines where Content Manager OnDemand stores data. Two
values are possible (Figure 5-5):
Fixed: Content Manager OnDemand stores data in the primary storage node that has the
load data field selected. When Load Type is set to Fixed, you must select the load data
check box for one primary storage node. Content Manager OnDemand loads data to only
one primary storage node regardless of the number of primary nodes that are defined in
the storage set.
Local: Content Manager OnDemand stores data in a primary storage node on the server
on which the data loading program runs. When the Load Type is Local, the load data
check box must be selected for a primary storage node on each of the object servers that
is identified in the storage set. A storage set can contain one or more primary storage
nodes that are on one or more object servers.
Next, we examine several parameters on the Add a Primary Node window (Figure 5-6 on
page 98).

Figure 5-6 Primary storage node definition
Storage node
The Content Manager OnDemand storage node name can be 1 - 60 characters in length and
can include embedded blanks. The case can be mixed.
Content Manager OnDemand no longer supports adding auxiliary storage nodes when you
create a storage set.
Note: The Content Manager OnDemand storage node name does not tie the storage set
to the Tivoli Storage Manager client node. This name is only a label in the Content
Manager OnDemand system. The storage node name can be the same as the associated
client node name, but they are not required to be the same name.
Logon
If Tivoli Storage Manager is used to maintain archive data, the Logon field is the name of the
Tivoli Storage Manager client node. This field is ignored if you are defining a cache-only
storage node.
Note: The Logon field must be a valid Tivoli Storage Manager client node name. This client
node name is the client node that is defined on the Tivoli Storage Manager system through
the wizard or command line. The password that follows the logon must be the same as the
password that you created for the client node. Content Manager OnDemand uses the Tivoli
Storage Manager application programming interface (API) to connect and log on to the
Tivoli Storage Manager server when data is being migrated to the Tivoli Storage Manager
client node.

Load Data
The Load Data parameter determines the primary storage node into which Content Manager
OnDemand loads data. When the Load Type is Fixed, Load Data must be selected for one
primary storage node. When Load Type is Local, Load Data must be selected for one primary
node for each object server that is associated with the storage set.
Cache Only
The Cache Only parameter determines whether Content Manager OnDemand uses the
archive manager for long-term storage of data.
After you install and configure Tivoli Storage Manager, create a Content Manager OnDemand
storage set, and assign it to a Tivoli Storage Manager client node, you are ready to consider
how an application group uses the cache storage manager. You must also consider how the
ASM stores, maintains, and expires Content Manager OnDemand report data.
Access Method
When you configure Content Manager OnDemand for Multiplatforms Tivoli Storage Manager
support, you can specify access to one or more Tivoli Storage Manager servers from a single
object server. Only one Tivoli Storage Manager server can be set up to load data at a time by
using the Load Data flag. To configure the support for multiple Tivoli Storage Manager
servers, you specify the client configuration file under the Config File Name section.
Content Manager OnDemand Object Servers on z/OS

In the Access Method section (Figure 5-7), choose from OAM (object access method) or
VSAM (Virtual Storage Access Method) for the access method. OAM is the default access
method for the primary storage node. If you choose OAM, specify the collection name. If you
choose VSAM, specify the high-level qualifier (HLQ).
Figure 5-7 Content Manager OnDemand Object Servers on z/OS

Reload Hold Data
You can optionally select the Reload Hold Data check box (Figure 5-8). If it is selected, all
documents on hold are reloaded into the storage node after they reach their expiration date.
Figure 5-8 Reload Hold Data
For each storage set, you can identify only one storage node as the node where the hold data
is reloaded. You can change the Reload Hold Data option when a storage node is updated.
This option grants you control of the type of media that reloaded data is placed on that is
technically eligible for expiration but is on hold. The location where the held data is stored
needs to be managed differently than new data that is being loaded to the system. You do not
want to reload Hold Data to a Storage Set/Pool that is defined for 7-year storage.
5.2.5 Application group storage management

The application group storage management settings (Figure 5-9 on page 101) determine how
long report data and indexes are kept in cache storage before they are expired. You must
decide how soon data is migrated to the archive storage after data is loaded.

Figure 5-9 Application group storage management
Cache Data
The Cache Data setting determines whether the report data is stored in a hard disk drive
cache and, if so, how long it is kept in cache before it is expired. You can also choose whether
to search cache when users retrieve documents for viewing. If you choose not to store reports
in cache, you must select a storage set that supports archive storage.
Note: Data that is retrieved often needs to generally remain in cache until it is no longer
needed by 90% of Content Manager OnDemand users.
Life of Data and Indexes

The Life of Data and Indexes settings determine the length of time that report data, indexes,
and resources are maintained in the Content Manager OnDemand system before they are
deleted from the application group. The report data, indexes, and resources can be
maintained indefinitely if set to never expire, or they might be kept for up to 273 years. After
the maintenance threshold is reached, the arsmaint command can be used to expire the data
from the system.

Expiration Type
The Expiration Type option determines how report data, indexes, and resources are expired.
Three expiration types are available:
Load: With this expiration type, a single input file (a Load) at a time can be deleted from
the application group. The latest date in the input data and the Life of Data and Indexes
determine when Content Manager OnDemand deletes the data. Content Manager
OnDemand signals to the storage manager that the data might be deleted.
Figure 5-10 shows the error message that displays when you use Enhanced Retention
Management and you do not set the expiration type to Load.
Note: Load is the suggested expiration type.
If any application group uses either the Enhanced Retention Management feature or
IBM Enterprise Records, this setting is required. You must also use this type if
event-based processing is used within Tivoli Storage Manager.
Figure 5-10 Expiration type set incorrectly
Segment: With this expiration type, a segment of data at a time is deleted from the
application group. The segment must be closed and the expiration date of every record in
the segment must be reached. Data that is stored in archive storage is deleted by the
storage manager based on the archive expiration date. If a small amount of data is loaded
into the application group, and the Maximum Rows value is high, the segment might be
open for a long period, and the data is not expired for the period.

Document: With this expiration type, a document at a time is deleted from the application
group. Data that is stored in archive storage is deleted by the storage manager based on
the archive expiration date. Storing documents with an expiration type of Document
causes the expiration process to search through every document in the segment to
determine whether the expiration date was reached, which results in long processing
times.
When the arsmaint expiration process is run, data is deleted only from the application group if
the upper threshold for the size of the cache storage is reached. By default, the cache
threshold is 80%. A lower threshold can be forced by the expiration command parameters.
Unless a reason exists to clear cache, leaving data in cache improves retrieval performance.
5.2.6 Advanced application group storage management

By using the advanced storage management settings (Figure 5-11), you can adjust the size of
the load object and determine when report data, indexes, and resources are migrated to
archive storage.
Figure 5-11 Advanced application group storage management
Object Size
The Object Size parameter determines the size of a storage object in kilobytes (KB). Content
Manager OnDemand, by default, segments and compresses stored data into 10 MB storage
objects. The default of 10 MB is the most commonly used object size value.
Important: Be careful when you change the value for Object Size. Setting the value too
small or too large can adversely affect load performance. However, increasing this value
might be necessary if you load large files and run out of Object IDs during the loading
process.
Note: The object size that is defined here must be equal to or larger than the size of the
compressed storage objects that are defined in any application that is assigned to the
application group.

Application Group Identifier and the Application Group ID
The Application Group Identifier and the Application Group ID (AGID) are unique identifiers
that are used by Content Manager OnDemand to identify the application group in system
tables.
Migrate Data from Cache

The Migrate Data from Cache value determines when documents and resources are migrated
to archive storage. A storage set that is associated with a Tivoli Storage Manager client node
must be selected to enable migration to archive storage.
The following values are valid:

No: Data is never migrated from cache. This option is unavailable when a storage set that
is associated with a Tivoli Storage Manager client node is selected for the application
group.
When data is loaded: Data is migrated to archive storage when the data is loaded into the
application group.
Next cache migration: Data is migrated to archive storage the next time that ARSMAINT is
run with the -m option. The -m option indicates that data and resources are copied from
cache to archive storage.
After __ days in cache: This value specifies the number of days that data remains in cache
storage. After the prescribed number of days in cache storage are reached, the data is
copied to archive storage the next time that ARSMAINT is run with the -m option for data
migration.
5.2.7 IBM System Storage Archive Manager

Certain regulations require data to be stored in devices that are read only. In the past,
physical storage devices, such as tapes and optical disks that are Write Once Read Many
(WORM), were used.
WORM disks, such as the NetApp SnapLock or EMC Centera, can be used to store data in
the same manner as WORM tapes or optical platters. IBM System Storage Archive Manager
allows critical data to be retained for a mandated period without the possibility of being
rewritten or erased.
In this section, we describe System Storage Archive Manager and how Content Manager
OnDemand can be configured to use this subsystem to support these WORM disk devices.
Note: Verify support for any particular device on a particular platform through the Tivoli
Storage Manager Device support matrix before you plan your implementation.
For more information about the Tivoli Storage Manager support of WORM disk devices, such
as NetApp SnapLock, or EMC Centera, see the following IBM Knowledge Center documents:
Tivoli Storage Manager for AIX Administrator’s Guide
Tivoli Storage Manager for Windows Administrator’s Guide
You can obtain these documents from the IBM Tivoli Storage Manager Knowledge Center at
the following web address:
http://www.ibm.com/support/knowledgecenter/SSGSG7/welcome?lang=en:

IBM System Storage Archive Manager
The IBM System Storage Archive Manager feature is sold as a separately licensed software
product that is integrated into Tivoli Storage Manager Server software. It requires a
stand-alone Tivoli Storage Manager Extended Edition server to be dedicated for its use. It is
accessible solely through the Tivoli Storage Manager API by various content management or
archive software applications.
For more information about the IBM System Storage Archive Manager, go to the following
website:
http://www.ibm.com/software/products/en/ibmsyststorarchmana
IBM System Storage Archive Manager provides support in the following key areas:
Data retention protection (DRP): Data is not deleted until the retention criteria for the
object is satisfied. This feature affects Content Manager OnDemand on loads, unloads,
application group deletes, and the expiration of data.
Event-based retention policy: Data is retained based on a time interval after the
occurrence of a retention-initiating event. For Content Manager OnDemand, this event is a
call to delete the data. A load, an unload, application group delete, or expiration of data
triggers the retention event.
Deletion hold: Data is not deleted or modified until the deletion hold is released. Content
Manager OnDemand does not take advantage of this feature. Content Manager
OnDemand uses its own built-in deletion hold mechanism that is called Enhanced
Retention Management.
New device support: Support is available for all of the devices that Tivoli Storage Manager
Extended Edition supports.
Content Manager OnDemand operation with the Tivoli Storage Manager

server API
With the new event-based retention policy, the object expiration can now be event-based
instead of creation-based. A new option is available in the archive copygroup definition that is
called RETINIT. It determines the time when the retention time that is specified by the RETVER
attribute is initiated. Two values are possible:
Creation: This value specifies that the retention time that is specified by the RETVER
attribute is initiated at the time that an archive copy is stored on the Tivoli Storage
Manager server.
Event: This value specifies that the retention time that is specified in the RETVER parameter
is initiated at the time that a client application notifies the server of a retention-initiating
event for the archive copy. If you specify RETINIT=EVENT, you cannot also specify
RETVER=NOLIMIT.
We compare the behavior of Tivoli Storage Manager when Content Manager OnDemand data
is deleted with the previously listed two options together with the setting of data protection.

Table 5-1 shows the action by Tivoli Storage Manager when a Content Manager OnDemand
object is deleted, unloaded, or during the deletion of an application group when data
protection is turned OFF.
Table 5-1 Comparison of expiration methods with data protection OFF

Tivoli Content Manager OnDemand action: Content Manager OnDemand
Storage Unload action: Delete application group
Manager
RETINIT
Creation The Delete Object command is issued through The Delete Filespace command is
the Tivoli Storage Manager API. issued.
Objects are deleted during the next Tivoli

Storage Manager expiration. Objects are immediately deleted with
the file space.
Event Content Manager OnDemand issues an event The Delete Filespace command is
trigger command through the Tivoli Storage issued.
Manager API.
The status of the objects that are affected is Objects are immediately deleted with
changed from PENDING to STARTED and is the file space.
expired by Tivoli Storage Manager based on
their retention parameters. If the retention
parameters are set to NOLIMIT, the objects
never expire.
Table 5-2 shows the action by Tivoli Storage Manager when data protection is turned ON.
Table 5-2 Comparison of expiration methods with data protection ON

Tivoli Content Manager OnDemand action: Content Manager OnDemand action:
Storage Unload Delete application group
Manager
RETINIT
Creation Content Manager OnDemand issues no Content Manager OnDemand issues no

commands to Tivoli Storage Manager. commands to Tivoli Storage Manager.
The objects are effectively orphaned by The objects are effectively orphaned by
Content Manager OnDemand and are Content Manager OnDemand and are
expired by Tivoli Storage Manager based expired by Tivoli Storage Manager based on
on their retention parameters. If the their retention parameters. If the retention
retention parameters are set to NOLIMIT, parameters are set to NOLIMIT, the objects
the objects never expire. never expire.
Event Content Manager OnDemand issues an The Delete Filespace command cannot be
event trigger command through the Tivoli used with DRP ON, so the operation is
Storage Manager API. treated the same as though a delete were
indicated and the status of all of the affected
The status of the objects that are objects is changed from PENDING to
affected are changed from PENDING to STARTED. They are expired by Tivoli
STARTED and are expired by Tivoli Storage Manager based on their retention
Storage Manager based on their parameters. This action unfortunately leaves
retention parameters. If the retention the file space entries in Tivoli Storage
parameters are set to NOLIMIT, the Manager. These entries can be manually
objects never expire. deleted after the file space is empty even
with DRP ON.

Content Manager OnDemand version 9 setup recommendations
The following recommendations are applicable to Content Manager OnDemand V9.0 and
later:
Application groups need to be set up to expire by load; then, you can use the Enhanced
Retention Manager document hold feature.
Tivoli Storage Manager archive copy groups need to be defined to be event-based by
setting the RETMIN and RETVER parameters. The RETMIN parameter needs to be set to the
minimum number of days that a document must be retained. For a legal 7-year document,
this setting must be 2557. For others, where you want Content Manager OnDemand to be
100% in control and able to delete documents at anytime, set RETMIN=0. Content Manager
OnDemand then issues a delete based on its Life of Data and Indexes or when an
administrator performs an unload command.
Tivoli Storage Manager Inventory expiration must be run regularly to ensure that expired
data is cleaned up.
5.2.8 The arsmaint command

We referenced the Content Manager OnDemand arsmaint command many times in previous
sections, but we now look closer at this command. The arsmaint program maintains
application group data that is stored in the Content Manager OnDemand database and in
cache storage. It maintains the system by using the storage management values that are
specified for application groups. It is typically run on a regular schedule to migrate documents
from cache storage to archive storage, migrate index data to archive storage, and delete
documents from cache storage and index data from the Content Manager OnDemand
database.
The arsmaint command uses the application group expiration type to determine how to delete
index data from an application group. This command can expire a table of application group
data at a time (segment expiration type), an input file of data at a time (load expiration type),
or individual documents (document expiration type).
Note: When cache data is expired, by default the data is not expired until the cache
storage file system exceeds 80% of capacity. Keeping data in cache as long as possible
improves retrieval and viewing performance. You can force the expiration of cache data
before the cache is 80% full by using the minimum and maximum parameters to override
the percentage full default.
For a detailed explanation of the arsmaint command and its associated parameters, with all
of the other Content Manager OnDemand commands, see IBM Content Manager OnDemand
for Multiplatforms, V9.5, Administration Guide, SC19-3352.

5.3 Object access method for z/OS
In this section, we provide an introduction to object access method (OAM) and show its
relationship with Content Manager OnDemand in a z/OS environment.
For more information about setting up OAM, see the following documentation:
DFSMS Object Access Method Planning, Installation, and Storage Administration Guide
for Object Support, SC35-0426
Chapter 3, “OAM and System Management Subsystem customization”, in Image and
Workflow Library: Content Manager for ImagePlus on OS/390 Implementation and EIP,
SG24-4055
OAM is a hierarchical data management system (disk → optical → tape) that is used for
archive storage.
Note: When you use OAM as the storage manager, Content Manager OnDemand can
retrieve the stored object directly from disk, optical drive, or tape.
OAM uses the OSREQ macro interface and uses DB2 both for its internal (indexing) tables
and for online storage objects. OAM is the DFSMSdfp component that manages a class of
data, which is called objects, in a z/OS environment. Objects are bit strings that are handled
as one large byte string rather than processing them as records, as is done with datasets.
The content of this byte string is not known to OAM. No restrictions exist on the data type of
this object; it can be an image, compressed data, or coded data.
How to handle this data is left up to the application. OAM handles an unlimited number of
objects, which can be stored on magnetic disk, magnetic tape, or optical storage. Objects are
different from datasets, which are handled by existing access methods. The following
characteristics distinguish objects from traditional datasets:
Lack of record orientation: No concept of individual records within an object exists.
Broad range of size: An object might contain less than 1 KB or up to 256 MB of data.
Volume: Objects are much smaller than datasets; however, they can use much more
external storage, depending on the type of application that creates them, such as image
applications.
Access time requirements: Reference patterns for objects change over time, allowing less
critical objects to be placed on lower-cost, slower devices or media.

5.3.1 OAM components and SMS terminology
In this section, we describe the three components of OAM and also OAM terminology.
OAM components
OAM functions are performed by three components:
Object Storage and Retrieval (OSR) component
This component provides an API for OAM. All OAM API functions are requested through
the OSREQ assembler macro. Applications use this interface to store, retrieve, query, and
delete objects, and to change information about objects. OSR stores the objects in the
storage hierarchy and maintains the information about these objects in DB2 databases.
OSR functions that start through the API require the OAM Thread Isolation Support (OTIS)
application for administrative processing.
Library Control System (LCS) component
This component writes and reads objects on tape and optical disk storage. It also
manipulates the volumes on which the objects are stored. The LCS component controls
the usage of optical hardware resources that are attached to the system.
OAM Storage Management Component (OSMC)
This component determines where to store objects in the OAM storage hierarchy. It
manages object movement within the object storage hierarchy and manages expiration
attributes that are based on the installation storage management policy that is defined
through the storage management subsystem (SMS). OSMC also creates the requested
backup copies of the objects and provides object and volume recovery functions.
SMS terminology
To provide a better understanding of OAM, we explain SMS terms in the following sections.
SMS storage class

A storage class is a collection of performance goals and availability and accessibility
requirements that are defined to SMS. It is used to select a device to meet those goals and
requirements.
Usually, three storage classes are set up for OAM where the storage administrator sets the
names of the storage classes based on the naming convention in the enterprise. The three
OAM storage classes to set up are listed:
OAMDASD: Objects are stored in a DB2 table on fast magnetic disk.
OAMTAPE: Objects are stored on magnetic tape, including tape robots.
OAMOPTIC: Objects are stored on a 3995 optical device.
Note: The Content Manager OnDemand cache storage on a hierarchical file system (HFS)
is not part of these SMS constructs.
SMS storage group

An SMS storage group is a collection of storage volumes and attributes that are defined by
the installation. Storage groups, with storage classes, help reduce the requirement for users
to understand the physical characteristics of the storage devices that contain their data.

In an OAM environment, object storage groups allow the storage administrator to define an
object storage hierarchy. The object storage hierarchy classifies storage areas according to
location and, therefore, according to retrieval response time. Each object storage hierarchy
must contain an object directory, containing control information about each object.
Additionally, the hierarchy can have the following items:
DB2 object storage tables on a hard disk drive
Optical volumes that are associated with optical libraries (real or pseudo), and stand-alone
or operator-accessible optical disk drives
Tape volumes that are associated with tape libraries or stand-alone tape drives
SMS management class

Management classes define the space and availability requirements for datasets. Class
attributes control backup, migration, retention of data, and release of unused space. OSMC
uses information from the management classes to determine the automatic management
processes that need to be performed on corresponding OAM objects.
Automated Class Selection routine

Automated Class Selection (ACS) routines are used to assign class and storage group
definitions to datasets and objects. ACS routines are written in the ACS language, which is a
high-level programming language that is similar to the language that is used for the
construction of TSO CLISTs. The ACS translator is used to convert the routines to object form
so that they can be stored in the SMS configuration.
OAM collection
A collection is a group of objects that typically have similar performance, availability, backup,
retention, and class transition characteristics. A collection is used to catalog many objects,
which, if cataloged separately, can require a large catalog. Every object must be assigned to
a collection. Object names within a collection must be unique; however, the same object
name can be used in multiple collections. Each collection belongs to only one object storage
group. Each storage group can contain from one to many collections.
Important: A collection is the only interface that is used by the administrator to determine
how to store objects in OAM. It is used when you create a storage set.
5.3.2 OAM configuration recommendations

This section provides a list of recommendations for you to review and consider when you
configure OAM for Content Manager OnDemand. They are classified in the following
categories:
General
DB2
Devices
Tapes
Maximum Object Size (MOS)
Optical platters
ARS.CFG setting

General
Consider the following general recommendations when you work with OAM for Content
Manager OnDemand:
Define a user catalog exclusively for collection names.
Cache the user catalog in the virtual lookaside facility (VLF).
Migrate objects to optical or tape (OSMC) during non-peak hours.
Spread OAM collections over multiple DB2/disk/channels.
Spread out the application groups to different collection names:
OAM collections → storage groups → DB2 database
Group your applications based on retrieval expectations:
– Collect small, frequently used applications together.
– Isolate your important applications so that the other applications do not get in the way.
DB2
Consider the following list of recommendations that relate to DB2:
Ensure that enough DB2 connections are available to support the OAM requests.
Run the REORG, RUNSTATS, and REBIND commands, as appropriate.
Partition OAM table spaces larger than 2 GB.
Devices
Consider the following recommendations that relate to devices:
Determine and set the Initial Access Response Seconds (IARS) option.
Assign objects to storage classes that have an adequate IARS that is defined and to
management classes that do not cause a transition to a slower storage class until the
frequency of retrieving the objects is reasonably low.
Determine whether to place the object on disk or removable (optical or tape) media.
If the IARS opts for REMOVABLE media, determine whether to place the object on optical
or tape.
Verify that the required Sustained Data Rate is achieved based on the selected object
placement.
Tapes
Consider the following recommendations that relate to tapes:
Modify (CBROAMxx) MAXTAPERETRIEVETASKS and MAXTAPESTORETASKS (if you are using tape
retrieves because the default=1). Both of these parameters are configured at the global
level and at the storage group level.
The global level MAXTAPERETRIEVETASKS (tasks) is defined by SETOAM. SETOAM specifies the
total number of concurrent tape retrievals that are possible at a time. (It controls the
maximum number of tape drives that can be concurrently allocated to the OAM address
space for reading object data from tape.) This number must be less than or equal to the
number of tape drives on the system. Do not specify a number that is greater than the
number of tape drives that are available to OAM for the MAXTAPESTORETASKS or the
MAXTAPERETRIEVETASKS subparameters because a system can go into allocation recovery
and attempt to allocate tape drives after all of the tape drives are in use, causing system
problems.
The storage group level MAXTAPERETRIEVETASKS (tasks) specifies the maximum concurrent
tape retrievals that are possible for a specific storage group. If MAXTAPERETRIEVETASKS is

not set, the default for each storage group is 1. This value must be set for each storage
group that requires a value larger than the default of 1. For a single storage group, you
must set this parameter if you must retrieve documents from two or more tapes
concurrently.
Set the OAM cataloged procedure parameter MAXS (the number of storage groups that the
storage management cycle processes concurrently) to an appropriate value. If MAXS
increases above 10, the effectiveness of concurrency diminishes and OAM processing
can be severely constrained or unsuccessful. If concurrent processing includes OBJECT
storage groups that write to tape volumes, you must specify the correct corresponding
(global level) MAXTAPERETRIEVETASKS and MAXTAPESTORETASKS values on the SETOAM
statement.
If you are using optical platters or tapes, set the tape DEMOUNTWAITTIME time parameter
appropriately. This parameter determines how long OAM leaves a tape volume mounted in
anticipation of another retrieval request from that device.
Maximum Object Size (MOS)

OAM now supports storing object sizes up to 256 MB. Authorized program analysis report
(APAR) OA03623 lists the program temporary fix (PTF) that is available for each release of
z/OS. To enable support for object sizes up to 256 MB, you must specify the maximum object
size by adding MOS =256 to the OAM subsystem definition parameter INITPARM in the
SYS1.PARMLIB(IEFSSNxx) member.
The Maximum Object Size (MOS) can be viewed by running the following command:
D SMS,OAM
The results of that command are shown:

OAM1 Parms: TIME=GMT MSG=EM UPD=N QB=Y
MOS= 256 OTIS=N LOB=N DP=N
If the MOS is too small, Content Manager OnDemand returns an error similar to “OAM Store
Failed with an OSREQ RC=8 and Reason=24020202”. You must increase the MOS size. For
more information, review the document at this website:
http://www.ibm.com/support/docview.wss?uid=swg21408525
Optical platters
When you work with optical platters, check and adjust the values for the following parameters
in SYS1.PARMLIB(CBROAMxx):
MOUNTWAITTIME: Specifies the amount of time (in minutes) that can pass while a volume
waits to be mounted on an operator-accessible drive within an optical library. After this
time expires, message CBR4426D is issued to allow the operator to try again or to cancel
the volume mount request. This value can be any numeric value 1 - 9999. If the operator
retries the mount request, the value that is specified in the MOUNTWAITTIME parameter is
used for the retry. The default value of this parameter is 5 minutes.
OPTICALDISPATCHERDELAY: Specifies the number of seconds that the OAM optical
dispatcher delays the processing of certain requests to minimize the flipping of optical disk
cartridges in an automated optical storage library that expects that another read request
for the currently mounted optical disk volume will arrive within this delay interval.
The OAM optical dispatcher delays processing of a unit of work for a specific period, when
all of the following conditions are true:
– A read request for an object on a currently mounted optical disk volume was
completed.

– No request exists for the currently mounted optical disk volume that is waiting to be
processed on the OAM optical dispatcher queue.
– The OAM optical dispatcher found a read request for another optical disk volume
(either the opposite side of the currently mounted volume or an unmounted optical disk
volume) and is about to dispatch this unit of work.
– A nonzero optical dispatcher delay value is specified with the OPTICALDISPATCHERDELAY
keyword on the SETOPT statement in the CBROAMxx PARMLIB member.
If another read request for the currently mounted optical disk volume arrives within the delay
interval, that unit of work is dispatched immediately upon arrival. If no read request for the
currently mounted optical disk volume arrives within the delay interval, another request for a
different optical disk volume (either the opposite side of the currently mounted optical disk
volume or an unmounted optical disk volume) is dispatched. Valid values for seconds are
decimal numbers 1 - 60. If usage of this parameter is necessary, use of a low value, 1 - 5, is
suggested.
ARS.CFG setting
If you are configuring a Content Manager OnDemand for z/OS system to use OAM for archive
storage, you must ensure that the ars.cfg file is updated to reflect that OAM is used as the
storage manager. Example 5-1 shows an example of the settings to configure for OAM
archive storage enablement for Content Manager OnDemand.
Example 5-1 ars.cfg OAM parameter setting

#######################################
# OAM Parameters (Object Server Only) #
#######################################
#
# Number of OAM SubServers.
# 0 - OAM is not used
# Otherwise - The number of OAM SubServers to handle
# connections to OAM
#
ARS_NUM_OAMSRVR=20
ARS_OAM_DB2SSID=DB2T
ARS_OAM_PLAN=CBRIDBS
5.3.3 Defining a storage set

When the Content Manager OnDemand administrator defines a new storage set, the Add a
Storage Set window opens, as shown in Figure 5-12 on page 114.

Figure 5-12 Adding an OAM storage set
The administrator must define values for the following fields to add a storage set:
Name: The name of the storage set.
Description: The storage set description, up to 120 characters.
Load Type: Where Content Manager OnDemand stores data. Two choices are available:
– Fixed: Content Manager OnDemand stores data in the primary storage node that has
the load data field selected. When you set load type to Fixed, you must select the Load
Data check box for one primary storage node. A storage set can contain one or more
primary storage nodes. Several different collection names can be used. Content
Manager OnDemand loads data in one primary storage node regardless of the number
of primary nodes in the storage set.
– Local: Content Manager OnDemand stores data in a primary node on the server on
which the data loading program runs. This load type applies to z/OS.
Then, the administrator clicks Add to add a primary storage node to this storage set. The Add
a Primary Node window opens, as shown in Figure 5-13 on page 115.

Figure 5-13 Adding a primary storage node to the storage set
The object server is the TCP/IP host name alias, fully qualified host name, or IP address of
the server on which the storage node exists. Select a name from the list or enter the name of
a Content Manager OnDemand object server. Select *Content Manager OnDemand if the
storage node is on the Content Manager OnDemand library server.
The load data check box indicates that the data is loaded to this collection. You must select
the OAM check box. The Logon, Password, and Verify Password fields are used only when
Tivoli Storage Manager is selected for the access method.
A one-to-one relationship exists between a collection and a storage set. You can add more
primary storage nodes to one storage set, but only one primary storage node can be active at
a time.
Figure 5-14 on page 116 shows the relationship between the creation of storage sets and
OAM.

ICF Catalog
OAMAE.CLL CT001
GROUP001
Storage Group ACS Routine
If &ACSENVIR = Store
Select
If &DSN = ‘OAMAE.CLLC T001’
Set &Storegroup = ‘GROUP001’
ICF Catalog
OAMAE.CLL CT001
OAMDATA
Needed DIRECTORYTOKEN-----GROUP001
SMSDATA
ST ORAGECLASS---------SCDASD
MANAGEMENTCLASS-------MCD ASD
Figure 5-14 Relationship between OAM and Content Manager OnDemand
Object naming conventions

The object name identifies the object within a collection. The object name is unique within a
collection and it is provided by the Content Manager OnDemand application. Currently, no
installation exits allow any customization of these names. The object name is composed of
the application group name and the load identifier within the application group portion of the
load ID. The load identifier within the application group is composed of a numeric sequence
number followed by a character string, such as FAAA. This string is then converted into two
qualifiers of the object name:
L indicates that the object contains document data.
R indicates that the object contains resource data.
The application group name is added, and an object name looks like the following syntax:
A BDA.L1.FAAA
The maximum size of an object is specified through the Content Manager OnDemand
Administrator Client when you define an application group. The default value is 10 MB.
Currently, the maximum size for an OAM object is 256 MB. The Content Manager OnDemand
administrator must be careful not to specify a value that exceeds this limit.
Important: In the current implementation, Content Manager OnDemand is not aware that
an object was deleted by OAM based on the management class criteria that are set by the
Storage Management component. A user can search for data that is no longer available.
No synchronization occurs between OAM object expiration and index expiration. Ensure
that you define the index expiration correctly when you define the application group.
Figure 5-15 on page 117 shows the window in which you can set up the index expiration for
Storage Management when you define or update an application group.

Figure 5-15 Defining index expiration in Content Manager OnDemand
Tip: Content Manager OnDemand and OAM can run in different DB2 subsystems
(different DB2 subsystem identifiers (SSIDs)).
5.3.4 Storing data in Virtual Storage Access Method datasets

Another way to store data on the z/OS system is through Virtual Storage Access Method
(VSAM). Content Manager OnDemand can create objects that are stored in VSAM datasets.
All storage management issues for VSAM datasets, such as allocation, backup, and
migration, apply for these object datasets.
To create a storage set that stores objects in VSAM datasets, the Content Manager
OnDemand administrator must provide the first-level qualifier for the defined cluster
statement. In the example that is shown in Figure 5-16 on page 118, VSAMTST is the high
(first) level qualifier.

Figure 5-16 Defining a storage set for VSAM
Based on these parameters, Content Manager OnDemand creates VSAM datasets during
the arsload program. A catalog entry is created, as shown in Example 5-2.
Example 5-2 VSAM dataset name

VSAMTST.FAA.L1.FAAA
This catalog entry is created automatically by the Content Manager OnDemand system. The
only part that you can create for yourself is the first-level qualifier. The space allocation during
the Define Cluster is performed by the Content Manager OnDemand code, as well. The
default object size that is set when you define the application group influences the number of
bytes for the primary allocation and the secondary allocation. The number of bytes is divided
by 16 for the primary allocation. Every time that an arsload command runs with this storage
set, this amount of data is allocated even if the objects are much smaller.
Every load creates two VSAM datasets: one VSAM dataset for the data, and one VSAM
dataset for the index. Every Define Cluster of a VSAM dataset is a catalog entry. If you have
several million loads with this storage set, your catalog grows large.
You can browse the VSAM dataset, but if the compression is on, you cannot see much. For
test purposes, compression can be switched off and then the content of the VSAM dataset is
viewable. Compression can be switched off on the load information in the application window.
If you store AFP data to VSAM, the resources are stored in a different VSAM dataset.

5.4 Archive Storage Manager for IBM i
The Disk Storage Manager of Content Manager OnDemand for i maintains a copy of
documents on disk. Disk Storage Manager migrates documents from cache to the Archive
Storage Manager (ASM). ASM then migrates documents to archive media.
ASM maintains one or more copies of documents on archive media, such as disk pool, optical
(physical or virtual), or tape. The Content Manager OnDemand administrator decides the type
of archive media that is required, configures the storage devices on the systems, and defines
the storage devices to ASM. To store application group data on archive media, the application
group must be assigned to a storage set that is managed by ASM.
When an application group is created, the Content Manager OnDemand administrator

specifies how long the documents must be maintained on the system and whether the index
data needs to be migrated from the database to archive media. Content Manager OnDemand
system management programs use this information to migrate documents from cache to
ASM, delete documents from cache, migrate index data from the database to archive media,
and delete index data from the database. Content Manager OnDemand can then reclaim the
space that was used by the migrated and expired data.
Disk Storage Manager expires data based on the Life of Data and Indexes value. You can
access this setting by clicking Application Group → Storage Management. ASM deletes
data from the archive media when the data reaches its storage expiration date. The Content
Manager OnDemand administrator defines management information to the ASM for the
Content Manager OnDemand data that is managed. This management information includes
storage volumes that can contain Content Manager OnDemand data, the number of copies of
a report to maintain, and the amount of time to keep data in the archive management system.
5.4.1 Migration policy

Migration policies and storage sets must be defined before you can define reports to Content
Manager OnDemand or load data into the system. Migration policies contain migration and
storage media characteristics for data that is archived by using Content Manager OnDemand.
The information is used by ASM to determine whether and when to move archived data
through a hierarchy of storage media, such as disk, optical, or tape. Each step in the
movement of data through this storage hierarchy is referred to as a migration policy storage
level. Each migration policy must contain at least one storage level. Additional levels might be
defined to meet your storage and retrieval requirements.
The Cache Only - Library Server storage set is no longer created automatically with the
installation of Content Manager OnDemand for i. The “Cache Only” storage set is limiting
because you cannot add any storage levels to it. A better alternative is to define a disk pool
and create a migration policy instead. This approach provides the flexibility of adding
additional storage levels to the policy later.
When you create a migration policy, a storage set of the same name is automatically created
by Content Manager OnDemand. If you plan to keep all of your archives on disk, the best
approach is to create a disk pool and to create a migration policy that specifies “No Maximum”
for the duration level. Disk Storage Manager expires data and indexes whenever the number
of days is reached in the Life of Data and Indexes setting in the application group, or
whenever an expiration level in the migration policy is encountered, whichever comes first. If
no expiration level is in the migration policy, data is only expired according to the Life of Data
in the application group.

If you plan to add a virtual optical level later to take advantage of improved save and restore
times or to use the WORM option, you can initially specify 90 days, for example, for the disk
pool level, with no other defined storage levels. When a virtual optical level is added later, the
archives are moved from the disk pool level to the virtual optical level. With this technique, you
must never add an expiration level after the disk pool level because if that level is
encountered, the archives are expired.
In the status report that is created by ASM, you might see messages that indicate that the
number of days in the ASP01 disk pool level was exceeded because no level is available after
90 days in this example. You can ignore these messages.
If you choose the default in the application group to migrate data from cache when data is
loaded, a copy of the data is archived to the integrated file system (IFS) CACHE directory and
to the ASMREQUEST directory. When you run Disk Storage Manager, the data is deleted
from cache after the Cache Data for Days duration ends. When you run ASM for the first time
after you load data, the data is moved to the first level of the migration policy, ASP01 in our
example. If aggregation is used, the data is not migrated until the appropriate object size is
aggregated, or until the number of days to aggregate was passed. The data remains in
ASP01 until the number of days in the Life of Data and Indexes is reached or an expiration
level in the migration policy is encountered, whichever comes first.
Most administrative functions for Content Manager OnDemand for i can be carried out with
the Content Manager OnDemand Administrator Client. The objects that are necessary for
Content Manager OnDemand archive storage management on IBM i are created by using the
Content Manager OnDemand component of the web-based IBM Navigator for i (Figure 5-17).
To create a migration policy for use by the archive storage management process, storage
devices must be defined for the types of archive media that are required by the Content
Manager OnDemand system. For our scenario, we created a disk pool storage group and an
optical storage group.
Figure 5-17 IBM Navigator for i
Disk pool storage group

A disk pool storage group is used to identify an IBM i auxiliary storage pool that ASM uses as
disk storage media when it migrates archived data. Use IBM Navigator for i to add a disk pool
storage group (Figure 5-18 on page 121).

Provide the following information for disk pool definition:
A pool number that corresponds to an existing auxiliary storage pool
A description of the storage group
The type of data, which is primary or backup
Figure 5-18 Content Manager OnDemand for i disk pool definition
Optical storage group

Optical storage groups are used by Content Manager OnDemand to group sets of optical
volumes for the storage of related data. Optical storage groups are used to group physical
optical volumes and virtual optical volumes. Each optical storage group must contain only one
type (physical or virtual). By using a specific storage group in the migration policy, the
administrator can control the sets of reports that are stored on a particular set of optical
volumes. Use IBM Navigator for i to define the optical storage group (Figure 5-19).
Figure 5-19 Content Manager OnDemand for i optical storage group definition

When you define the optical storage group, you provide the following information:
Storage group name
Description of the storage group
Volume full reset when optical volumes are rewritable and you want to reuse the storage
space (only available with local area network (LAN)-attached optical jukeboxes)
Free space threshold percent (the percent at which Content Manager OnDemand starts
storing to rewritable volumes again if the volume full reset parameter is checked)
Storage group type, which is primary or backup
After you define the optical storage group, use IBM Navigator for i to define the optical
volumes to the Content Manager OnDemand system (Figure 5-20).
Figure 5-20 Content Manager OnDemand for i optical volume definition
When you define optical volumes, provide this information:

Volume name: Your volume name.
Volume type: Primary or backup.
Capacity in megabytes: Capacity of one side of the optical media after it is initialized.
Optical media family:
– Rewritable (REWT)
– WORM
– Universal Disk Format single-sided (UDF1) that is used by DVD RAM drives
– Universal Disk Format or double-sided (UDF2)
– Virtual Rewritable (VRWT)
– Virtual WORM (VWRM)
Optical storage group: Your optical storage group.
Optical library: Library name, which can be provided for documentation.

Volume is full: Set when the optical volume reaches its capacity.
Opposite side volume name: For the other side of the optical platter (only required for
REWT, WORM, and UDF2).
After the storage groups are established, use IBM Navigator for i to define the migration policy
that is needed to use the storage groups (Figure 5-21).
Figure 5-21 Content Manager OnDemand for i migration policy definition
The migration policy definition includes the following items:

Policy name and description: This field is for the policy name and its description.
Tip: The preferred practice is to put information, such as the length of time and the
location of the data, in the description rather than in the policy name field. You can
change, add, and delete levels, but you cannot change the name. If your requirements
change, you do not want a name that is no longer accurate.
Enable aggregation: If this item is selected, ASM combines individual archived objects into
larger objects to provide a more efficient process. Archived objects are appended to the
same file until the aggregate is closed.
Maximum size: The value of this field determines the maximum size of the aggregate file.
ASM closes the existing aggregate and opens a new aggregate when the maximum value
is reached.
Close aggregate only when maximum size is reached: If this item is selected, the
aggregate stays open until the maximum size is reached.
Close aggregate based on number of days: The value in this field specifies the number of
days before an aggregate closes. ASM closes the aggregate after the specified number of
days or when the specified maximum size is reached, whichever occurs first.

Important: The aggregation process occurs before the migration of the object from
disk to the first ASM storage level. Only aggregate files that are closed are eligible for
migration by ASM. If the specified maximum file size is large and the size of the
archived objects is small, the aggregate file can remain open for long periods. Also, the
Content Manager OnDemand objects might remain on disk longer than the period that
is specified by the application group. Choosing to close the aggregate after a specified
period addresses this problem.
Tape backup requested and media type: The Tape backup requested field indicates
whether a one-time tape backup must be made of the data before it is archived. The Media
type field indicates the type of tape to use for the backup.
Storage levels in this policy: This section determines the path that the archived data
follows through the different archive storage media. The order of the levels determines the
migration sequence. Storage levels are created by placing the cursor on an existing
storage level (if one exists) and clicking Add Before or Add After. The Migration Policy
Storage Level Definition window (Figure 5-22) opens.
Figure 5-22 Content Manager OnDemand for i new policy level

In the Migration Policy Storage Level Definition window (Figure 5-22 on page 124), you
provide the following information for the new policy storage level:
Level identifier: This field distinguishes the different storage levels within the migration
policy. The value must be unique within the storage levels of the migration policy. ASM
uses the level identifier to determine the current level of the migration hierarchy and to
determine the next level to which the data must be moved. The identifier can be numeric
(for example, 10, 20, and 30) or descriptive (for example, ASP or OPT).
Disabled: Specifying this option causes ASM to skip this level in the storage hierarchy. The
Disabled option can be used in a situation where an optical unit is added to the system
later, but the administrator wants to add an optical policy level and disable it.
This option can also be used when migration to a policy level is discontinued, such as a
tape unit. A policy level cannot be removed if data is archived to it, but it can be disabled
so that no more data is migrated to that level.
Description of the policy level: Use this field to provide a description of the policy level.
Primary media type: The types from which you can choose are optical, tape, disk, or
expire. If you select expire as the last policy level, when data reaches this level in the
migration sequence, it is removed from the archive system even if the retention period that
is specified in the application group is not exceeded. It is not necessary to specify an
expire level. Instead, you can let the data expire when it exceeds the number of days that
are specified in the Life of Data and Indexes in the application group.
Duration at this level: In this field, you specify either no maximum or a specified number of
days before ASM moves the data to the next level in the migration sequence.
Primary storage group: Select the storage group that you want to use to store the data at
this level.
Create backup copy and backup storage group: You select these options if you want ASM
to create a backup copy of the data when it moves to this policy level. The backup storage
group must be created with a media type of backup.
Stage to disk when data is retrieved from tape and the duration on disk in days: Choose
these options to cache data that is returned from tape to disk for the number of days that
are specified.
In our scenario, we created a policy level that stores data for 100 days on disk by using the
disk pool storage group that is assigned to auxiliary storage pool 1. We also created a policy
level that stores data on optical storage indefinitely and uses the REPORTS optical storage
group. We did not include an expire level, so the data always expires according to the Life of
Data and Indexes in the application group. We can use this migration policy for all application
groups if we choose. Documents that are in application groups with the Life of Data set to 100
days or fewer are never migrated to optical because the disk pool storage level specifies 100
days. This approach is easy to manage.
Figure 5-23 on page 126 shows the final migration policy structure.

Figure 5-23 Content Manager OnDemand for i migration policy hierarchy
When the migration policy is created, a corresponding storage set is created for the Content
Manager OnDemand instance with which the migration policy is associated. The storage set
is displayed in a listing of storage sets by using the Content Manager OnDemand
Administrator Client but it can only be viewed. No updates can be made to existing storage
sets, and no new storage sets can be added by using the Content Manager OnDemand
Administrator Client. Storage sets in the Content Manager OnDemand for i system can be
created and modified only by using IBM Navigator for i migration policies.
5.4.2 Application group storage management

The application group storage management settings (Figure 5-24 on page 127) determine
how long report data and indexes are kept in cache storage before they expire. All documents
in the application group are loaded on the media that is part of the storage set to which the
application group is assigned. All documents in the application group migrate according to the
rules that are defined for the application group’s migration policy. When the application group
is defined, choices are made concerning how soon data is migrated to archive storage after
the report load is completed.

Figure 5-24 Content Manager OnDemand for i Add an Application Group Storage Management tab
Cache Data
The Cache Data setting determines whether the report data is stored in disk cache, and if so,
how long it is kept in cache before it expires. If the Cache Data for n Days option is selected,
the search cache is always selected.
Search cache determines whether Content Manager OnDemand searches cache storage
when users retrieve documents from the application group. When you set Cache Data to No,
you can configure Content Manager OnDemand to retrieve existing documents from cache
storage while preventing new documents from being copied to cache storage. If you choose
not to store reports in cache, you must select a storage set that supports archive storage.
Life of Data and Indexes

The Life of Data and Indexes settings determine the length of time that report data, indexes,
and resources are maintained in the Content Manager OnDemand system before they are
deleted from the application group. The report data, indexes, and resources can be
maintained indefinitely, if set to never expire, or they can be kept for up to 273 years. If your
retention requirements change, the Life of Data and Indexes value can be changed. The
change affects data that is already archived and new data that is stored to the application
group.
Disk Storage Manager maintains documents on disk. It is initiated by the Start Disk Storage
Management (STRDSMOND) command. Disk Storage Manager can delete documents after they
exceed the cache data or Life of Data periods. For more information about running the
STRDSMOND command, see the IBM Content Manager OnDemand for i - Common Server
Administration Guide, SC19-2792.

Expiration Type
The Expiration Type determines how report data, indexes, and resources are expired. Three
expiration types are available:
Load: If the expiration type is Load, an input file at a time can be deleted from the
application group. The latest date in the input data and the Life of Data and Indexes
determines when Content Manager OnDemand deletes the data. Data that is stored in
archive storage is deleted by the storage manager based on the archive expiration date.
Load is the recommended expiration type.
Segment: If the expiration type is Segment, a segment of data, which is a database file
that contains index values for an application group, at a time is deleted from the
application group. The segment must be closed and the expiration date of every record in
the segment must be reached. If small amounts of data are loaded into the application
group, and the maximum rows value is high, the segment might be open for a long period,
and the data is not expired for the period.
Document: If the expiration type is Document, a document at a time is deleted from the
application group. Storing with an expiration type of Document causes the expiration
process to search through every document in the segment to determine whether the
expiration date was reached, resulting in long processing times.
Expiration Type Load is not allowed when you use the ARSLOAD ADD API or when you use
the workstation APIs. If you plan to use these APIs with an application group, specify
Document for the Expiration Type.
5.4.3 Advanced application group storage management

With the advanced storage management settings (Figure 5-25), you can adjust the size of the
load object and determine when report data, indexes, and resources are migrated to archive
storage.
Figure 5-25 Content Manager OnDemand for i Application Group Advanced Storage Management

Object Size
The Object Size parameter determines the size of a storage object in kilobytes. Content
Manager OnDemand, by default, segments and compresses stored data into 10 MB storage
objects. The default of 10 MB is the recommended object size value.
Important: Setting the value too small or too large can adversely affect load performance.
Note: The object size, which is defined here, must be equal to or larger than the size of the
compressed storage objects that are defined in any application that is assigned to the
application group.
Migrate Data from Cache pane

This section of the Advanced Storage Management window determines when documents and
resources are migrated to archive storage. A storage set that is associated with a migration
policy that uses archive media must be selected to enable migration to archive storage. The
possible values are listed:
No: Data is never migrated from cache. This option is unavailable when a storage set that
is associated with archive storage is selected for the application group.
When Data is Loaded: Data is migrated to archive storage when the load process runs
because of a store command, such as Add Report (ADDRPTOND), Start Monitor (STRMONOND),
or ARSLOAD.
Next Cache Migration: Data is migrated to archive storage the next time that Disk Storage
Manager is run.
After Days in Cache: This value specifies the number of days that data remains in cache
storage. After the data reaches the prescribed number of days in cache storage, the data
is copied to archive storage the next time that Disk Storage Manager is run.
ASM is started with the STRASMOND command. The command must be run only in batch. For
more information about running the STRASMOND command, see the IBM Content Manager
OnDemand for i - Common Server Administration Guide, SC19-2792.

6
Chapter 6. Security
This chapter describes the security features that are provided by IBM Content Manager
OnDemand (Content Manager OnDemand). It also provides examples of available
components and their usage to create a secure environment.

Content Manager OnDemand security overview
Data separation
API access
Data security
Data encryption
Security exits

6.1 Content Manager OnDemand security overview
The amount of security that is employed by an organization varies by organization and is
normally proportional to the cost of data loss because of security leaks or other issues.
For any system, the first layer of security is its environment. Several attributes are included in
a secure environment:
Physical security: Controlling physical access to the system and ensuring that the system
is protected from both natural and man-made disasters.
Data security: Controlling access to online data by using both authentication and
authorization techniques; controlling access to offline data, including all backup copies of
the data, data storage sites, and encryption of the backup copies of data.
Personnel security: Hiring trusted employees, limiting employee access based on
employee role, and redundancy.
Although environmental security is beyond the scope of this book, it is important to be aware
of and prepare for security in these areas.
This section describes what Content Manager OnDemand can provide from a security
perspective.
Content Manager OnDemand is a flexible and scalable system. This flexibility allows the
deployment of multiple security features by using multiple methodologies. The descriptions
within this chapter are examples of the available components and their usage to create a
secure environment.
Figure 6-1 outlines many of the components that are part of Content Manager OnDemand’s
security features.
Offsite
location
Backup system
backu ps
Web U sers
CMOD CMOD Server
S tach f ile
Com ma nd s Data Center
Lib rary Server Exte rna l

We b Serve rs Logon… Query Secur ity
Java API
Sy st em tables
Listening port
A ppli cation Group data t ables
SS L port
Obje ct Serve r CMOD data arch ive

GU I Use rs Retrieve
CMOD Develo pment Lab
Figure 6-1 Content Manager OnDemand security overview

The complete security cycle begins with code creation through data loading, storage, and
access, and ends with data (and index) expiration. The following list outlines different types of
security that are described in this chapter. Within each type, different security techniques can
be implemented.
Code creation:
– Controlled environment
– Code scanning
– Quality assurance testing
Data separation:
– Multiple systems: Allowing users access only to the system that contains data that is
relevant to them
– Multiple object servers
– Multiple archive subsystems
– Application programming interface (API) access: Web server, web services, and
Content Management Interoperability Services (CMIS)
Data security:
– Administrative features: Login inactivity, disabling a user, locking out a user, and
defining password rules
– Content Manager OnDemand data model: Application groups (AGs) and folders
– Query restrictions
– Annotation security
– Securing access to Content Manager OnDemand commands (stash file)
Data encryption:
– Data at Rest
– Data in Motion: Secure communication between the server and the clients (Secure
Sockets Layer (SSL))
Security exits:
– User security and permissions exit (ARSUSEC)
– Unified logon exit (ARSPTGN)
– System log exit
6.2 Code security

The Content Manager OnDemand code is developed in a secure environment that follows
IBM guidelines. The Content Manage OnDemand development lab follows multiple preferred
practice methodologies to ensure the highest possible code and security standards. The goal
is to ensure that the code “works as designed”, does not perform any malicious actions, and
is resistant to external security breach attempts. In this section, we describe examples of the
practices that are followed.
Chapter 6. Security 133

6.2.1 Controlled environment
During development, all code is reviewed by two or more developers and passes through a
structured process within the development organization to ensure the integrity of the code.
The code is periodically scanned to ensure that no foreign code is included and to ensure that
safe programming techniques are applied. The following practices are applied:
Limited access: The source code is only accessible to the Content Management
OnDemand team.
Secure systems: The code is stored on secured systems behind the IBM firewall and can
only be accessed by the Content Management Development team.
Code reviews: All code modifications are reviewed by two or more developers on the team.
Separation of duties: Separate development, build, and test teams exist.
Redundancy: Two or more developers are familiar with each aspect (function and module)
of the code.
6.2.2 Code scanning

The code is scanned three times, once at the beginning of the release or fix pack, once during
the middle of the development process, and the last time at the end of the development
process. Each time, three types of scans are performed:
Code scan: This type of scanning searches for code that is external to the Content
Manager OnDemand developed code. The goal is to ensure that no code is unknowingly
inserted into the source code and to verify that all of the external code that is used is
correctly licensed and will not result in any future legal action.
Appscan source: This type of scanning searches for “bad code”. It verifies that all variables
and pointers are correctly initialized, and that during the program operation, the values of
variables and pointers can be changed only through the “correct” code path and cannot be
altered by external sources.
Appscan Web: This penetration testing program is run against the common gateway
interface (CGI) code to identify any potential security flaws.
6.2.3 Quality assurance testing

The quality assurance (QA) testing is run in parallel with the code development through the
development cycle. When developers create new code, they perform their own unit test to
ensure that the code works as intended. These unit tests are then passed to the QA team for
automation. The QA team automates these tests and adds other newly automated tests to the
regression bucket.
Every time a new build occurs, which is nightly during peak development, automated
regression and performance tests are run. These automated tests are run on the multiple
operating systems that are supported by Content Manage OnDemand (Windows, Linux, AIX,
IBM i, Linux on System z®, and z/OS). The goal is to detect any defects or performance
impact so that it can be corrected the following day.
Periodically, endurance and stress tests are run to ensure that the code can run for long
periods and under heavy workloads.
A specialized subset of these tests and cloud-specific tests are run against the Cloud release
of Content Management OnDemand.

6.3 Data separation
Content Manager OnDemand allows the separation (compartmentalization) of the
organization’s data into multiple separate partitions. Specific groups of users can access only
the partitions that contain data that relates to their operations. The separation of data can be
at the system level, the object server level, and the archive server level.
6.3.1 Multiple systems

The organization’s data can be spread over two or more separate systems. As illustrated in
Figure 6-2, User Group A can access only Content Manager OnDemand server A and cannot
access any other Content Manager OnDemand system or any other Content Manager
OnDemand data. If necessary, you can create a super user group that can access multiple
systems.
System access restrictions can be implemented by one or more of the following means:
A web server.
Firewalls, switches, or other network devices.
Only the correct user group is authenticated to use the system.
CMOD
T CP/IP Server A
network
C ontai ns part “A” o f
The o rgan ization ’s data
CMOD Client
User Group A
CMOD Client Firewall

Super User Group Switch
CMOD
…
Server B
Con ta ins pa rt “B” of

Th e orga niza ti on’ s da ta
CMOD Client
User Group B
Figure 6-2 Data separation at the system level
6.3.2 Multiple object servers

Data can also be separated at the object server level. In this case, the application group (AG)
data tables that contain the indexes that point to separated data are also separated.
Therefore, access to the AG data table is allowed only to users who need that data. As
illustrated in Figure 6-3 on page 136, User Group A of AG Data Tables Part A is pointed to
(allowed access to) the data on Object Server A, and User Group B of AG Data Tables Part B
is pointed to the data on Object Server B.

TCP/IP CMOD
network Library Server
AG AG
Data Tables D ata Tables
Part A data Part B data
CMOD Client
User Group A
CMOD - Object Server A

Con ta ins par t “A” of
Th e orga niza tio n’ s da ta
CMOD Client
User Group B
CMOD - Object Server B

Con ta ins par t “B” of
Th e orga niza tio n’ s da ta
Figure 6-3 Data separation at the object server level
6.3.3 Multiple archive servers

Data can be separated at the archive level. Typically, in this implementation, as illustrated in
Figure 6-4, the application group (AG) data tables remain separate and User Group A’s data
is stored on the Tivoli Storage Manager system A server, and User Group B’s data is stored
on the Tivoli Storage Manager system B server. The two Tivoli Storage Manager servers are
separate systems. This same type of separation is also possible by using object access
method (OAM) on z/OS systems. OAM enables the separation of data by placing the data in
different OAM collections on different storage devices.
T CP/IP CMOD
network Library Server
AG AG
Data T ables Data Tables
Part A data Part B data
CMOD Client
User Group A
CMOD –
Object Server
TSM system A
Co ntains p art “A” of
The orga ni zation’ s d ata
CMOD Client
User Group B
TSM system B
Co ntain s p art “B” of
The org ani zation ’s d ata
Figure 6-4 Data separation at the archive level

6.4 API access
An important component of Content Manager OnDemand is the Content Manager
OnDemand Web Enablement Kit (ODWEK) Java APIs. These APIs are used to build
applications that access the Content Manager OnDemand server. Various applications can
be built by using the APIs. Examples of applications include IBM Content Navigator (ICN) and
CMIS. By using the ODWEK APIs, you can also build your own application server or web
services applications.
All of these types of applications address the following situations:

Users communicating and interacting with a mid-tier, custom-built access mechanism that
controls access to the Content Manager OnDemand server. For example, the mid-tier
application can control whether a Content Manager OnDemand user request is accepted
or rejected, and if it is accepted, which Content Manager OnDemand server the request is
routed to.
The network transmissions between the ODWEK Java APIs and the Content Manager
OnDemand server use a proprietary Content Manager OnDemand protocol and optionally
can be encrypted by using SSL.
The network transmissions between the mid-tier custom application and the users can
optionally be encrypted by using SSL.
By using an optional user proxy implementation, multiple users can share a user ID and
password, therefore reducing the number of actual logons to the Content Manager
OnDemand server while maintaining secure access to the system through the
custom-built access mechanism.
The Java APIs can pass a security token through to the Content Manager OnDemand
server. This token can then be captured by the security exit and the exit can perform the
required special processing.
Figure 6-5 shows controlling access at the web server.
CMOD
Server
Content Navigator
webserver,
webservices,
CMOD Client CMIS
User Group A
TCP/IP
C MOD Pr oprie tary
network K
WE C ommun ica tio n
O D API s CMOD
a protoco l
Jav
Server
C MOD Client
User Group B
C ustom bui lt
Acce ss me chan ism
Extern al C ustom bui lt

Securi ty Ca che da ta stor e
Figure 6-5 Data separation at the web server (mid-tier)

6.5 Data security
Access to the Content Manager OnDemand data tables is secured through various methods.
These methods include a secure data model, user authentication, SQL Query support,
annotation security, and securing access to the Content Manager OnDemand commands.
These methods are described in further detail in this section.
6.5.1 Content Manager OnDemand object-owner model

Content Manager OnDemand internal security is based on an object-owner model, which is
illustrated in Figure 6-6. Details about the object-owner model are in the IBM Content
Manager OnDemand for Multiplatforms, V9.5, Administration Guide, SC19-3352. In this
context, a Content Manager OnDemand instance is an implementation of the library server,
one or more object servers, the data access, and the storage model. The data access and
storage are implemented in the form of objects. The following objects are all Content Manager
OnDemand objects:
Users
Groups
Application groups
Folders
Cabinets
Applications
Holds
Storage set
Printers
System Ad ministrator
OnDemand instance B
OnDemand instance A
User Administrator Users Groups
Report
Administrator Application Groups Folders Cabinets
Applications H olds Storage Sets Printers
Figure 6-6 Content Manager OnDemand internal security
The Content Manager OnDemand object-owner model design handles the following
situations:
A single system administrator to control one or more Content Manager OnDemand
instances through a single Administrator Client interface.
Flexibility to create user administrators who manage users and groups for a specific
Content Manager OnDemand instance.
Flexibility to create report administrators who manage application groups, folders, and
cabinets for a specific instance.

Implementing report security that is based on limiting object access to selected groups of
users.
Elimination access to Content Manager OnDemand objects unless explicit permission is
granted.
In summary, with this model, organizations can separate and isolate report (data) ingestion
and access to various users and groups. Additionally, organizations that provide billing,
payroll, accounting, and bill presentment services for a number of other companies (their
clients) also benefit from this model, because users from one company are isolated from the
data and users of another company. Furthermore, large systems can decentralize system
administration so that report and user administrators can be delegated for the management of
components of the overall Content Manager OnDemand system.
6.5.2 Administrative features

Use the Administrator Client to control user logon parameters. These parameters are set in
the Login Information tab in the System Parameters window, as shown in Figure 6-7.
Figure 6-7 Administrator Client - setting the logon restrictions
We describe these parameter settings in the following subsections.
Check Previously Used Passwords

This setting specifies whether you want users to be able to reuse a previous password. You
can make users create up to 10 unique passwords before they can reuse a previous
password. Use this setting to enforce security policies. For example, you can force the user to
not reuse the eight most recent passwords.

Disable Or Lock Out After Failed Logins
This setting specifies whether you want to limit the number of failed login attempts by a user.
You can limit the number of login attempts, specify how many failed attempts you want to
permit, and specify whether to disable or lock out the user after the user exceeds that number
of attempts.
If you choose to disable a user, the user must request that the system administrator re-enable
the user ID.
If you choose to lock out the user, the user must wait to attempt another login. You specify
how many minutes to wait in the Number Of Minutes To Lock Out User field.
LDAP authentication
Use Lightweight Directory Access Protocol (LDAP) to store authentication values on a
separate organizationally centralized server that is remote from Content Manager
OnDemand. LDAP can be used in place of the user security exit to manage basic login
authentication. Figure 6-8 shows how Content Manager OnDemand works with LDAP.
LDAP Server
CMOD Server
AP
LD ase
CMOD Windows t ab
da
Clients
Webserver
HTTP
CMOD browser
Clients
Figure 6-8 Content Manager OnDemand works with LDAP
You can specify whether you want to use LDAP authentication in your Content Manager
OnDemand server.
When you enable LDAP authentication, the Content Manager OnDemand server makes an
authentication request to the LDAP server every time it receives a login request from the
client. The Content Manager OnDemand server processes the client request only after the
user information is verified by the LDAP server.

If you use LDAP, consider the following scenarios:
The LDAP server runs on another system and it connects to Content Manager OnDemand
through TCP/IP.
In this scenario, a time delay occurs between when the verification request is issued by
Content Manager OnDemand and the result is returned to Content Manager OnDemand.
The length of this time depends on the Internet Protocol network connection, the response
time of the LDAP server, and the current LDAP workload.
Users with admin-level security bypass LDAP.
You can compare an admin user’s response time to a production user’s response time to
determine the LDAP impact.
The LDAP server or the connection to the LDAP server fails.
When this scenario happens, users cannot log in to Content Manager OnDemand, except
for users with admin-level security.
Login Processing (case sensitivity)

With this parameter, you can specify whether user IDs and passwords are case-sensitive. By
default, user IDs and passwords are case-insensitive. When you add a user, Content
Manager OnDemand converts lowercase letters in the user ID to uppercase letters.
A person can type letters in a user ID in uppercase, lowercase, or mixed case letters. For
example, if you add the user LaGuarde, a person can enter LAGUARDE, laguarde, or
LaGuarde to log on to the server.
If you select User ID to be case-sensitive, a user must type the user ID exactly as it was
entered when the user was added. For example, if you add the user ID LaGuarde, the user
must enter LaGuarde to log on to the server.
If you set a password as case-sensitive, a user must enter the password exactly as it was
entered when the user was added.
Important: Do not change the case-sensitive settings for user IDs and passwords after you
install the system.
Decide whether to make user IDs and passwords case-sensitive when you install the
system. Change the defaults if necessary, but do not change the settings later. Otherwise,
the following situations occur:
If user IDs are initially case-insensitive and you later choose User ID to be
case-sensitive, user IDs that were added before you changed the parameter must be
entered in uppercase. The same is true for passwords.
If user IDs are initially case-sensitive and you later clear the case-sensitive restriction,
the user IDs that were added before you changed the parameter might contain mixed or
lowercase letters, which are no longer valid. The same is true for passwords.
Note: If users log on to Content Manager OnDemand with the IBM CICS® client program,
you must configure the system to ignore the case of user IDs and passwords.
Maximum Password Age

This setting specifies a time limit for passwords and determines when Content Manager
OnDemand prompts users to change passwords. The default setting is Password Never
Expires, which means that passwords do not expire and Content Manager OnDemand never
prompts users to change passwords.

If you click Password Always Expires, users must change to new passwords each time that
they log on to a server. To set a specific time limit for passwords, select Expires In __ Days
and enter the number of days that passwords are valid in the space that is provided. The
value can be 1 - 365.
Minimum Password Length

This setting specifies whether passwords are required. If passwords are required, it specifies
the minimum number of characters that passwords can contain. The default value is At Least
8 Characters, which means that passwords must contain at least eight characters.
If you click Permit Blank Password, which means that passwords are not required, the valid
password length is 0 - 128.
To set a specific minimum password length, click At Least __ Characters and enter a
number in the space that is provided. The value can be 1 - 128.
When a user changes a password, the client checks the number of characters that the user
entered. The new password must contain the minimum number of characters. Otherwise, the
user receives an error message.
Password Expiration Notification

This setting specifies whether to notify users that their password expires within the specified
number of days.
Changing an Expired Password

Content Manager OnDemand provides password expiration processing to help you manage
security on the system. You can set a value that represents the time in days that passwords
that are assigned to users remain valid. After a user’s password reaches the value that you
specify, the user must change the password.
After a password reaches the expiration value, the next time the user logs on to a server,
Content Manager OnDemand prompts the user to enter a new password. The user must
enter the current password, a new password, and verify the new password by reentering the
new password.
Session Inactivity Time Out

This setting specifies when Content Manager OnDemand terminates sessions between
inactive clients and the server. The default setting is Time Out in 60 Minutes. Never Time Out
means that Content Manager OnDemand does not terminate a session, regardless of how
long the client remains inactive.
To set a specific inactivity timeout, click Time Out In __ Minutes and enter the number of
minutes in the space provided. The value can be 1 - 1440 (24 hours). The period of inactivity
is measured between requests to a server. For example, when a user enters a query, Content
Manager OnDemand searches the database and builds the document list. This action
completes a request to the server. If the user does not work with the items in the document
list, open another folder, or start another query before the inactivity timeout occurs, Content
Manager OnDemand automatically terminates the session with the client.

Use caution when you set the inactivity timeout. Choose the correct amount of time when you
specify this setting. For example, assume that you set the inactivity timeout to 10. You log on
to Content Manager OnDemand to add an application group. Creating the application group
might take you 15 minutes to complete. After you enter all of the information about the
application group, you click OK to create the application group. Content Manager OnDemand
issues a message that a timeout occurred. You must log off the server, and you cannot save
the information that you entered about the application group.
System Logging
This setting specifies the messages that Content Manager OnDemand saves in the system
log. Content Manager OnDemand provides the system log to help you track activity and
monitor the system. Content Manager OnDemand saves messages that are generated by the
various programs, such as the ARSLOAD program. Content Manager OnDemand can save a
message in the system log when the following events occur:
A user logs on to the system.
A user logs off the system.
A user logon fails.
Application group data is queried, retrieved, loaded, updated, deleted, or maintained.
System Log Comments

This setting specifies whether the Administrator Client displays the System Log Comments
window when you perform an add, update, or delete operation.
You can enable comments and also specify whether the comments are required. If the
comments are required, the user must enter one or more characters in the Comments field.
User Login Inactivity

This setting specifies whether you want to disable users who do not log in after the specified
number of days. Users must contact the system administrator to enable their user IDs.
Query Restriction
This setting specifies the restriction to access to folders and application groups based on
index values. This setting is specified on the Permissions tab of the Update an Application
Group window, as shown in Figure 6-9 on page 144. You can set a restriction with the internal
Content Manager OnDemand security. The access restriction for an application group is
controlled through internal or external permissions (for example, RACF).

Figure 6-9 Update query restriction
When a user is given access to the application group, access can be further restricted to a
subset of the application group data by using a query restriction setting on the application
group. The query restriction is added to an SQL “where clause” that enforces the restriction.
Figure 6-9 is an example of a query that is restricted to statements with a balance that
exceeds 200. This query restriction is for all users with access to the application group
(*PUBLIC) that do not have a separate query restriction.
6.5.3 SQL macro support

Macro support can be used in SQL statements, including the query restriction. With the
macro support, the macro can be substituted by the appropriate value for the creation of SQL
statements that include current object values, such as application group name or user ID. The
available macros are listed in Table 6-1 on page 145.

Table 6-1 Available macros
Name Description
$ODUSERID The user ID that is used to log in to Content

Manager OnDemand.
$ODALIAS The alias that is defined to Content Manager

OnDemand for the user’s session.
$ODAGNAME The application group name.
$ODAGID The application group internal identifier.
The substitution does not include any necessary quotes for the macro, so you must ensure
that you use the correct quotation marks for the macro, if required, for example:
WHERE ag_field in (SELECT value FROM <customer_table> where userid = '$ODUSERID')
If you log on to Content Manager OnDemand as USER1, the SQL changes to the following
syntax:
WHERE ag_field in (SELECT value FROM <customer_table> where userid = 'USER1')
6.5.4 Annotations security

Content Manager OnDemand allows the secure creation and viewing of annotations (notes).
This capability is enabled through the Administrator Client window, as shown in Figure 6-10.
Figure 6-10 Add annotation authority

Controlling annotation creation
In Figure 6-10 on page 145, in the Add Authority section, specify the types of annotations
(referred to as “notes” in Content Manager OnDemand Client) that can be added by a user.
This selection applies to all users with authority to add annotations in the system.
You can select the following types of annotations:

Allow Public: Allows the user to add public annotations. Public annotations of a document
can be viewed by anyone who opens that document.
Allow Private to User: Allows the user to add private annotations to a document. These
annotations can be viewed only by the user that created the note, application group
administrators, and system administrators.
Allow Private to Group: Allows the user to add annotations to a document. These
annotations can be viewed only by a specific group of users.
Allow Text Annotations: Allows the user to add text annotations.
Allow Graphic Annotations: Allows the user to add graphic annotations.
Controlling annotations viewing

In the Annotation section of the Permissions tab of the Add an Application Group window,
specify the default viewing scope for all annotations, as shown in Figure 6-11.
Figure 6-11 Annotation viewing

You can select the following scopes:
View: Lets the user view annotations.
Add: Lets the user add annotations to documents.
Delete: Lets the user delete annotations.
Update: For text annotations, lets the user update the location of an annotation on the
page (by dragging the annotation marker to a new spot on the page). For graphical
annotations, this scope lets the user update the various characteristics of an annotation.
Copy: For text annotations, lets the user copy the text of an annotation to the clipboard.
6.5.5 Securing access with ARSSTASH and the stash file

Use the stash files and the ARSSTASH command to securely store and pass a password to
Content Manager OnDemand commands without the passwords appearing in the clear
(unencrypted text). The ARSSTASH command is used to encrypt the password by using
Advanced Encryption Standard (AES)-128 encryption and storing it in a file that is called a
stash file (an encrypted password file). The path to that stash file is then specified with the -p
parameter to those commands that require a password. The stash file is retrieved and
decrypted, and the password that is stored in the stash file is used. Therefore, the -p
parameter that is stored in JCL or other scripts or programs does not need to contain a clear
text password.
Multiplatforms: Stash files are the method of choice for securely storing passwords on a
Content Manager OnDemand for Multiplatforms server. Unified login does not work when
you use a Content Manager OnDemand for Multiplatforms server. Therefore, stash files
are the only mechanism that is provided to prevent passwords from being specified in
“clear text” for the various Content Manager OnDemand commands that require
passwords.
Special case for z/OS and IBM i

If you are using a z/OS server, consider using the z/OS unified login mechanism instead of
the stash file. Unified login provides the same functionality as stash files, which means that
the passwords are not stored unencrypted when at rest (for example, in JCL or scripts) but
without the additional burden of managing stash files. For example, when a password is
changed for a user, stash files that contain the encrypted password for that user must also be
changed.
If you are using an IBM i server, you might not need to use stash files because if you are
signed on to the IBM i server with a user profile that is defined to Content Manager
OnDemand and that has enough authority to perform the function you are running, Content
Manager OnDemand uses the IBM i user profile for that function (such as ARSDOC or ARSLOAD).
The -u and -p parameters are not required, therefore relieving you of the need to show or
store a password in clear text.
Accessing the stash file

Access to the stash file must be restricted by using file system permissions and other security
as appropriate. The stash file that is used by an instance is specified in the ARS.INI file (or in
the registry on Windows) with the SRVR_OD_STASH parameter, for example:
SRVR_OD_STASH=/opt/IBM/ondemand/V9.5/config/ars.stash

At IBM i version 7.2 and later, the following commands support the optional password stash
file (STASHFILE) parameter:
* ADDRPTOND
* MRGSPLFOND
* STRMONOND
Using the stash file

The stash file can be used by these commands:
arsadmin
arsdoc
arsload
arsmaint
arsrd
arsxml
In our example, we use arsload. The supported values for the -a parameter are available in
the arsstash help output.
The preferred method is to set a user ID and password for each command in the stash file.
Then, the arsload command can be run without specifying the -u userid or the -p password
parameter. This method is always recommended when you run the arsload command as a
daemon. To use this method, first run the arsstash command to store the user ID and
password for the arsload command:
arsstash -a 3 -s ars.stash -u <userid>
Then, enter and verify the password when you are prompted. When you run arsload, omit the
-u and -p parameters. The arsload command obtains the arsload user ID and password from
the stash file.
A second method is to specify the -u parameter for another Content Manager OnDemand
user ID that exists in the stash file. To use this method, first run the arsstash command to
store the user ID and password in the stash file:
arsstash -a 1 -s ars.stash -u <userid>
Then, enter and verify the password when you are prompted. When you run arsload, specify
the -u <userid> and -p <stash file> parameters. The arsload command obtains the
password for the specified user ID from the stash file.
Notes:
You can continue to run the arsload command with the password in clear text. However,
the arsload command generates a warning that specifying the password in clear text is
being deprecated and to use the stash file instead.
The stash file works with Content Manager OnDemand security, LDAP, and IBM i
security.
After you save the user ID and password in the stash file, remember to change the
password anytime that you change the user’s password in Content Manager
OnDemand; otherwise, the load fails. The ARSLOAD program can accept an expired
password. However, the ARSLOAD program fails if an incorrect password is specified.

Stash file information for z/OS
To use arsstash with Content Manager OnDemand for z/OS, the Integrated Cryptographic
Service Facility (ICSF) must be available on the z/OS system to provide AES-128 encryption.
The encryption can be performed in either software or hardware.
In the examples, a started task name of CSF is used. If CSF is not running, when you try to
create a stash file, you get the following message, which does not identify the problem:
Verify OnDemand Password:
ARS1602E The stash file >/u/myuser/prodstash.stash< is invalid.
/usr/lpp/ars/V9R5M0/bin: >
To verify that CSF is up and running so that Content Manager OnDemand V9.5 can use it,
use the MODIFY command against ARSSOCKD.
On a system where ICSF is up and running, run the following command:

F ARSSOCKD,D,ICSF
ARS0438I 15.21.18 DISPLAY ICSF
CSFIQF RC=00, RSN=00000000, AES=3, FMID=HCR7780
On a system where CSF is not running, run the following command:

F ARSSOCKD,D,ICSF
ARS0438I 15.28.36 DISPLAY ICSF
CSFIQF RC=12, RSN=00000000, AES=0, FMID=N/A
6.6 Data encryption

Encrypting data is a way of providing security and protection to your Content Manager
OnDemand data.
6.6.1 Encrypting data at rest

Depending on how the database tables and archived data are stored, you can encrypt the
data by using either DB2 encryption or device encryption. The advantage of encrypting the
data is to make it “unintelligible” to unauthorized access even if it is accessed (as an extreme
example, the storage device is stolen). The cost of encrypting the data is increased processor
consumption and slower response time. This cost varies based on the device and encryption
methods that are used.
Backup data must always be encrypted because it is more susceptible to unauthorized

access.
6.6.2 Encrypting data in motion: Secure communications

Transport Layer Security (TLS) and Secure Sockets Layer (SSL) allow secure communication
between the Content Manager OnDemand server and the Content Manager OnDemand
clients. Since Content Manager OnDemand version 8.5, support for SSL and its successor,
TLS, is enabled for all transmissions between the Content Manager OnDemand servers and
clients. When this section mentions SSL, the same information applies to TLS, unless
otherwise noted.
SSL is the standard technology for creating secure connections between servers and clients.
The secure connection allows authentication and verification, and data encryption.

Authentication and verification allow both the client and server to verify that they are
communicating with the intended receiver. Data encryption prevents the packets of
information that are traveling through the network to be viewed by anyone who can access
the network.
During an SSL handshake, a client and server securely exchange digital signatures and
encryption keys by using a public-key algorithm (usually Rivest-Shamir-Adleman algorithm
(RSA)). The client and server establish a secure connection with this identity and key
information. After the client and server establish a secure session, they transmit the data to
each other, encrypting it with a symmetric algorithm, such as AES.
Trusted parties, which are called certificate authorities (CAs), issue digital certificates to verify
the identity of an entity, such as a client or a server. The digital certificate serves the following
purposes:
Verifies the identity of the owner
Makes the public key of the owner available
The IBM Global Security Kit (GSKit) provides libraries for data encryption and SSL
communication.
The GSKit package also installs the iKeyman key management utility (gsk7ikm), which you
can use to create key databases, public-private key pairs, and certificate requests. For
information about the iKeyman utility and the GSKCmd command-line interface, see the IBM
Developer Kit and Runtime Environment, iKeyman 8.0 User’s Guide at the following website:
http://download.boulder.ibm.com/ibmdl/pub/software/dw/jdk/security/60/iKeyman.8.Us
er.Guide.pdf
Note: Implementation of SSL is optional. The Content Manager OnDemand server can be
configured to listen on either a non-SSL port or an SSL port, or it can listen on both types
of ports. To implement SSL, click New server. In the Add a Server window that opens,
select Use Secure Sockets Layer. If your server does not support SSL, SSL is not used
even if you select this check box.
After a Content Manager OnDemand client (for example, the Content Manager OnDemand
Windows client, ARSDOC, or OnDemand Web Enablement Kit (ODWEK) Java API) is
configured to log on to a Content Manager OnDemand library server with SSL, all
communication to and from that client is performed by using SSL:
Between the client and the library server
Between the client and the object servers
To use SSL, it must be enabled on both the server and the client components of Content
Manager OnDemand.
Important considerations exist when you use SSL. We describe them in the following
subsections.

Separate port number
In addition to the standard (non-SSL) port, a separate port number is identified on the
Content Manager OnDemand server to support the secure connection. This separate port
number allows both SSL and non-SSL connections to operate concurrently. When a client
connects to the SSL port, it negotiates a connection through a handshake procedure during
which the client and server agree on the session parameters to use to maintain a secure
connection. Session keys are generated that allow the encryption and decryption of the data
that is sent between the client and server.
Processor consumption
SSL improves security by encrypting and decrypting data across the network. The encryption
and decryption occur at the application layer, which consumes the additional processing
cycles for both the sending and receiving systems. Therefore, consider using SSL only for
sessions where it is needed. Consider adding additional processor resources on the Content
Manager OnDemand server or clients to manage the increased overhead processing.
Digital certificates
With SSL, the identities of the parties are verified by using digital certificates. Digital
certificates have expiration dates. After a digital certificate expires, Content Manager
OnDemand will not be able to establish connections through SSL. Therefore, always be
aware and plan ahead to avoid expired certificates.
ODWEK
The support of SSL and ODWEK refers specifically to the transfer of data between ODWEK
and the Content Manager OnDemand servers and it does not imply a level of support from
the browser to ODWEK. The use of SSL from the browser to ODWEK was always allowed
and it does not require any support from ODWEK. It is the application and the web
developer’s responsibility to enable such support.
arsload
GSKIT is initialized one time for each arsload invocation. When you load multiple documents,
it is more effective to concatenate the documents (such as TIFF images) and generic index
files and load multiple documents at a time. Also, when you load multiple documents, use
arsload as the daemon.
6.7 Security exits

The Content Manager OnDemand security exits allow customers to implement their own
customized security methods based on their internal requirements and needs. You can use
the security exit to customize and enhance the security functions within a Content Manager
OnDemand system.

6.7.1 User security and permissions exits
Content Manager OnDemand provides a user exit so that you can implement your own user
exit program to identify and authenticate users that log on to the system. If you use only
Content Manager OnDemand internal security, the security exit is not needed.
You can use the security user exit to authenticate a user’s password. For example, you might
want to enforce a sort of password uniqueness or allow logons to occur only at specific times
in the day. You can also build a user proxy mechanism to allow users that are not already in
the Content Manager OnDemand user database to access the system.
The permissions exit is called during login if the permissions exit is turned on for folder and
application groups. It is also called during a search when the permissions exit is turned on for
an SQL query string or document.
Use the user security exit and the permissions exit to augment the security-related
processing of the following activities or events:
User authentication (checking user security):
– Log on.
– Change a password.
– Add a user ID.
– Delete a user ID.
Resource authorization (checking user permissions):
– Access to a Content Manager OnDemand folder.
– Access to a Content Manager OnDemand application group.
– Restrict access to specific documents.
– Control the SQL search criteria that are used for searching folders.
The user-written exit routine (or set of exit routines) can interact with another security system
to determine whether the activity is allowed or disallowed.
Important: When you implement your own security user exit program, you bypass the
logon verification processing that is built into the base Content Manager OnDemand
product. We advise caution when you bypass the Content Manager OnDemand user and
password restrictions. The security of the system can easily be subverted by malicious or
defective code. Only use code that you trust.
When you set the user security exit, set the following parameters:
Set the Maximum Password Age parameter to the value that best matches the main logic
of the user exit program (permit/deny). The Maximum Password Age parameter is set on
the System Parameters dialog box, which is accessed by using the Administrator Client.
Set the Maximum Password Age parameter to Never Expires so that users are not
prompted to change their passwords. If you are restricting the change password function
to a limited number of users, this setting is probably the best overall setting because most
users are never automatically prompted to change their password.

IBM Content Manager OnDemand and FileNet-2

Uploaded by

Copyright:

Available Formats

IBM Content Manager OnDemand and FileNet-2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IBM Content Manager OnDemand and FileNet-2

Uploaded by

Copyright:

Available Formats

Name window

Figure 3-21 Specifying names

Wizard complete window

3.2 User and group administration

66 IBM Content Manager OnDemand Guide

The decision about whether to use a centralized or a decentralized administration model is

In this section, we describe different types of users, followed by a description of a

3.2.1 User types, authorities, and functions

Object type model

Application Group/Folder/Cabinet Administrator

User Administrator with Create Groups Authority

Storage Sets System Printers

Figure 3-23 Decentralized system administration - object type model

68 IBM Content Manager OnDemand Guide

System administrator Creates report administrators.

Application group, folder, and Creates and maintains application groups.

User administrator with Create Creates and maintains users.

Object owner model

User with Create Application Groups, Create Folders, and

User Administrator with Create Groups Authority

User with Create Application Groups, Create Folders, and

User Administrator with Create Groups Authority

Storage Sets System Printers

Figure 3-24 Decentralized system administration - object owner model

70 IBM Content Manager OnDemand Guide

Report administrator Creates and maintains application groups.

User administrator Creates and maintains users.

Table 3-3 Administration guidelines

Data from several independent sources is maintained on Decentralized system administration

In this section, we describe the following items:

Benefits of using the XML batch program

3.3.1 Using the XML Batch Administration program

To use the program, you must have the following files:

72 IBM Content Manager OnDemand Guide

Example 3-1 Sample XML input file for exporting users

<user name="SAMPLEUSER0" />

Example 3-2 Input file to update user - updateUser.xml

<user name="User1" description="User1" createUsersAuth="Yes" >

The following command updates user User1:

3.3.2 Special features of the XML batch program

74 IBM Content Manager OnDemand Guide

Example 3-3 Input file updateag.xml

Example 3-4 shows the output from the previous command.

Example 3-5 Output of updating the user without using task=“update”

76 IBM Content Manager OnDemand Guide

Chapter 4. Database structure

In this chapter, we cover the following topics:

© Copyright IBM Corp. 2003, 2015. All rights reserved. 77

Table 4-1 Content Manager OnDemand system control tables

78 IBM Content Manager OnDemand Guide

ARSLOAD Load table The load_ID table

ARSRES Resources table One row for each resource ID

ARSSYS System parameters One row for the entire system

Chapter 4. Database structure 79

4.2 Main data table structures

Table 4-2 ARSSEG table structure

agid Application group ID

table_name Application group segment table name