Chapter 6. Media Specific Processes (MSPs)

A file is migrated from online disk to offline media by a media-specific process (MSP). There are three types of MSPs:

The following sections provide a general description of MSP operation.

The Tape MSP

The tape MSP consists of three programs: dmatmsp, dmatwc, and dmatrc.

The DMF daemon executes dmatmsp as a child process. The MSP communicates with the daemon through a pair of unnamed pipes. In turn, dmatmsp executes dmatwc (the write child) to write data to tape and dmatrc (the read child) to read data from tape.

The dmatmsp maintains two types of records in its database:

  • CAT records, which contain information about the files the MSP maintains

  • VOL records, which contain information about the media the MSP uses

The database is not a text file and cannot be updated by standard utility programs. Detailed information about the database and its associated utilities is provided in “CAT Database Records”, and “VOL Database Records”.

The tape MSP provides a mechanism for copying active data from volumes that contain largely obsolete data to volumes that contain mostly active data. This process is referred to as volume merging or compression. Data on MSP volumes becomes obsolete when users delete or modify their files. Volume merging can be configured to occur automatically (see “Configuring Tape MSP Maintenance Tasks” in Chapter 2). It can also be triggered by marking MSP volumes as sparse with the dmvoladm(8) command.

The tape MSP provides two utilities that read MSP volumes directly:

  • dmatread(8), which copies all or part of a migrated file to disk

  • dmatsnf(8), which audits and verifies MSP volumes

Tape MSP Directories

Each instance of the tape MSP needs three types of directories, one for each of the following:

  • Databases

  • Database journal files

  • Log files

Sites define the location of these directories by editing the base object configuration file parameters HOME_DIR, JOURNAL_DIR, and SPOOL_DIR, whose values are referred to as HOME_DIR, JOURNAL_DIR, and SPOOL_DIR in this document. A given instance of the tape MSP creates a subdirectory named after itself in each of these three directories.

For example, if an instance of the tape MSP is called cart1, its database files reside in directory HOME_DIR/cart1. If another instance of the tape MSP is called cart2, its database files reside in HOME_DIR/cart2.

Similarly, MSP cart1 stores its journal files in directory JOURNAL_DIR/cart1 and its log files and other working files in SPOOL_DIR/cart1.

Media Concepts

The tape MSP takes full advantage of the capabilities of modern tape devices, including data compression and fast media positioning. To accommodate these capabilities and to provide recovery from surface or other media defects, dmatmsp uses a number of structural concepts built on top of traditional tape structure.

The components are as follows:

  • The block is the basic structural component of most tape technologies. It is the physical unit of I/O to and from the media. The optimal block size varies with the device type. For example, the default block size for a 3480/3490 device is 65,536 bytes.

  • A chunk is as much or as little of a user file as fits on the remainder of the tape (see Figure 6-1). Thus, every migrated file has at least one, and sometimes many, chunks. Such a concept is necessary because the capacity of a volume is unknown until written, both because of natural variation in the medium itself and because the effect of data compression varies with the data contents.

  • A zone is a logical block containing several physical blocks ending with a tape mark. A zone has a target size that is configurable by media type. The default zone target size is 50 MB.

    The MSP writes chunks into the zone until one of three conditions occurs:

    • The zone size is exceeded

    • The MSP exhausts chunks to write

    • The end of tape is encountered

    Thus, the actual zone size can vary from well below the target size to the entire tape volume. A zone never spans physical volumes.

    The zone plays several roles:

    • The zone size is the amount of data that triggers dmatmsp to start a process to write files to tape.

    • The MSP records the position of the beginning of each zone in its database so that it can use fast hardware positioning functions to return there to restore the chunks in that zone.

    • When a tape volume develops a defect, the data loss usually will be restricted to the zone.

    Because getting the tape position and writing a tape mark can be very costly, the concept of a zone and the target size provides a way to control the trade offs between write performance, safety, and recall speed.

Figure 6-1 illustrates the way files are distributed over chunks, zones, and volumes, depending upon the file size. The tape with volume serial number (VSN) VOL001 has two zones and contains six files and part of a seventh. The tapes with VSNs VOL002 and VOL003 contain the rest of file g. Notice that on VOL001 file g is associated with chunk 7, while on the other two tapes it is associated with chunk 1. File g has three VSNs associated with it, and each tape associates the file with a chunk and zone unique to that tape.

Figure 6-1. Media Concepts


CAT Database Records

Records in the tape catalog (CAT), tpcrdm, store the location of each file chunk in terms of its volume, zone, and chunk number. The key for these records is the file's bit file identifier (bfid).

You do not explicitly create CAT records in the database. They are created with files migrate.

The CAT portion of the MSP database consists of three files:

  • tpcrdm.dat, which contains the data records themselves

  • tpcrdm.key1.keys and tpcrdm.key2.keys, which contain the indexes to those records

The database definition file (in the same directory) that describes these files and their record structure is named atmsp_db.dbd.

All files are non-ASCII and cannot be maintained by standard utility programs. The dmcatadm command provides facilities to create, query, and modify CAT database records (see “dmcatadm Command”).


Note:: The ability to create or modify CAT database records with dmcatadm is provided primarily for testing purposes. In the normal course of operations, you would never use this capability.


VOL Database Records

Records in the tape volume (VOL) portion of the MSP database, tpvrdb, contain information about each volume that exists in the pool of tapes to be used by dmatmsp. These records are indexed by the volume serial number (VSN) of each volume and contain such information as the volume's type, estimated capacity, label type, and a number of flags indicating the state of the volume. Unlike the CAT records, you must create the VOL records in the database before using dmatmsp for the first time.

The VOL portion of the MSP database consists of two files:

  • tpvrdm.dat, which contains the volume records themselves

  • tpvrdm.vsn.keys, which contains the indexes to the records

The database definition file (in the same directory) that describes these files and their record structure is named atmsp_db.dbd.

Both files contain binary data and require special maintenance utilities. The dmvoladm command, described in more detail in “dmvoladm Command”, provides facilities to create, query, and modify VOL records in the database. Additional database maintenance utilities are described in “Database Recovery” in Chapter 7.


Note:: If you have more than one instance of the tape MSP, you must ensure that the volume sets for each MSP are mutually exclusive.


Tape MSP Journals

Each instance of dmatmsp protects its database by recording every transaction in a journal file. The journal file path names have the following format:

JOURNAL_DIR/msp_name/atmsp_db.yyyymmdd[.hhmmss]

