Migration Processes

Now that you have reviewed the basic SMS concepts, it is time to have a look at the SMS internals (see Figure 30).

Figure 30. SMS Processes

When an object is initially stored in the system (either with a scanner or with some import program), the object server gets the object directly from the client and writes it into the staging area. The staging area is a critical component of

the object server. It is defined at installation time, and it resides on DASD.

When first stored in the staging area, the object/file has a file attribute of R for read only to prevent inadvertent deletion or changing of the file. The file name assigned to the object is:

collection ID as five digit string + object name

The object name for objects created by VisualInfo is dynamically generated by the library server and not stored in a table in the library server. The name format is:

first eight characters from itemid in SBTITEMS or SBTPARTS +

″.″ +

last eight characters from itemid +

REPTYPE field from SBTPARTS (usually

FRN$NULL) +

″ .

P

part number as hex number, from PARTNUM in SBTPARTS +

″ .

V

version number, from VERSIONNUM in SBTPARTS

SBTPARTS in a library server database table (see VisualInfo Programming Reference Volume 2 for a description of all the library and object server tables).

The current release of VisualInfo does not support versioning, so the last characters would be “.V0” or “.V1.” Here is an example of one of those filenames:

00001.RYW0H2EF.QNH5JNX1.FRN$NULL.P1.V0

At this time a row is added to the BASE_OBJECTS table (an object server database table) for this newly added object, and the row will contain:

• The object′s name (key field)

• The collection ID

• An actiondate of 12/31/9999 (varies according to the current date and retention period)

• A null filename

• A create date and reference date of the time of storage

• A status of S meaning that the object is currently in the staging area

• A path of 0

• Management class and storage class IDs corresponding to the object′s collection

• Dates for each class indicating when that object first entered that class

The management of the staging area is controlled by the destager process, which moves new and modified objects to their first SMS storage class, and the purger process, which can delete objects that have been destaged. Parameters that specify the size of the staging area, the time between startup of the

destager and purger processes, and the percentage of used space to reclaim, are set through the system administration application.

When the destager runs, the file is renamed and copied to the first storage class defined in the corresponding management class. You have two possibilities on the NT and AIX platforms (OS/2 has others):

1. You can copy the file to a VisualInfo-managed DASD volume. In this case the file is stored in an area named LBOSDATA (ubosdata for AIX) which

resides on a previously defined SMS logical drive for NT or OS/2 (filesystem for AIX). It is copied to a subdirectory within LBOSDATA which corresponds to the object′s collection ID and “bucket” path. The OBJ_PATH field in the BASE_OBJECTS table corresponds to the bucket in which this object resides.

The number of buckets a volume can have is in the BASE_VOLUMES field named VOL_NUMBUCKETS. This tells how many subdirectories underneath the collection ID subdirectory to divide the data among. This field cannot be updated through the SMS system administration program and has a default value of 1.

Hint

To update this field, connect to the object server database and execute this SQL command:

UPDATE BASE_VOLUMES SET VOL_NUMBUCKETS=x WHERE VOL_VOLUMEID=n

where “x” is the new number of buckets, and “n” is the ID of the volume.

Therefore, a file which is stored on a volume whose collection ID is 6 and for which the volume has a numbucket of 2 may be referenced like this:

E:LBOSDATA0000601filename.xxx, where the 01 refers to the second bucket (00 is the first) and E is the drive letter for the referenced volume.

2. You can copy the file to an ADSM-managed volume. In this case the object server starts a session with ADSM, sends the object, and closes the session (see Chapter 3, “VisualInfo and the ADSM Interface” on page 49).

Before copying the file to a VisualInfo-managed DASD volume, the destager checks for free space against the file′s size. If there is not enough space, an error message is sent. The file may be written to another volume in the storage group. But when copying to an ADSM-managed volume, it does not check for free space because it considers the ADSM volumes as infinite in size.

At this time the object′s row in the BASE_OBJECTS table is updated to reflect the new volumeid, filename, path and actiondate. Its status will now change from S to A, meaning the object has been archived. The archive filename on the volume is composed of random characters unrelated to the object name. You cannot tell by looking at the file what object it contains, as there is no

VisualInfo-supplied header on the object. The only mapping is through the BASE_OBJECTS table. The OBJ_ACTIONDATE is updated to today′s date plus the MGP_SINCEENTER value for this storage class within this management class′ transition (BASE_MGTTRANSITION table).

The file which is in the staging area is now eligible for purging. The destager will set the file attribute accordingly (delete the rw attribute), so that when the purger runs the file can be deleted from the staging area. The purger deletes objects according to their last reference date, so objects most recently used are less likely to be deleted.

The migrator process moves the objects from one storage class to another according to the policy specified in the management class. When the migrator runs, it checks the OBJ_ACTIONDATE field and if this date is equal or less that today′s date, it moves the object to the next storage class. At this time the object′s row in the BASE_OBJECTS table is updated to reflect the new volumeid, filename, path and actiondate.

If the new storage class has a retention period of FOREVER, then the

OBJ_ACTIONDATE is updated to 12/31/9999. This means that if you update the management class and add a new storage class, this object will never be migrated (or at least not for 8,000 years).

The migrator deletes objects that have been archived. A delete (discard) request from an application does not cause the immediate deletion of an archived object. The object server marks the object as discarded

(OBJ_STATUS=′D′) and deletes any staged copy of the file. Nobody can

retrieve the object once it has been marked as discarded. On the next migration cycle, the migrator will delete the actual object and the row from

BASE_OBJECTS. This delayed action means the delete request does not have to wait to mount the volume with the object.

The purger and destager wake up according to their cycle times. They go to sleep for the cycle time after they finish running. The cycle time is not added to the time they last ran. For example, if the destager ran at 1:00pm for 10 minutes and had a cycle time in BASE_CNTL of 15 minutes, it would run again at 1:25pm, not 1:15pm. VisualInfo does not support exact scheduling of the purger and destager. However, it does support exact scheduling for the migrator.