The MSP creates journal files automatically.

Existing journal files are closed and new ones created in two circumstances:

  • When the first transaction after midnight occurs

  • When the journal file reaches the size defined by the JOURNAL_SIZE configuration parameter

When the first transaction after midnight occurs, the existing open journal file is closed and the suffix .235959 is appended to the current file name no matter what the time (or date) of closing. The closed file represents the last (or only) transaction log of the date yyyymmdd. A new journal file with the current date is then created.

When the journal file reaches JOURNAL_SIZE, the file is closed and the suffix .hhmmss is added to the name; hh, mm, and ss represent the hour, minute, and second of file closing. A new journal file with the same date but no time is then created.

For example, the following shows the contents of a JOURNAL_DIR/msp_name directory on 15 June 1998:

atmsp_db.19980527.235959  atmsp_db.19980606.235959
atmsp_db.19980528.235959  atmsp_db.19980607.235959
atmsp_db.19980529.235959  atmsp_db.19980608.235959
atmsp_db.19980530.235959  atmsp_db.19980609.235959
atmsp_db.19980531.235959  atmsp_db.19980610.235959
atmsp_db.19980601.235959  atmsp_db.19980611.235959
atmsp_db.19980602.235959  atmsp_db.19980612.235959
atmsp_db.19980603.235959  atmsp_db.19980613.235959
atmsp_db.19980604.235959  atmsp_db.19980614.235959
atmsp_db.19980605.235959  atmsp_db.19980615

For every date on which database transactions occurred, there will exist a file with that date and the suffix .235959, with the exception of an existing open journal file. Some dates may have additional files because the transaction log reached JOURNAL_SIZE at a specified time and the file was closed.

You can configure daemon_tasks parameters to remove old journal files (using the run_remove_journals.sh task and the JOURNAL_RETENTION parameter. For more information, see “Configuring Daemon Maintenance Tasks” in Chapter 2.

If an MSP database becomes corrupt, recovery consists of applying the journal files to a backup copy of the database.

Tape MSP Logs

All DMF MSPs maintain log files named msplog.yyyymmdd in the MSP spool directory which, by default, is SPOOL_DIR/mspname. SPOOL_DIR is configured in the base object of the configuration file; mspname is the name of the MSP in the daemon object of the configuration file; yyyymmdd is the current year, month, and day.

These log files are distinct from the logs maintained by the DMF daemon; however, some of the messages that occur in the daemon log are responses that the tape MSP generates. The content of the log is controlled by the MESSAGE_LEVEL configuration parameter. For a description of the levels of logging available, see the dmf_config(5) man page.

The msplog.yyyymmdd file is the primary log for the tape MSP and contains most of the messages. This file is written by dmatmsp, dmatrc, and dmatwc. A new msplog.yyyymmdd is created for each day.

This section describes informational statistics provided by the tape log files. These messages appear in the SPOOL_DIR/msp_name/msplog.yymmdd files. Timing information provided (such as MB transferred per second) should not be used as an accurate benchmark of actual data transfer rates. This information is provided for monitoring DMF and should only be used in comparison to similar data provided by DMF. Text in all uppercase references a parameter defined in the DMF configuration file. You can reference the comments in the sample configuration file or in the dmf_config(5) man page for a more detailed definition of these parameters.


Note: Because the MSP will continue to create log files and journal files without limit, you must remove obsolete files periodically by configuring the run_remove_logs.sh and run_remove_journals.sh tasks in the configuration file, as described in “Configuring Daemon Maintenance Tasks” in Chapter 2.


Example 6-1. Tape MSP Statistics Messages

The following is an example of advanced tape MSP statistics messages taken from an msplog.yyyymmdd file. These messages are automatically issued by the MSP every 5 minutes.

02:02:00-I 27082-dmatmsp stats: children=5/5/8, btp=2818446/100000000/0, wc=1/8, cwc=47952
02:02:00-I 27082-dmatmsp stats: data put=48480.521 mb, data recalled= 93.446 mb
02:02:00-I 27082-dmatmsp stats:      dm_put -      0  65179      0     77
02:02:00-I 27082-dmatmsp stats:      dm_get -      2  23706    743      5
02:02:00-I 27082-dmatmsp stats:   dm_delete -      0  27459      0      0
02:02:00-I 27082-dmatmsp stats:   dm_cancel -      0     82     12      0
02:02:00-I 27082-dmatmsp stats: dm_flushall -      0   1820      0      0
02:02:00-I 27082-dmatmsp stats: dm_snapshot -      0    120      0      0
02:02:00-I 27082-dmatmsp stats:    dm_merge -     33   5967      0      0
02:02:00-I 27082-dmatmsp stats: mc=8, ms=1000000000, mu=74854430, sm=0

The information provided by these entries is defined as follows:

  • The first line contains the following information:

    • children=5/5/8 represents the total child processes (5), the active child processes (5), and the configured value of CHILD_MAXIMUM (8)

    • btp=2818446/100000000/0 represents the bytes queued for putting (2818446), the threshold at which to start the next put child (100,000,000), and the bytes assigned to socket I/O (0)

    • wc=1/8 represents the active write child processes (1) and the configured value of MAX_PUT_CHILDREN (8)

    • cwc=47952 represents the process ID of the current write child (that is, the write child which is accepting data to write)

  • The next six lines provide statistics for each type of MSP request. Statistics information is provided only for requests that have been issued since the MSP was started. These lines have the following format:

    request_name      active      successful      errors      canceled

    active represents the number of requests not yet completed; successful represents the number of successfully completed requests; error represents the number of requests that completed with errors; canceled represents the number of canceled requests.

  • The last line provides the following information:

    • mc is the configured value for MERGE_CUTOFF, the cutoff to stop scheduling tapes for merging (8)

    • ms is the configured value for CACHE_SPACE, the merge cache space available (1 Gbyte)

    • mu is the merge cache space used (74854430)

    • sm is the number of socket merge children (0)

The tape MSP write child (dmatwc) and read child (dmatrc) also produce statistics messages in the MSP log file. These messages contain timing statistics whose format changes from release to release, and they are not documented in this manual.

Volume Merging

When users delete or modify their migrated files, the copy on tape becomes obsolete. Over time, some volumes will become entirely empty and can be reused. However, most volumes experience a gradual increase in the ratio of obsolete data to active data; such volumes are said to be sparsely populated or simply sparse. To reclaim the unused space on these volumes, DMF provides a volume merge facility, which copies the active data from several sparse volumes to a new volume, thus freeing the sparse volumes for reuse. Volume merging can be configured to occur automatically by using the run_merge_tapes.sh task (see “Configuring Tape MSP Maintenance Tasks” in Chapter 2).

Volume merging can also be done manually. dmatmsp performs merge operations whenever sparse volumes and the necessary resources exist at the same time. Use the dmvoladm select directive to mark MSP volumes as sparse. (The select directive is described in “dmvoladm Command”.) Because the merge processing occurs simultaneously with other DMF activities, it is easiest to configure DMF to automatically perform merges at night or during other periods of relatively low activity.

The dmatmsp can perform volume-to-volume merging. Volume-to-volume merging is accomplished by moving data across a socket connection between the MSP tape read-child and the MSP tape write-child. The benefit of using a socket to transfer data between volumes is that you do not have to reserve disk space. The drawback to using a socket for data transfer is the cost of linking the process that performs the read with the process that performs the write.

In busy environments that have heavy contention for tape drives, the close coupling between the socket's tape reader and tape writer can be costly, especially when short files are being transferred. For large files, the overhead and possible delays in waiting for both tapes to be mounted is small compared to the benefit of rapid transfer and zero impact on free disk space. For this reason, you can move small files through a disk cache and big files through a socket. This process is mediated by the following configuration parameters:

Parameter

Description

CACHE_SPACE

Specifies the amount of disk space that will be used to temporarily store chunks during a merge operation.

CACHE_DIR

Specifies the directory into which the MSP will store chunks while merging them from sparse tapes. If CACHE_DIR is not specified, TMP_DIR is used.

MAX_CACHE_FILE

Specifies the largest chunk that will be stored temporarily on disk during a merge operation.

MERGE_CUTOFF

Specifies the number of child processes after which the MSP will stop scheduling tapes for merging. This number is the sum of the active and queued children generated from gets, puts, and merges.

Using a small amount of disk space to hold small chunks can have a significant impact on the total time required to perform merges. The default configuration options are set to move 100% of merge data across sockets.


Note:: It is important to avoid volume merging on more than one MSP simultaneously if the two MSPs share a tape device. If you initiate a merge process on more than one MSP on the same device at the same time (either by entering the same time in the dmf_config configuration file or by triggering the process manually), both processes will compete for tape transports. When a limited number of tape transports are available, a deadlock can occur. If you chose not to configure DMF to perform merges automatically by configuring the run_tape_merge.sh task, ensure that your cron jobs that automatically initiate volume merging refrain from initiating a second merge process until after all previously initiated merges are complete. You can accomplish this by using the dmvoladm command within the cron job to check for tapes that have the hsparse flag:
tapes=$(dmvoladm -m msp1 -c "count hsparse")
if [[ -z "$tapes" ]]; then
        # start merge on msp2
        dmvoladm -m msp2 -c "select hfull threshold<=30"
fi



dmcatadm Command

The dmcatadm(8) command provides maintenance services for CAT records in the MSP database.

When you are inside the dmcatadm interface (that is, when you see the adm command_number > prompt), the command has a 30-minute timeout associated with it. If you do not enter a response within 30 minutes of the prompt having been displayed, the dmcatadm session terminates with a descriptive message. This behavior on all the database administrative commands limits the amount of time that an administrator can lock the daemon and MSP databases from updates.


Note:: Most of these facilities, especially the ability to create and modify CAT database records, are intended primarily for testing purposes.


dmcatadm Directives

The dmcatadm command executes directives from stdin or from the command line when you use the -c option. All directives start with a directive name followed by one or more parameters. Parameters may be positional or keyword-value pairs, depending on the command. White space separates the directive name, keywords, and values.

The dmcatadm directives are as follows:

Directive 

Description

count 

Displays the number of records that match the expression provided.

create 

Creates a CAT record.

delete 

Deletes an existing CAT record.

dump 

Prints the specified CAT records to standard out in ASCII; each database field is separated by the pipe character (|).

help 

Displays help.

list 

Shows the fields of selected CAT records. You may specify which fields are shown.

load 

Applies records to the MSP database obtained from running the dump directive.

quit 

Stops program execution after flushing any changed database records to disk. The abbreviation q and the string exit produce the same effect.

set 

Specifies the fields to be displayed in subsequent list directives.

update 

Modifies an existing CAT record.

verify 

Verifies the MSP database against the dmdaemon database.

The first parameter of most directives specifies the database records to manipulate, and the remaining parameters are keyword-value pairs.

The syntax for the dmcatadm directives is summarized as follows:

count selection [limit]
create key field...
delete selection [limit]
dump selection [limit]
help
list selection [limit] [format]
load filename
quit (or q or exit)
set [format]
update selection [limit] to fields...
verify selection [entries] [mspname] [limit]

The value for key may be a bit file identifier (bfid) designator in the form of a hexadecimal number.

The value for selection can be one of the following:

  • A key or range of keys in the form key [-] [key]. key- specifies all records starting with key, and -key specifies all records up to key.

  • The keyword all

  • A period (.), which recalls the previous selection

  • An expression involving any of the above, field value comparisons, and, or, or parentheses.

A field value comparison may use < (less than), > (greater than), = (equal to), <= (less than or equal to), or >= (greater than or equal to) to compare a field keyword to an appropriate value.

The syntax for selection is as follows:

selection       ::=   or-expr
or-expr        ::=   and-expr [ or or-expr  ]
and-expr       ::=  nested-expr [ and and-expr  ]
nested-expr     ::=   comparison | ( expression )
comparison     ::=   key-range | field-keyword op  field-value
op           ::=   < | > | = | >= | <=
key-range      ::=   key [ - key] | [key - [key]] | key-macro
key-macro     ::=   all
field-keyword   ::=   name or abbreviation of the record field
field-value     ::=   appropriate value for the field
key          ::=   character representation of the record key

Thus valid selections could be any of the following:

1510-1514
10000000000-
-15138
all
chunkoffset>0
chunknumber>0 and writeage<5d
. recordorder data
vsn=S07638

dmcatadm Field Keywords

The field keywords listed below specify new values for fields. Some of the keywords are valid only if you also specify the -u option.

Keyword 

Description

chunkdata (cd) 

Specifies the actual number of bytes written to tape by the MSP for the chunk. In the case of sparse files, this field will be smaller than chunklength. This is valid only in unsafe (-u) mode.

chunklength (cl) 

The size of the chunk in bytes; an integer. This is valid only in unsafe (-u) mode.

chunknumber (cn) 

The ordinal of the chunk on its volume. For example, 1 if the chunk is the first chunk on the volume, 2 if it is the second, and so on. Valid only as part of selection.

chunkoffset (co) 

The byte offset within the file where the chunk begins; an integer. For example, the first chunk of a file has chunkoffset 0. If that first chunk is 1,000,000 bytes long, the second chunk would have chunkoffset 1000000. This is valid only in unsafe (-u) mode.

filesize (fs) 

The original file size in bytes, an integer. This is valid only in unsafe (-u) mode.

flags (fl) 

Not yet used by DMF.

readage (ra) 

The date and time when the chunk was last read; the same as readdate, except specified as age.

readcount (rc) 

The number of times the chunk has been recalled to disk; an integer.

readdate (rd) 

The date and time when the chunk was last read, an integer that reflects raw UNIX time.

vsn (v) 

The volume serial number(s); a list of one or more 6-character alphanumeric volume serial numbers separated by colons (:).

writeage (wa) 

The date and time when the chunk was written; the same as writedate, except specified as age. This is valid only in unsafe (-u) mode.

writedate(wd) 

The date and time when the chunk was written, an integer that reflects raw UNIX time. This is valid only in unsafe (-u) mode.

zoneblockid (zb) 

Allows just the block ID portion of the zonepos to be displayed, returned, or changed. This is valid only in unsafe (-u) mode.

zonenumber (zn) 

Allows just the zone number portion of the zonepos to be displayed, returned, or changed. This is valid only in unsafe (-u) mode.

zonepos (zp) 

The physical address of the zone on the volume, expressed in the form integer/hexinteger, designating a zone number and block ID. A value of zero is used for hexinteger if no block ID is known. integer is the same as zonenumber, and hexinteger is the same as zoneblockid. This is valid only in unsafe (-u) mode.

The date field keywords (readdate and writedate) have a value of either now or raw UNIX time (seconds since January 1, 1970). These keywords display their value as raw UNIX time. The value comparison > used with the date keywords means newer than the value given. For example, >36000 is newer than 10AM on January 1, 1970, and >852081200 is newer than 10AM on January 1, 1997.

The age field keywords (readage and writeage) let you express time as age, a string in a form such as 8w12d7h16m20s (meaning 8 weeks, 12 days, 7 hours, 16 minutes, and 20 seconds old). The age keywords display their value as an integer followed by w, d, h, m, or s (weeks, days, hours, minutes, and seconds, respectively). The comparison > used with the age keywords means older than the value given (that is, >5d is older than 5 days).

The limit keywords limit the records acted upon:

Keyword 

Description

recordlimit (rl) 

Limits the number of records acted upon to the value that you specify; an integer.

recordorder (ro) 

Specifies the order that records are scanned; may be key, vsn, or data. key specifies that records are scanned in ascending order of the chunk key. vsn specifies that records are scanned in ascending order of the chunk VSN. data specifies that records are scanned in the order in which they are stored in the database, which is fastest but essentially unordered.

The following keywords specify files of daemon database entries:

Keyword 

Description

entries (e) 

Specifies a file of daemon database entries; a string.

mspname (mn) 

Specifies the name of the MSP associated with the record; a string.

The format keyword selects a format to use for the display. If, for example, you want to display fields in a different order than the default or want to include fields that are not included in the default display, you specify them with the format keyword. Values for format can be default, keyword, or a list of field keywords enclosed in quotation marks.

For any field that takes a byte count, you may append the letter k, m, or g (in either uppercase or lowercase) to the integer to indicate that the value is to be multiplied by one thousand, one million, or one billion, respectively.

For information about the role of the dmcatadm(8) command in database recovery, see “Database Recovery” in Chapter 7.

Example 6-2. dmcatadm list directive

The following is sample output from the dmcatadm list directive. The file with key 3273d5420001e244 has two chunks because it spans two physical tape volumes; the first chunk contains bytes 0 through 24821759, and the second chunk bytes 24821760 (the CHUNK OFFSET) to the end of the file.

adm 3>list 3273d5420001e242- recordlimit 10
                                 FILE  WRITE       CHUNK       CHUNK CHUNK
                      KEY        SIZE    AGE      OFFSET      LENGTH   NUM VSN
---------------------------------------------------------------------------------
         3273d5420001e242    77863935    61d           0    77863935    13 S12940
         3273d5420001e244    48365568    61d           0    24821760   168 S12936
         3273d5420001e244    48365568    61d    24821760    23543808     1 S12945
         3273d5420001e245    51019776    61d           0    51019776     2 S12945
         3273d5420001e246    45629440    61d           0    45629440    59 S12938
         3273d5420001e247    35586048    61d           0    35586048    60 S12938
         3273d5420001e248     9568256    61d           0     9568256     3 S12944
         3273d5420001e249    14221312    61d           0    14221312     4 S12944
         3273d5420001e24a      458752    61d           0      458752     5 S12944
         3273d5420001e24b    14155776    61d           0    14155776     6 S12944

dmcatadm Text Field Order

The text field order for chunk records generated by the dmdump(8), dmdumpj(8), and the dump directive in dmcatadm is listed below. This is the format expected by the load directives in dmcatadm:

  1. C (indicates the chunk record type)

  2. bfid (hexadecimal digits)

  3. filesize

  4. writedata

  5. readdate

  6. readcount

  7. chunkoffset

  8. chunklength

  9. chunkdata

  10. chunknumber

  11. flags (in octal)

  12. zoneposition (zonenumber/zoneblockid) (in hexadecimal)

  13. vsn

dmvoladm Command

The dmvoladm(8) command provides maintenance services for VOL records in the MSP database. In addition to the creation and modification of volume records, dmvoladm has an important role in the recovery of VOL records from a database checkpoint and is the mechanism that triggers volume merge activity.

When you are inside the dmvoladm interface (that is, when you see the adm command_number > prompt), the command has a 30-minute timeout associated with it. If you do not enter a response within 30 minutes of the prompt having been displayed, the dmvoladm session terminates with a descriptive message. This behavior on all the database administrative commands limits the amount of time that an administrator can lock the daemon and MSP databases from updates.

dmvoladm Directives

The dmvoladm command executes directives from stdin or from the command line when you use the -c option. The syntax is the same as for dmcatadm: a directive name followed by parameters or paired keywords and values, all separated by white space. dmvoladm directives follow:

Directive 

Description

count 

Displays the number of records that match the expression provided.

create 

Creates a VOL record.

delete 

Deletes an existing VOL record.

dump 

Prints the specified VOL records to standard output in ASCII. Each database field is separated by the pipe character (|).

help 

Displays help.

list 

Shows the fields of selected VOL records. You may specify which fields are shown.

load 

Applies VOL records to the database obtained from running the dump directive.

quit 

Stops program execution after flushing any changed database records to disk. The abbreviation q and the string exit produce the same effect.

repair 

Causes dmvoladm to adjust the usage information for specified volumes based on CAT data in the database. This directive is valid only in unsafe (-u) mode.

select 

Marks selected volumes as being sparse. Equivalent to update expression to hsparse on.

set 

Specifies the fields to be shown in subsequent list directives.

update 

Modifies an existing VOL record.

verify 

Verifies the MSP databases against the dmdaemon databases.

The syntax for the dmvoladm directives is summarized as follows:

count selection
create vsnlist [field...]
delete selection [limit...]
dump selection [limit...]
help
list selection [limit...] [format]
load filename
quit (or q, or exit
repair selection
select selection [limit...]
set [format]
update selection [limit...] to field
verify selection

The value for vsnlist may be a single 6-character volume serial number (VSN) or a range of VSNs separated by the hyphen (-) character. A VSN string may consists entirely of letters, entirely of digits, or may be a series of letters followed by digits. In a range of VSNs, the first must be lexically less than the second.

The value for selection may be one of the following:

  • A vsnlist or range of VSNs in the form vsn[-vsn]. vsn- specifies all records starting with vsn, and -vsn specifies all records up to vsn.

  • A period (.), which recalls the previous selection

  • The name of one of the flags in the keyword list that follows in this section.

  • One of the words all, used, empty, or partial or any of the hflags, whose meanings are as follows:

    Flag 

    Description

    all 

    Specifies all volumes in the database

    empty 

    Specifies all volumes in which data written is 0

    partial 

    Specifies used volumes in which hfull is off

    used 

    Specifies all volumes in which data written is not 0

The syntax for selection is as follows:

selection       ::=   or-expr
or-expr        ::=   and-expr [ or or-expr  ]
and-expr       ::=    nested-expr [ and and-expr  ]
nested-expr     ::=   comparison | ( expression )
comparison     ::=   vsnlist | field-keyword op  field-value
op           ::=   < | > | = | >= | <=
key-range      ::=   vsn [ - vsn] | [vsn - [vsn]] | key-macro
key-macro      ::=   all | empty | used | partial | flag(s)
field-keyword   ::=   name or abbreviation of the record field
field-value     ::=   appropriate value for the field
vsnlist        ::=   character representation of the volume serial number

Thus valid selections could be any of the following:

tape01-tape02
tape50-
-vsn900
all
herr or hbadmnt
used and hfull=off
datawritten>0 and hfull=off
. and eotchunk>3000 and (eotchunk<3500 or hfree=on)
hfull and threshold<30

dmvoladm Field and Format Keywords

The field keywords specify new values for fields:

Keyword 

Description

blocksize (bs) 

Specifies the data block size in bytes when the tape was first written; an integer. The default is 65,536. This keyword is used only when mounting tapes with existing valid data. When an empty tape is first written, the MSP uses the default value for the tape type, unless it is overridden by a value in the BLOCK_SIZE parameter for the tape device in the DMF configuration file. This is valid only in unsafe (-u) mode.

chunksleft (cl) 

Specifies the number of active chunks on the volume; an integer. This is valid only in unsafe (-u) mode.

dataleft (dl) 

Specifies the number of bytes of active data on the volume. You specify this number as an integer, but for readability purposes it is displayed in megabytes (MB). This is valid only in unsafe (-u) mode.

datawritten (dw) 

Specifies the maximum number of bytes ever written to the volume. You specify this number as an integer, but for readability purposes it is displayed in MB. This is valid only in unsafe (-u) mode.

eotblockid (eb) 

Specifies the blockid of the chunk containing the end-of-tape marker; a hexinteger. This is valid only in unsafe (-u) mode.

eotchunk (ec) 

Specifies the number of the chunk containing the end-of-tape marker; an integer. This is valid only in unsafe (-u) mode.

eotpos (ep) 

Specifies the absolute position of the end-of-tape marker zone in the form integer/hexinteger, designating a zone number and block ID. A value of zero is used for hexinteger if no block ID is known. integer the same as eotzone, and hexinteger is the same as eotblockid. This is valid only in unsafe (-u) mode.

eotzone (ez) 

Specifies the number of the zone containing the end-of-tape marker; an integer. This is valid only in unsafe (-u) mode.

label (lb) 

Specifies the label type: al for ANSI standard labels; sl for IBM standard labels; or nl for nonlabeled volumes. The default is al.

tapesize (ts) 

Specifies the estimated capacity in bytes; an integer. The default is 215 MB.

threshold (th) 

Specifies the ratio of dataleft to datawritten as a percentage. This field cannot be displayed or updated.

upage (ua) 

(Display only.) Specifies the date and time of the last update to the volume's database record. The same as for update, except that it is expressed as age. This is valid only in unsafe (-u) mode.

update (ud) 

(Display only.) Specifies the date and time of the last update to the volume's database record, expressed as an integer that reflects raw UNIX time. This is valid only in unsafe (-u) mode.

version (v) 

Specifies the DMF tape format version, an integer. This is valid only in unsafe (-u) mode.

wfage (wa) 

Specifies the date and time that the volume was written to or freed for reuse. The same as for wfdate, except that it is expressed as age. This is valid only in unsafe (-u) mode.

wfdate (wd) 

Specifies the date and time that the volume was written to or freed for reuse, expressed as an integer that reflects raw UNIX time. This is valid only in unsafe (-u) mode.

The date field keywords (update and wfdate) have a value of either now or raw UNIX time (seconds since January 1, 1970). These keywords display their value as raw UNIX time. The value comparison > used with the date keywords means newer than the value given. For example, >36000 is newer than 10AM on January 1, 1970, and >852081200 is newer than 10AM on January 1, 1997.

The age field keywords (upage and wfage) let you express time as age, a string in a form such as 8w12d7h16m20s (meaning 8 weeks, 12 days, 7 hours, 16 minutes, and 20 seconds old). The age keywords display their value as an integer followed by w, d, h, m, or s (weeks, days, hours, minutes, and seconds, respectively). The comparison > used with the age keywords means older than the value given (that is, >5d is older than 5 days).

The limit keywords restrict the volumes acted upon:

Keyword 

Description

datalimit (no abbreviation) 

Specifies a value in bytes. The directive stops when the sum of dataleft of the volumes processed so far exceeds this value.

recordlimit (rl) 

Specifies a number of records; an integer. The directive stops when the number of volumes processed equals this value.

recordorder (ro) 

Specifies the order that records are scanned; may be either data or vsn. vsn specifies that the records are scanned in ascending order of the chunk VSN. data specifies that the records are scanned in the order in which they are found in the database, which is fastest but essentially unordered.

The format keyword selects a format to use for the display. If, for example, you want to display fields in a different order than the default or want to include fields that are not included in the default display, you specify them with the format keyword. Values for format can be default, keyword, or a list of field keywords enclosed in quotation marks.

The flag keywords change the settings of hold flags:

Keyword 

Description

hbadmnt (hb) 

Indicates that the volume could not be mounted. If the problem causing the mount to fail is transient, the MSP will clear the flag the next time it attempts to mount the tape and succeeds. Typically this flag indicates a permanent condition that should be investigated and corrected. It is displayed as --------b.

herr (he) 

Indicates that an I/O error has occurred on the volume; displayed as e--------.

hflags (no abbreviation) 

(Display only.) Shows the complete set of hold flags as a 9-character string. Each flag has a specific position and alphabetic value. If the flag is off, a dash (-) is displayed in its position; if the flag is on, the alphabetic character is displayed in that position.

hfree (no abbreviation) 

Indicates that the volume has no active data and is available for reuse after HFREE_TIME has expired, displayed as -f-------. See the dmf_config(5) man page for information about the HFREE_TIME configuration parameter. This is valid only in unsafe (-u) mode.

hfull (hu) 

Indicates that the volume cannot hold any more data; displayed as ------u--.

hlock (hl) 

Currently unused, displayed as ----l----.

hoa (ho) 

Indicates that the volume is not to be used for either input or output, displayed as --o------.

hro (hr) 

Indicates that the volume is read-only, displayed as ---r-----; this inhibits the MSP from using the volume for output.

hrsv (h*) 

Currently unused (reserved); displayed as ----*----. This is valid only in unsafe (-u) mode.

hsparse (hs) 

Indicates that the volume is considered sparse and thus a candidate for a volume merge operation, displayed as -------s-.

For any field that takes a byte count, you may append the letter k, m, or g (in either uppercase or lowercase) to the integer to indicate that the value is to be multiplied by one thousand, one million, or one billion, respectively.

For information about the role of the dmvoladm command in database recovery, see “Database Recovery” in Chapter 7. For details about dmvoladm syntax, see the man page.

Example 6-3. dmvoladm list directives

The following example illustrates the default format for the list directive. The column marked HFLAGS uses a format similar to the ls -l command in that each letter has an assigned position and its presence indicates that the flag is “on”. The positions spell the string efor*lmusb, representing herr, hfree, hoa, hro, hrsv, hlock, hfull, hsparse, and hbadmnt, respectively.

adm 1>list S03232-S03254
                                     DATA    EOT             WR/FR
VSN    LB      DATA LEFT        WRITTEN  CHUNK   HFLAGS      AGE
------------------------------------------------------------------
S03232 sl      185.105446     400.000000     10 ------u--   997d
S03233 sl      177.057792     400.000000      2 ------u--   495d
S03234 sl      253.573185     400.000000    598 ------u--   906d
S03235 sl      170.963133     400.000000     18 ------u--   497d
S03236 sl      194.456616     400.000000     38 ------u--   915d
S03237 sl      250.533926     400.000000     92 ------u--   803d
S03238 sl        0.000000       0.000000      1 ---------   114d
S03239 sl        0.000000       0.000000      1 ---------   114d
S03240 sl        0.000000       0.000000      1 ---------   114d
S03241 sl      252.162452     400.000000    325 ------u--   369d
S03242 sl      166.635861     400.000000     81 ------u--   631d
S03243 sl      202.468129     400.000000     26 ------u--   400d
S03244 sl        0.000000       0.000000      1 ---------    96d
S03245 sl      383.047890     400.000000     26 ------u--   212d
S03246 sl      288.721920     400.000000      5 ------u--   687d
S03247 sl      261.498716     400.000000    186 ------u--   691d
S03248 sl      255.480486     400.000000     17 ------u--   288d
S03249 sl      319.990661     400.000000    526 ------u--   253d
S03250 sl        0.000000       0.000000      1 ---------   114d
S03251 sl      241.785669     400.000000    533 ------u--   327d
S03252 sl     1223.947545    1223.947545    157 ------u--    44d
S03253 sl      386.038988     400.000000    636 ------u--   136d
S03254 sl      170.798521     400.000000     38 ------u--   228d

The following example illustrates using the list command to show only volumes meeting some criterion (in this case, those having their hfree flag set):

adm: 1>list hfree
                                     DATA    EOT             WR/FR
   VSN LB       DATA LEFT        WRITTEN  CHUNK   HFLAGS      AGE
-------------------------------------------------------------------
003249 sl         0.000000     115.000000      9 -f-r------     3h
003250 sl         0.000000     115.000000      9 -f-r------     3h
003251 sl         0.000000     115.000000     10 -f-r------     3h
003252 sl         0.000000     115.000000     11 -f-r------     3h
003255 sl         0.000000     115.000000     15 -f-r------     3h
003258 sl         0.000000     115.000000     13 -f-r------     3h
003263 sl         0.000000     115.000000     12 -f-r------     3h
003264 sl         0.000000       0.000000      1 -f--------     4h
003289 sl         0.000000       0.000000      1 -f-r------     3h
003290 sl         0.000000     215.000000     29 -f-r------     3h
003294 sl         0.000000       0.000000      1 -f--------     4h

The following example shows one way you can customize the list format to show only the fields that you want to see. The other way is to use the set format command with the same keyword list.

adm 21>list S03232-S03254 format "eotchunk eotzone eotpos"
          EOT   EOT
VSN     CHUNK  ZONE    EOTPOS
-------------------------------
S03232     10     2 2/4294967295
S03233      2     2 2/4294967295
S03234    598     2 2/4294967295
S03235     18     2 2/4294967295
S03236     38     2 2/4294967295
S03237     92     2 2/4294967295
S03238      1     1 1/4294967295
S03239      1     1 1/4294967295
S03240      1     1 1/4294967295
S03241    325     2 2/4294967295
S03242     81     2 2/4294967295
S03243     26     2 2/4294967295
S03244      1     1 1/4294967295
S03245     26     2 2/4294967295
S03246      5     2 2/4294967295
S03247    186     2 2/4294967295
S03248     17     2 2/4294967295
S03249    526     2 2/4294967295
S03250      1     1 1/4294967295
S03251    533     2 2/4294967295
S03252    157    17 17/2147483648
S03253    636     2 2/4294967295
S03254     38     2 2/4294967295

The following example gives a convenient way to show the several flag bits in a way different from their usual representation.

adm 23>list 003232-003254 format "herr hfree hfull hlock hoa hro"
       herr hfree hfull hlock hoa hro
VSN
--------------------------------------
003232  off   off    on    off off off
003233  off   off   off    off off off
003234  off   off   off    off off off
003235  off   off   off    off off off
003236  off   off    on    off off off
003237  off   off    on    off off off
003238  off   off    on    off off off
003239  off   off    on    off off off
003240  off   off   off    off off off
003241  off   off    on    off off off
003242  off   off    on    off off off
003243  off   off   off    off off off
003244  off   off   off    off off off
003245  off   off    on    off off off
003246  off   off   off    off off off
003247  off   off    on    off off off
003248  off   off    on    off off  on
003249  off    on   off    off off  on
003250  off    on   off    off off  on
003251  off    on   off    off off  on
003252  off    on   off    off off  on
003253  off   off    on    off off  on
003254  off   off    on    off off  on


dmvoladm(blank) Text Field Order

The text field order for volume records generated by the dmdump(8), dmdumpj(8), and the dump directive in dmvoladm is listed below. This is the format expected by the load directives in dmvoladm:

  1. V (indicates the volume record type)

  2. vsn

  3. lbtype

  4. capacity

  5. blocksize

  6. hflags (in octal)

  7. version

  8. datawritten

  9. eotchunk

  10. eotposition (eotzone/eotblockid) (in hexadecimal)

  11. dataleft

  12. chunksleft

  13. wfdate

  14. update

  15. id (in octal). This field indicates the type of process that last updated the record.

dmatread Command

Use the dmatread(8) command to copy all or part of the data from a migrated file back to disk. You might want to do this if, for example, a user accidentally deleted a file and did not discover that the deletion had occurred until after the database entries had been removed by the hard delete procedure. Using backup copies of the databases from before the hard delete was performed, dmatread can restore the data to disk, assuming that the tape volume has not been reused in the meantime.

Example 6-4. Restoring Hard-deleted Files Using dmatread

To copy migrated files back to disk, perform the following steps:

  1. Determine the bfid of the file you want to restore. You can use backup copies of dmdlog or your dbrec.dat files, or a restored dump copy of the deleted file's inode (and the dmattr command).

  2. Using backup copies of the MSP databases, use a dmatread(8) command similar to the following:

    dmatread -p /a/dmbackup -B 342984C50000000000084155

    342984C50000000000084155 is the bfid of the file to be restored, and /a/dmbackup is the directory containing the backup copies of the MSP databases. Your file will be restored to the current directory as B342984C50000000000084155

DMF does not know the original name of the file; you must manually move the restored data to the appropriate file.

If you have access to chunk and VSN information for the file to be restored, you can use the dmatread -c and -v options and avoid using backup copies of the MSP database. In this case, dmatread will issue messages indicating that the chunk is not found in the current database, but it will continue with the request and restore the file as described in this example.


dmatsnf Command

Use the dmatsnf(8) command to verify the readability of or to audit the contents of MSP volumes. You may also generate text database records that can be applied to the MSP databases (using the load directive in dmcatadm and dmvoladm, respectively), in order to add the contents of a volume to the MSP database (although this is impractical for large numbers of volumes).

dmatsnf can be used to verify one or more tape volumes against the MSP databases. It also can be used to generate journal entries, which can be added to the MSP databases by using the load directive in dmvoladm and dmcatadm.

dmaudit verifymsp Command

Use the verifymsp option of the dmaudit(8) command to check the consistency of the DMF daemon and MSP databases after an MSP, DMF, or system failure. This command captures the database files and compares the contents of the daemon database with each MSP database. Any problems are reported to standard output, but no attempt is made to repair them.

This function can also be done directly using dmatvfy(8) after a snapshot has been taken.

FTP MSP

The FTP MSP allows the DMF daemon to manage data by moving it to a remote machine. Data is moved to and from the remote machine with the protocol described in RFC 959 (FTP). The remote machine must understand this specific protocol.


Note:: It is desirable that the remote machine run an operating system based on UNIX, so that the MSP can create subdirectories to organize the offline data. However, this is not a requirement.

The FTP MSP does not need a private database to operate; all information necessary to retrieve offline files is kept in the daemon database, DMF configuration file, and login information file. The login information file contains configuration information, such as passwords, that must be kept private. As a safeguard, the MSP will not operate if the login information file is readable by anyone other than the system administrator.

Processing of Requests

The FTP MSP is always waiting for requests to arrive from the DMF daemon, but, to improve efficiency, it holds PUT and DELETE requests briefly and groups similar requests together into a single FTP session. No PUT request will be held longer than 60 seconds. No DELETE request will be held longer than 5 seconds. GET requests are not held. The MSP will stop holding requests if it has a large amount of work to do (more than 1024 individual files or 8 MB of data). The FTP MSP also limits the number of FTP sessions that can be active at once and the rate at which new sessions can be initiated.

After a request has been held for the appropriate amount of time, it enters a ready state. Processing usually begins immediately, but may be delayed if resources are not available.

The following limits affect the maximum number of requests that can be processed:

  • An administrator-controlled limit on the maximum number of concurrent FTP sessions per MSP (CHILD_MAXIMUM).

  • An administrator-controlled limit on the number of child processes that are guaranteed to be available for processing delete requests (GUARANTEED_DELETES).

  • An administrator-controlled limit on the number of child processes that are guaranteed to be available for processing dmget(1) requests (GUARANTEED_GETS).

  • A system-imposed limit of 85 FTP sessions in any 60-second period. This limit is seldom a concern because of the MSP's ability to transfer many files in one session. Because requests are grouped into batches only when resources are immediately available, GET requests (which are not normally held) are batched when resources are in short supply.

Requests are processed by forking off a child process. The parent process immediately resumes waiting for requests to arrive from the DMF daemon. The child process attempts to initiate an FTP session on the remote FTP server. If the remote machine has multiple Internet Protocol (IP) addresses, all of them are tried before giving up. If the child process cannot connect, it waits 5 minutes and tries again until it succeeds.

Once a connection is established, the child process provides any required user name, password, account, and default directory information to the remote FTP server. PUT, GET, or DELETE operations are then performed as requested by the DMF daemon. PUT, GET, or DELETE operations are not intermixed within a batch. If an individual request does not complete successfully, it does not necessarily cause other requests in the same batch to fail. Binary transfer mode is used for all data transfer.

The stored files are not verbatim copies of the user files. They are stored using the same format used to write tapes, and you can use MSP utilities such as dmatread and dmatsnf to access the data in them.

Activity Log

All DMF MSPs maintain log files named msplog.yyyymmdd in the MSP spool directory which, by default, is SPOOL_DIR/mspname. SPOOL_DIR is configured in the base object of the configuration file; mspname is the name of the MSP in the daemon object of the configuration file; yyyymmdd is the current year, month, and day.

The activity log shows the arrival of new requests, the successful completion of requests, failed requests, creation and deletion of child processes, and all FTP transactions. Sensitive information (passwords and account information) does not appear in the activity log. In addition, the MSP lists the contents of its internal queues in its activity log if it is given an INTERRUPT signal.


Note: Because the MSP will continue to create log files and journal files without limit, you must remove obsolete files periodically by configuring the run_remove_logs and run_remove_journals tasks in the configuration file, as described in “Configuring Daemon Maintenance Tasks” in Chapter 2.


Messages

The MSP also recognizes and handles the following messages issued from the DMF daemon:

Message 

Description

CANCEL 

Issued when a previously requested action is no longer necessary, for example, when a file being migrated with a PUT request is removed. The MSP is able to cancel a request if it is being held or if it is waiting for resources. A request that has begun processing cannot be canceled and will run to normal completion.

FINISH 

Issued during normal shutdown. When the MSP receives a FINISH message, it finishes all requested operations as quickly as it can and then exits.

FLUSHALL 

Issued in response to the dmdidle(8) command. When the MSP receives a FLUSHALL message, it finishes all requested operations as quickly as it can.


Caution: If the remote file system must be restored to a previous state, inconsistencies may arise: remote files that reappear after being deleted are never removed, and remote files that disappear unexpectedly result in data loss. There is presently no way to detect these inconsistencies. You should avoid situations that require the remote file system to be restored to a previous state.


Disk MSP

The disk MSP (dmdskmsp) migrates data into a directory that is accessed on the current system. It uses POSIX file interfaces to open, read, write, and close files. The directory may be NFS-mounted. The data is read and written with root (uid 0) privileges. By default, dmdskmsp stores the data in DMF-blocked format, which allows the MSP to do the following:

  • Keep meta-data with a file

  • Keep sparse files sparse when they are recalled

  • Verify that a file is intact on recall

The disk MSP does not need a private database to operate; all information necessary to retrieve offline files is kept in the daemon database and DMF configuration file.

The disk MSP may also be used as an import MSP. In this case, it only permits recalls and copies the data unchanged for a recall.

Processing of Requests

The disk MSP is always waiting for requests to arrive from the DMF daemon, but, to improve efficiency, it holds PUT and DELETE requests briefly and groups similar requests together into a single session. No PUT request will be held longer than 60 seconds. No DELETE request will be held longer than 5 seconds. GET requests are not held. The MSP will stop holding requests if it has a large amount of work to do (more than 1024 individual files or 8 MB of data).

After a request has been held for the appropriate amount of time, it enters a ready state. Processing usually begins immediately, but may be delayed if resources are not available.

The following limits affect the maximum number of requests that can be processed:

  • An administrator-controlled limit on the maximum number of concurrent operations per MSP (CHILD_MAXIMUM).

  • An administrator-controlled limit on the number of child processes that are guaranteed to be available for processing delete requests (GUARANTEED_DELETES).

  • An administrator-controlled limit on the number of child processes that are guaranteed to be available for processing dmget(1) requests (GUARANTEED_GETS).

Requests are processed by forking off a child process. The parent process immediately resumes waiting for requests to arrive from the DMF daemon.

PUT, GET, or DELETE operations are performed as requested by the DMF daemon. PUT, GET, or DELETE operations are not intermixed within a batch. If an individual request does not complete successfully, it does not necessarily cause other requests in the same batch to fail. Binary transfer mode is used for all data transfer.

The stored files are not verbatim copies of the user files. They are stored using the same format used to write tapes, and you can use MSP utilities such as dmatread and dmatsnf to access the data in them.

Activity Log

All DMF MSPs maintain log files named msplog.yyyymmdd in the MSP spool directory which, by default, is SPOOL_DIR/mspname. SPOOL_DIR is configured in the base object of the configuration file; mspname is the name of the MSP in the daemon object of the configuration file; yyyymmdd is the current year, month, and day).

The log file shows the arrival of new requests, the successful completion of requests, failed requests, and creation and deletion of child processes. In addition, the MSP lists the contents of its internal queues in its activity log if it is given an INTERRUPT signal.


Note: Because the MSP will continue to create log files and journal files without limit, you must remove obsolete files periodically by configuring the run_remove_logs and run_remove_journals tasks in the configuration file, as described in “Configuring Daemon Maintenance Tasks” in Chapter 2.


Moving Migrated Data between MSPs

DMF provides a mechanism to move copies of offline or dual-state files from one MSP to another. The dmmove(8) command takes a list of such files and moves them to a specified set of MSPs. The list of MSPs specified to the dmmove command indicates which MSPs are to contain migrated copies of a file after the move process is completed. All other migrated copies are hard-deleted.


Note: All migrated copies of files are hard-deleted, including those on MSPs that are not indicated on the dmmove command.


If a file's migrated state is offline, dmmove recalls the file to disk and then remigrates it to the specified MSPs. When the migration process is complete, the online copy is removed. The file is recalled to a scratch file system that is specified by the MOVE_FS configuration parameter. If the file is dual-state, dmmove does not need to recall the file first, but instead uses the existing online copy.

The dmselect(8) command can be used to determine which files you want to move. dmselect selects files based on age, size, ownership, and MSP criteria. The output from the dmselect command can be used with the dmmove command. The dmmove command also accepts a list of path names as input.

See the man pages for dmselect and dmmove for all the possible options and further information.