Additional information available:

$@ANALYZEAT_ENDBACKUPCHANGECHANGE_DATABASE
CHANGE_FIELDCHANGE_INDEXCHANGE_PROTECTION
CHANGE_RELATIONCHANGE_STORAGE_MAPCOMMITCONVERT
CREATE_SEGMENTDATABASEDECLARE_STREAMDEFINEDEFINE_COLLATING
DEFINE_CONSTRAINTDEFINE_DATABASEDEFINE_FIELDDEFINE_INDEX
DEFINE_PROTECTIONDEFINE_RELATIONDEFINE_STORAGE_MAP
DEFINE_TRIGGERDEFINE_VIEWDELETEDELETE_COLLATING
DELETE_CONSTRAINTDELETE_DATABASEDELETE_FIELDDELETE_INDEX
DELETE_PATHNAMEDELETE_PROTECTIONDELETE_RELATIONDELETE_STORAGE_MAP
DELETE_TRIGGERDELETE_VIEWEDITEND_SEGMENT
END_STREAMERASEEXITEXPORTFETCHFINISH
FORGETHELPIMPORTINTEGRATEINVOKE
MODIFYNEW_FEATURES_V4.1ON_ERRORPLACEPRINTRDOINI
READYROLLBACKRSESETSHOWSTART_SEGMENT
START_STREAMSTART_TRANSACTIONSTORE

Access rightsCommand RecallCond exprDatatypesData DistribDCL invoke
DemoErrorsExecuteField attrLogical NamesPreprocessors
RDO Foreign CmdRelease NotesRel operatorsSegment strValue expr

 Rdb/VMS controls access rights that grant or deny users access to:

  o  Data in an Rdb/VMS database
  o  Rdb/VMS data definition statements
  o  Rdb/VMS utility statements

 When specifying access rights, remember these rules:

  o  Rdb/VMS denies all access rights not explicitly granted.
  o  Specify only those access rights to which you want to grant
     access.
  o  If you want to grant all access rights, you can do so by
     specifying the keyword "ALL" instead of listing all the access
     rights.
  o  If you want to deny all access rights, you can do so by
     specifying the keyword "NONE".

 For tables that define these access rights, ask for Additional
 Information on DATA_ACCESS, DEF_ACCESS.

Additional information available:

DATA_ACCESSDEF_ACCESS

 This table lists the access rights that control access to data.

 Table 1:
 +----------------+-------------+----------------+
 |                |             |                |
 | Access Right   | To Grant    | To Deny        |
 +----------------+-------------+----------------+
 |                |             |                |
 | Read data      |  READ       |   NOREAD       |
 |                |             |                |
 | Store data     |  WRITE      |   NOWRITE      |
 |                |             |                |
 | Modify data    |  MODIFY     |   NOMODIFY     |
 |                |             |                |
 | Erase data     |  ERASE      |   NOERASE      |
 +----------------+-------------+----------------+

 This table lists the access rights that control access to database
 definitions.

 +---------------------------+---------------+------------------+
 |                           |               |                  |
 | Access Right              | To Grant      | To Deny          |
 +---------------------------+---------------+------------------+
 |                           |               |                  |
 | Define global field,      | DEFINE        | NODEFINE         |
 | relation, or storage map  |               |                  |
 |                           |               |                  |
 | Change global field       | CHANGE        | NOCHANGE         |
 |                           |               |                  |
 | Delete global field       | DELETE        | NODELETE         |
 |                           |               |                  |
 | Run two-phase commit      | DISTRIBTRAN   | NODISTRIBTRAN    |
 | transaction on database   |               |                  |
 |                           |               |                  |
 | Define, change, delete    | CONTROL       | NOCONTROL        |
 | database protection       |               |                  |
 |                           |               |                  |
 | [future versions]         | REFERENCES    | NOREFERENCES     |
 |                           |               |                  |
 | Specify, show, and review | SECURITY      | NOSECURITY       |
 | the security audit trail  |               |                  |
 |                           |               |                  |
 | [future versions]         | SHOW          | NOSHOW           |
 |                           |               |                  |
 | Open or close a database  | ADMINISTRATOR | NOADMINISTRATOR  |
 |                           |               |                  |
 | Any CHANGE DATABASE       | ADMINISTRATOR | NOADMINISTRATOR  |
 | option                    |               |                  |
 |                           |               |                  |
 | Delete a database         | ADMINISTRATOR | NOADMINISTRATOR  |
 +---------------------------+---------------+------------------+

 This table lists the access rights that control access to relation
 definitions.

 +---------------------------+---------------+------------------+
 |                           |               |                  |
 | Access Right              |   To Grant    |  To Deny         |
 +---------------------------+---------------+------------------+
 |                           |               |                  |
 | Define index or storage   |   DEFINE      |  NODEFINE        |
 | map                       |               |                  |
 |                           |               |                  |
 | Define trigger            | READ,DEFINE   |  NOREAD,NODEFINE |
 |                           |               |                  |
 | Define view or constraint | READ,DEFINE   |  NOREAD,NODEFINE |
 |                           |               |                  |
 | Change relation           |   CHANGE      |  NOCHANGE        |
 |                           |               |                  |
 | Delete relation,          |   DELETE      |  NODELETE        |
 | index, view,              |               |                  |
 | constraint, or storage    |               |                  |
 | map                       |               |                  |
 |                           |               |                  |
 | Define, change, delete    |   CONTROL     |  NOCONTROL       |
 | protection for            |               |                  |
 | relation                  |               |                  |
 |                           |               |                  |
 | [Reserved for future      |   SHOW        |  NOSHOW          |
 | versions]                 |               |                  |
 |                           |               |                  |
 | [Reserved  for  future    |   OPERATOR    |  NOOPERATOR      |
 | versions]                 |               |                  |
 +---------------------------+---------------+------------------+

 Rdb/VMS saves and allows you to access up to 20 of your most recently
 entered RDO commands.  Use the UP-ARROW or CTRL/B keys to recall
 previously entered commands.  Use the DOWN-ARROW key to reexamine a
 command that you had retrieved using the UP-ARROW key.

 This feature is designed for the convenience of RDO users.  It
 greatly reduces the need to enter the RDO editing buffer to rerun one
 or more of your last 20 commands.  The EDIT statement continues to be
 a useful tool for created RDO procedures in that it lets you take
 advantage of your editor's text manipulation features and it lets you
 edit multiple lines.

Additional information available:

More

 Any string entered at the RDO> prompt is saved in the recall buffer.
 This includes all DCL commands prefaced by the dollar sign ($),
 commented text that begins with the exclamation point (!), and any
 RDO statements.  The carriage return delimits each line written to
 the recall buffer.  Thus, in the following example, four separate
 entries are written to the recall buffer:

 RDO> FOR E IN EMPLOYEES
 cont> WITH E.EMPLOYEE_ID BETWEEN "00164" AND "00175"
 cont> PRINT E.LAST_NAME, E.EMPLOYEE_ID
 cont> END_FOR

 The most recently typed command is at the top of the recall buffer.
 If the user enters CTRL/B at this point, the END_FOR statement would
 appear first.

 There are no parameters or logicals available to control the maximum
 number of lines saved in the recall buffer.

 An expression, sometimes called a Boolean expression, that represents
 the relationship between two value expressions.  The value of a
 conditional expression is either true, false, or null.

 Conditional expressions can be combined with AND and OR or qualified
 with NOT.  The AND, OR, and NOT operators are called logical
 operators.

Additional information available:

Format

 conditional-expr =

 ──┬───> conditional-expr ──> 
A
N
D ──> conditional-expr ───┬──>
   ├───> conditional-expr ──> 
O
R ───> conditional-expr ───┤
   ├────────────────────────> 
N
O
T ──> conditional-expr ───┤
   ├───> value-expr  ──> operator ──> value-expr  ────────┤
   ├───> any-clause ──────────────────────────────────────┤
   ├───> between-clause ──────────────────────────────────┤
   ├───> containing-clause ───────────────────────────────┤
   ├───> matching-clause ─────────────────────────────────┤
   ├───> missing-clause ──────────────────────────────────┤
   ├───> starting-with-clause ────────────────────────────┤
   └───> unique-clause ───────────────────────────────────┘

Additional information available:

ANYBETWEENCONTAININGMATCHINGMISSINGSTARTING_WITH
UNIQUE

value-expr

 For a complete description of Rdb/VMS value expressions, ask for HELP
 on Value_expr.

 any-clause =

 ────┬───>────────┬──> 
A
N
Y ───> rse ───>
     └───> 
N
O
T ───┘

 The condition containing ANY is true if the record stream specified
 by the record selection expression (RSE) includes at least one
 record.  If you add NOT, the condition is true if there are no
 records in the record stream.

 between-clause =

 ────> value-expr  ────┬───>──────┬───> 
B
E
T
W
E
E
N ────┐
                       └──> 
N
O
T ──┘                 │
      ┌─────────────────────────────────────────────┘
      └───> value-expr  ───> typebox (A)typebox (N)typebox (D) ───> value-expr  ───────>

 The condition containing BETWEEN is true if the first value
 expression is between the second and the third value expressions or
 equal to one of them.

 containing-clause =

 ───> value-expr ───┬─────>────┬──> 
C
O
N
T
A
I
N
I
N
G ───> value-expr ───>
                    └──> 
N
O
T ──┘

 With CONTAINING, the condition is true if the second value expression
 is found within the first.  In most cases, the value expressions in a
 CONTAINING clause evaluate to text strings, but CONTAINING also
 operates on numeric data types.

                                 NOTE

         CONTAINING is not case sensitive; it considers
         uppercase and lowercase forms of the same letter to
         be a match.

 If either of the value expressions in a CONTAINING clause is null,
 the result is null.

 matching-clause =

 ───> value-expr ───┬─────>────┬─> 
M
A
T
C
H
I
N
G ───> match-expr ────>
                    └──> 
N
O
T ──┘

 With MATCHING, the condition is true if the match expression matches
 the value expression.  MATCHING uses the following symbols:

 * Matches any string of zero or more characters

 % Matches any single character

                                 NOTE

         MATCHING is not case sensitive; it considers
         uppercase and lowercase forms of the same letter to
         be a match.

 If either of the expressions is null, the result is null.

 missing-clause =

 ───> db-field  ────────┬────>─────┬──> 
M
I
S
S
I
N
G ───>
                        └──> 
N
O
T ──┘

 This condition is true if the value specified by db-field is missing.

 starting-with-clause =

 ───> value-expr ───┬─────>─────┬──> 
S
T
A
R
T
I
N
G 
W
I
T
H ───> value-expr ──>
                    └──> 
N
O
T ───┘

 If a condition contains STARTING WITH, the condition is true if the
 first characters of the first string expression match the second
 string expression.  In most cases, the value expressions in a
 STARTING WITH clause evaluate to text strings, but STARTING WITH also
 operates on numeric data types.

                                 NOTE

         STARTING WITH is case sensitive; it considers
         uppercase and lowercase forms of the same letter to
         be different.

 If either of the string expressions in a STARTING WITH clause is
 null, the result is null.

 unique-clause =

   ──────┬───>─────┬─> 
U
N
I
Q
U
E ───> rse ───>
         └──> 
N
O
T ─┘

 The condition containing UNIQUE is true if the record stream
 specified by the RSE includes only one record.  If you add NOT, the
 condition is true if there is more than one record in the record
 stream or the record stream is empty.

 This table summarizes the characteristics of the Rdb/VMS data types.


Table 1:  Rdb/VMS Data Types

VAX Rdb/VMS   Corresponding    Size     Range          Other
Data Type     VAX Data Type             Precision      Parameters

SIGNED        Signed byte      8 bits   -128 to          n = scale
BYTE          integer                   127              factor

SIGNED        Signed word     16 bits   -32768 to        n = scale
WORD          integer                   32767            factor

SIGNED        Signed          32 bits   -2**31 to        n = scale
LONGWORD      longword                  (2**31)-1        factor
              integer

SIGNED        Signed          64 bits   -2**63 to        n = scale
QUADWORD      quadword                  (2**63)-1        factor
              integer

F_FLOATING    F_floating      32 bits   0.29 x 10**(-38)    None
              Single                    to 1.7 x 10**38
              precision                 Approximately
              floating                  seven decimal
              point number              digits

G_FLOATING    G_floating      64 bits   0.56 x 10**(-308)   None
              Extended                  to 0.9 x 10**308
              precision                 Approximately
              floating                  15 decimal
              point number              digits

DATE          Absolute date   64 bits   Not                 None
              and time                  applicable

TEXT          ASCII text      n bytes   0 to 32767        n = number
of
                                        characters        characters
                                                          (unsigned
                                                          integer)

VARYING       Varying         Varies    0 to 32765        n = maximum
STRING        length ASCII              characters        number of
              text                                        characters
                                                          (unsigned
                                                          integer)

SEGMENTED     None            Varies    0 to 64k            None
STRING                                  bytes per
                                        segment

Note:         For more information on SEGMENTED STRINGS, request HELP
              on Segment_str.

 VAX Data Distributor is a software product that lets you distribute
 whole databases, or parts of them, to target directories on the same
 or different nodes in the network.  The source database for
 extraction and extraction rollup target databases can be a
 DSRI-compliant database such as Rdb/VMS or VIDA.  The source database
 for a replication target database must be an Rdb/VMS database.

 You can issue all language statements, options, and qualifiers of VAX
 Data Distributor from RDO when VAX Data Distributor is installed on
 your system.

Additional information available:

EXTRACTIONEXTRACTION_ROLLUPREPLICATIONSHOW_TRANSFER
DELETE_SCHEDULEDELETE_TRANSFERDEFINE_TRANSFERDEFINE_SCHEDULE
REINITIALIZE_TRANSFERSTART_TRANSFERSTOP_TRANSFER

Release NotesError msg doc

 To see the current Release Notes for VAX Data Distributor, type or
 print the following file:

      SYS$HELP:DDALvvu.RELEASE_NOTES

                where   vv = version
                        u  = update

           For example:

      SYS$HELP:DDAL021.RELEASE_NOTES

 Errors returned by Data Distributor are documented online in the file
 SYS$HELP:DDAL$MSG.DOC, which you can PRINT, TYPE, or SEARCH at DCL
 level.

 Specifies that Data Distributor create an extraction database at the
 target site.  Because each extraction database is independent of the
 source database, users at the target directory can access extraction
 databases with either read-only or read/write transactions.  Each
 time an extraction transfer executes, Data Distributor creates a new
 version of the target database and transfers a complete copy of the
 selected records to the target node.

 Indexes, constraints, and access rights are not transferred when the
 target database is created.  Once the target database has been
 created, you can define views, indexes, and constraints for it and
 modify the access rights.  Refer to the VAX Data Distributor Handbook
 for more information about extraction databases.

 Specifies that Data Distributor create an extraction rollup database
 at the target site with records selected from one or more source
 databases.  Because each extraction rollup database is independent of
 the source database, users at the target directory can access
 extraction rollup databases with either read-only or read/write
 transactions.  Each time an extraction rollup transfer executes, Data
 Distributor creates a new version of the target database and
 transfers a complete copy of the selected records to the target node.

 Indexes, constraints, and access rights are not transferred when the
 target database is created.  Once the target database has been
 created, you can define indexes and constraints for it and modify the
 access rights.  Refer to the VAX Data Distributor Handbook for more
 information about extraction databases.

 Specifies that Data Distributor create a replication database at the
 target site.  When a replication transfer executes, Data Distributor
 creates a database at the target site during the initial execution
 and supplies updates to it during subsequent transfers.  In addition,
 the execution of a replication transfer might create special-purpose
 relations in the source database and the target database to handle
 updating.

 Refer to the VAX Data Distributor Handbook for specific information
 about these special database entities.  Because the source database
 is modified with the addition of these new system relations, the user
 who defined the transfer needs the DEFINE access right to the source
 database.

 After Data Distributor creates the target database and transfers the
 data records to it, users are expected to access the replication
 database to retrieve data only.  Applications should not attempt to
 store, modify, or erase values in records of the replication
 database.

 Displays information about the transfer definition, schedule
 definition, the transfer status, or all these transfer attributes.
 When you enter the SHOW TRANSFER statement, you can display
 information about one transfer or all of them, but not about a
 selected number of transfers.

Additional information available:

MoreFormat

 You must have the Rdb/VMS READ privilege for a database to use the
 SHOW TRANSFER statement.

 SHOW TRANSFER ────> transfer-attribute ───┐
    ┌──────────────────────────────────────┘
    └──────> 
F
O
R ───┬───> 
A
L
L ────────────┬───>
                    └───> transfer-name ──┘

Additional information available:

ALL

transfer-attributetransfer-name

 transfer-attribute =

 ───┬───> 
D
E
F
I
N
I
T
I
O
N ─────┬────>
    ├───> 
S
C
H
E
D
U
L
E ───────┤
    ├───> 
S
T
A
T
U
S ─────────┤
    └───> 
A
L
L ────────────┘

 The type of information you want displayed about the selected
 transfer or all transfers.

Additional information available:

DEFINITIONSCHEDULESTATUSALL

 Displays transfer definition information for the specified transfer
 or for all transfers.

 Displays schedule definition information for the specified transfer
 or for all transfers.

 Displays the following status information for the specified transfer
 or for all transfers:

  o  Transfer name

  o  State of the current transfer (unscheduled, scheduled, active,
     waiting-to-retry, retrying, suspended)

  o  Time the transfer entered its current transfer state

  o  Last transfer status

  o  Time the last successful transfer completed

  o  Next scheduled transfer time (for transfers in the scheduled or
     waiting-to-retry state)

  o  Number of the currently executing retry (for transfers in the
     retrying state)

  o  Number of the next retry (for transfers in the waiting-to-retry
     state)

 Displays all information about the definition, schedule, and status
 for the specified transfer or for all transfers.

 Specifies that you want Data Distributor to display information about
 all transfers associated with your UIC.  For transfers belonging to
 other UICs, Data Distributor displays only the transfer name.  To
 display information about transfers belonging to other UICs, you must
 have VMS BYPASS or READALL privilege.

 The transfer about which you want Data Distributor to display
 information.

 Deletes the schedule definition associated with a transfer definition.
 You can delete a schedule definition only when the associated transfer is
 in the suspended state.  Refer to the STOP TRANSFER statement for
 information about how to suspend a transfer.  If you issue a START
 TRANSFER statement after deleting the schedule, the transfer will be
 placed in the unscheduled state.

Additional information available:

FormatMoreExample

 DELETE SCHEDULE ──> Ftypebox (O)typebox (R) ───> transfer-name ──────> .

Additional information available:

transfer-name

 Identifies the transfer whose schedule is to be deleted.  The
 transfer-name parameter is required.

 You must execute the DELETE SCHEDULE statement outside of the scope of a
 transaction.  If you issue this statement when a transaction is
 outstanding, Data Distributor returns an error message.

 If a transfer has a schedule definition, DELETE TRANSFER also deletes the
 corresponding schedule definition.  If you want to delete a transfer
 schedule, the schedule definition must be associated with your UIC.

 This example places the NH_EMPLOYEES transfer in a suspended state and
 then deletes the associated schedule.

 RDO> STOP TRANSFER NH_EMPLOYEES
 RDO> DELETE SCHEDULE FOR NH_EMPLOYEES.

 Deletes a transfer definition.  If a transfer has a schedule definition,
 DELETE TRANSFER also deletes the corresponding schedule definition.

Additional information available:

FormatMoreExample

 DELETE TRANSFER ───> transfer-name ────> .

Additional information available:

transfer-name

 The transfer definition to be deleted.  The transfer-name parameter is
 required.

 You must have the Rdb/VMS ERASE privilege to the transfer relation to
 use the DELETE TRANSFER statement.

 You must execute the DELETE TRANSFER statement outside of the scope
 of a transaction.  If you issue this statement when a transaction is
 outstanding, Data Distributor returns an error message.

 You can delete a transfer only if the transfer is in the suspended
 state.  Refer to the STOP TRANSFER statement for information about
 how to suspend a transfer.

 When you delete a transfer definition, the associated target database
 does not change in any way.

 If you want to delete a transfer definition, the transfer definition
 must be associated with your UIC.

 The following example suspends the MA_EMPLOYEES transfer and then deletes
 its definition:

 RDO> STOP TRANSFER MA_EMPLOYEES
 RDO> DELETE TRANSFER MA_EMPLOYEES.

 Creates a transfer definition and stores it in the transfer database.  A
 transfer definition contains all the information necessary to select a set
 of records from the source database and to define a target database.  A
 transfer definition also can contain the views to be defined on the target
 database and the command procedures to be executed before and after the
 execution of the transfer.

 A source database for extraction or extraction rollup transfers can be any
 DSRI-compliant database, such as Rdb/VMS or VIDA.  For replication
 transfers, the source database must be an Rdb/VMS database.

Additional information available:

FormatMoreExamples

 DEFINE TRANSFER  ──> transfer-name ──┬───> 
R
E
P
L
I
C
A
T
I
O
N ─────────┬──┐
                                      ├───> 
E
X
T
R
A
C
T
I
O
N ──────────┤  │
                                      └───> 
E
X
T
R
A
C
T
I
O
N 
R
O
L
L
U
P ───┘  │
 ┌─────────────────────────────<────────────────────────────────────┘
 └──┬─>───────────────────────────────┬──> 
T
O ──> file-spec ─┐
    └─> 
D
E
S
C
R
I
P
T
I
O
N typebox (I)typebox (S) ─> typebox (/)typebox (*) text */ ─┘                      │
 ┌──────────────────────────────<────────────────────────────┘
 └─┬─>───────────────────────┬─┬─┬─>─────────────────────────────┬─┬─┐
   └─>target-db-param-clause─┘ │ ├─>move-relations-clause ───────┤ │ │
                               │ ├─>move-views-clause ───────────┤ │ │
                               │ └─>move-relations-rollup-clause─┘ │ │
                               └─────────────<─────────────────────┘ │
  ┌──────────────────────────────<───────────────────────────────────┘
  └──┬──────────>─────────────────────────┬──────────────────────────┐
     └───> transfer-file-options-clause ──┘                          │
  ┌────────────────────────────────<─────────────────────────────────┘
  └──> 
E
N
D ───┬─────────>─────────┬──┬───────>──────┬───────> .
              └─> transfer-name ──┘  └─> 
T
R
A
N
S
F
E
R ──┘

Additional information available:

REPLICATIONEXTRACTIONEXTRACTION_ROLLUPRSE

transfer-nametextfile-spectarget-db-param-clausemove relations clause
move-views-clausemove-relations-rollup-clausetransfer-file-options-clause

 The name that identifies the transfer.  The transfer name must be
 unique among the set of all transfers defined in the transfer
 database.  Because a single transfer database serves all source
 databases on a node or VAXcluster, the transfer name must be unique
 across all source databases at a given site.

 The transfer-name parameter is required.

 Specifies that Data Distributor create a replication database at the
 target site.  When a replication transfer executes, Data Distributor
 creates a database at the target site during the initial execution
 and maintains a connection to that target database so the source can
 supply updates to the target.  Subsequent transfers involve only
 those modifications that have been made to the selected records in
 the source database.  (If the target and source database should
 become inconsistent with each other, you can use the REINITIALIZE
 TRANSFER statement to restore consistency.)

 In addition, the execution of a replication transfer generally
 creates special-purpose relations in the source database and the
 target database to handle updating.  Because the source database is
 modified with the addition of these system relations, the transfer
 definer's account needs the DEFINE access right to the source
 database itself.

 Users are expected to access the replication target database only to
 retrieve data.  Applications should not attempt to store, modify, or
 erase values in records of the replication database.  Although data
 values should not be manipulated in a replication database, you can
 modify the target database by defining views and indexes, and adding
 access rights.

 Specifies that Data Distributor create an extraction database at the
 target site.  Because each extraction database is independent of the
 source database, users at the target directory can access extraction
 databases with reaad/write as well as read-only transactions.  Each
 time an extraction mode transfer executes, Data Distributor creates a
 new version of the target database and transfers a complete copy of
 the selected records to the target node.

 Indexes, constraints, and access rights are not transferred when the
 target database is created.  Once the target database has been
 created, you can define indexes and constraints for it and modify the
 access rights.

 Specifies that Data Distributor create an extraction rollup database
 at the target site by transferring selected relations and fields from
 one or more source databases into a single target database.  An
 extraction rollup database is defined at the target site, and Data
 Distributor pulls data from the source databases into the target.

 Each time an extraction rollup transfer is executed, Data Distributor
 creates a new version of the target database and transfers a complete
 copy of the selected records to the target node.

 The EXTRACTION ROLLUP option in the DEFINE TRANSFER statement has the
 following characteristics and limitations:

  o  All extraction rollup transfers are pull transfers; that is, you
     define the extraction transfer at the target site to transfer
     data from a number of remote source databases to a single target
     database.
  o  Data Distributor issues an error message if you do not enter a
     MOVE RELATION clause or a SELECT FIELDS list in a
     move-relations-rollup-clause.
  o  You must refer to each source database in the DEFINE TRANSFER
     statement by its database handle.
  o  On the target database, relation names and field names must be
     unique.  Consequently, all target relations of the same name must
     have the same definition, and all target fields of the same name
     must have the same datatype.  If the definitions or datatypes
     differ, Data Distributor issues an error message and the transfer
     fails.
  o  If any database specified in the transfer definition is on a node
     that is not available, Data Distributor places the transfer in a
     waiting-to-retry state.  Data Distributor will retry the transfer
     at the time specified for retry in the schedule definition.
  o  If any of the source nodes specified in the transfer definition
     fail during the transfer, the transfer will also fail.  Data
     Distributor will retry the transfer at the time specified for
     retry in the schedule definition.
  o  If the transfer fails, the retry will start at the beginning, not
     where the transfer left off.


 Indexes, constraints, and access rights are not transferred when the
 target database is created.  Once the target database has been
 created, you can define indexes and constraints for it and modify the
 access rights.

 A text string that allows you to associate a comment with the
 transfer definition.  The text string, together with other parts of
 the transfer definition, appears in the SHOW TRANSFER DEFINITION
 display.  The DESCRIPTION IS clause is optional.

 Designates a file specification for the target database.  The target
 database is an Rdb/VMS database.  Data Distributor uses the file
 specification to create and access the target database.  You can use
 either a full or partial file specification or a logical name.  The
 file-spec parameter is required.  If you do not specify the node,
 device, or directory, Data Distributor assumes the SYS$LOGIN of the
 user defining the transfer.  If the file type is not .RDB, the
 transfer will fail during the creation of the target database.  The
 default file type is .RDB.

 When you specify the name of a remote node as part of the file
 specification, you can include an access control list (ACL) for
 login.  However, the most effective method of allowing access to a
 target node uses proxy accounts.

 Note that the file specification is resolved at run time.  All
 logical names used for the file-spec parameter are resolved within
 the copy process after it executes the transfer definer's login
 initialization file, LOGIN.COM.  If the target database name is a
 logical symbol name, when it is translated, the default directory is
 the one pointed to by SYS$LOGIN.

 Data Distributor makes no attempt to verify whether a database or
 file of the same name already exists in the target directory.  When
 you issue a duplicate file specification, Data Distributor creates a
 second file with the same name, but a higher version number.

 If the database system (Rdb/VMS) returns an error while attempting to
 create a database in the target directory, the copy process writes
 the error in the copy process log file and returns the error status
 to the transfer monitor.

 target-db-param-clause =

 ───┬─┬─>────────────────────────────────────────────────────┬─┬──>
    │ ├─> 
A
L
L
O
C
A
T
I
O
N typebox (I)typebox (S) ────────> number-pages ──> typebox (P)typebox (A)typebox (G)typebox (E)typebox (S) ────┤ │
    │ ├─> 
P
A
G
E 
S
I
Z
E typebox (I)typebox (S) ───> page-blocks ──────> typebox (B)typebox (L)typebox (O)typebox (C)typebox (K)typebox (S) ──────┤ │
    │ ├─> 
N
U
M
B
E
R typebox (O)F 
B
U
F
F
E
R
S typebox (I)typebox (S) ──> number-buffers ───────────┤ │
    │ ├─> 
N
U
M
B
E
R typebox (O)F 
U
S
E
R
S typebox (I)typebox (S) ────> number-users ─────────────┤ │
    │ ├─> 
B
U
F
F
E
R 
S
I
Z
E typebox (I)typebox (S) ──> buffer-blocks ───> typebox (B)typebox (L)typebox (O)typebox (C)typebox (K)typebox (S) ──────┤ │
    │ ├─> 
E
X
T
E
N
T typebox (I)typebox (S) ──────────┬─> ext-pages ───> typebox (P)typebox (A)typebox (G)typebox (E)typebox (S) ───┬──┤ │
    │ │                       └─> (multi-vol-ext-clause) ─┘  │ │
    │ ├─> 
S
N
A
P
S
H
O
T typebox (I)typebox (S) ────┬─> 
E
N
A
B
L
E
D ─┬─> 
I
M
M
E
D
I
A
T
E ──┬─┬───┤ │
    │ │                   │            └─> 
D
E
F
E
R
R
E
D  ──┘ │   │ │
    │ │                   └─> 
D
I
S
A
B
L
E
D ──────>───────────┘   │ │
    │ ├─> 
S
N
A
P
S
H
O
T 
A
L
L
O
C
A
T
I
O
N typebox (I)typebox (S) ─> snp-pages ─> typebox (P)typebox (A)typebox (G)typebox (E)typebox (S) ──────┤ │
    │ └─> 
S
N
A
P
S
H
O
T 
E
X
T
E
N
T typebox (I)typebox (S) ─┬> ext-pages ────> typebox (P)typebox (A)typebox (G)typebox (E)typebox (S) ────┬─┘ │
    │                         └> (multi-vol-ext-clause) ───┘   │
    └──────────────────<──────────────────────────<────────────┘

 Enables you to specify values for the parameters that affect the
 creation of the target database.  This clause uses syntax similar to
 the Rdb/VMS DEFINE DATABASE statement.  However, Data Distributor
 does not support all the parameters that DEFINE DATABASE supports.
 Data Distributor uses the values provided in this clause to create
 the target database.

Additional information available:

ENABLED_IMMEDIATEENABLED_DEFERREDDISABLED

number-pagespage-blocksnumber-buffersnumber-usersbuffer-blocks
ext-pagessnp-pagesmulti-vol-ext-clause

 The number of database pages initially allocated to the target
 database.  Rdb/VMS automatically extends the allocation to handle the
 loading of data and subsequent expansion.  The default is 400 pages.

 The size in blocks of each database page in the target directory.
 Page size is allocated in 512-byte blocks.  The default is two blocks
 (1024 bytes).  If your largest record has more than approximately 950
 bytes, you can specify more blocks for each page to prevent records
 from being fragmented.

 The number of buffers Rdb/VMS allocates for each process using the
 target database.  Specify an unsigned integer between 2 and 32768.
 The default is 20 buffers.

 The maximum number of users allowed to access the target database at
 one time.  The default is 50 users.  After the maximum is reached,
 the next user who tries to invoke the database receives an error
 message and must wait for access.  The largest number of users you
 can specify is 2032, and the fewest number of users is 1.

 The number of blocks Rdb/VMS allocates for each buffer.  The value
 must be greater than zero.  If you do not specify this parameter,
 Rdb/VMS uses a buffer size that is three times the page size value.

 The number of pages of each target database extent.  This parameter
 provides direct control over the extent of the target database.  For
 greater control, and particularly for multivolume databases, use the
 MINIMUM, MAXIMUM, and PERCENT GROWTH parameters of the
 multi-vol-ext-clause instead.  The default extent is 100 pages.

 Specifies that read/write transactions write previously updated
 copies of records they modify to the snapshot file, regardless of
 whether a read-only transaction is active.  Snapshot writing is
 enabled immediately by default.  With snapshots enabled, users or
 applications can read from either the snapshot file or the database
 file itself.

 Specifies that read/write transactions not write previously updated
 copies of records they modify to the snapshot file unless a read-only
 transaction is already active.  Read-only transactions that attempt
 to start after an active read/write transaction must wait for all
 active read/write users to complete their transactions.  With
 snapshots enabled, users or applications can read from either the
 snapshot file or the database file itself.

 Specifies that snapshot writing be disabled.  There is usually some
 performance gain when snapshot writing is disabled because Rdb/VMS
 does not need to perform write operations to the snapshot file during
 updates to the database.

 You should not disable snapshots for replication databases.  Although
 users are expected only to retrieve data from the replication
 database, retrieval can occur in either read-only or read/write
 transactions.

 The number of pages allocated for the snapshot file.  The default is
 100 pages.  After the target database has been created, you can use
 the RDO CHANGE DATABASE statement to truncate the snapshot file.  To
 truncate the file, specify an allocation size smaller than the
 current snapshot file size.

 multi-vol-ext-clause =

   ─────> 
M
I
N
I
M
U
M typebox (O)F ──> min-pages ───> typebox (P)typebox (A)typebox (G)typebox (E)typebox (S), ─┐
     ┌──────────────────────────────────────────┘
     └──> 
M
A
X
I
M
U
M typebox (O)F ──> max-pages ───> typebox (P)typebox (A)typebox (G)typebox (E)typebox (S), ─┐
     ┌──────────────────────────────────────────┘
     └──> 
P
E
R
C
E
N
T 
G
R
O
W
T
H typebox (I)typebox (S) ───> growth ────>

Additional information available:

min-pagesmax-pagesgrowth

 The minimum number of pages of each target database extent.  The
 default is 99 pages.

 The maximum number of pages of each target database extent.  The
 default is 9,999 pages.

 The percent of growth for each target database extent.  The default
 is 20 percent growth.

 move-relations-clause =

 ─┬──> 
M
O
V
E 
R
E
L
A
T
I
O
N
S 
A
L
L ───────────────────────>───────────┬────>
  │                                                          │
  └─┬──> 
M
O
V
E 
R
E
L
A
T
I
O
N ──┬───────────────┬──> rse ──────┐    │
    │                    └─> typebox (/)typebox (*) text */ ─┘              │    │
    │      ┌────────────────────────<───────────────────┘    │
    │      └─> 
S
E
L
E
C
T 
F
I
E
L
D
S ─┬──> 
A
L
L ────────>───────┬──┬──┘
    │                         └┬─> select-field-name ─┬┘  │
    │                          └──────── , <──────────┘   │
    └────────────────────────────── typebox (;) <───────────────────┘

 Selects the records Data Distributor transfers to the target database
 during an extraction or a replication transfer.  The records selected
 for replications are specified with a restricted form of a record
 selection expression (RSE).  You must specify a move-relations-clause
 for each user relation moved to the target database.  If you do not
 include a move-relations-clause, Data Distributor assumes the
 default, MOVE RELATIONS ALL.

 When you specify a view in a MOVE RELATION clause, the records
 selected by that view are created as a relation in the target
 database.  You can also transfer views using the move-views-clause.

 You must have READ privilege for the relations of an Rdb/VMS source
 database that you specify in a MOVE RELATION clause or a MOVE
 RELATIONS ALL clause.  For VIDA databases, Data Distributor does not
 check for READ privilege for views.

Additional information available:

MOVE_RELATIONS_ALLSELECT_FIELDS_ALL

textrseselect-field-name

 Allows you to have Data Distributor select all records and fields
 from all user relations, excluding views, that are in the source
 database at the time the transfer is defined.  If you wish to move
 views, you must use the move-views-clause or the MOVE RELATION
 clause.  Fields defined with a COMPUTED_BY clause are restricted to
 those that use the value expressions shown in the value-expr syntax
 diagram in this section.  If a field is not defined by a supported
 value expression, you will receive a warning message, and the
 COMPUTED_BY fields will not be transferred.

 If you define a transfer on a source database that is itself a target
 extraction database, do not use the MOVE RELATIONS ALL clause.  An
 error will result during transfer execution because Data Distributor
 will attempt to define the DDAL$VINTAGE relation in the new target
 database twice.  The second transfer would create a DDAL$VINTAGE
 relation in the target database.  Then, using the MOVE RELATIONS ALL
 clause, it would attempt to copy the DDAL$VINTAGE relation that
 already exists in the source database.  To avoid this error, specify
 explicitly each relation to be moved instead of using MOVE RELATIONS
 ALL.

 Do not use the MOVE RELATIONS ALL statement for an extraction rollup
 transfer.  If you use the MOVE RELATIONS ALL statement to define an
 extraction rollup transfer, the transfer will fail on execution.
 Instead, you must name the individual relations you want to transfer
 to the extraction rollup target.

 A text string that allows you to associate a comment with the MOVE
 RELATION clause.  The DESCRIPTION IS clause is optional.

 For more information on record selection expression, select the
 subtopic RSE under the DEFINE_TRANSFER Format subtopic.

 Enables you to include every field in a specific relation.  Fields
 defined with a COMPUTED_BY clause are restricted to those that use
 the value expressions shown in the value-expr syntax diagram in this
 section.  If a field is not defined by a supported value expression,
 you will receive a warning message, and the COMPUTED_BY fields will
 not be transferred.  You cannot use the SELECT FIELDS ALL statement
 for an extraction rollup transfer.

 select-field-name =

    ────────> context-variable ──> . ───> field-name ─────>

 Allows you to name a specific field or group of fields you want moved
 to the target database.  You can specify only one SELECT clause for
 each MOVE clause.  Data Distributor moves only the named fields to
 the target database.  If you do not specify SELECT FIELDS ALL, the
 select-field-name clause is required.

 Data Distributor supports COMPUTED_BY fields named in the
 select-field-name clause if the fields are defined using the value
 expressions shown in the value-expr syntax diagram in this section.
 If the fields are not defined by a supported value expression, you
 will receive a fatal error message.

 move-views-clause =

 ────>  
M
O
V
E 
V
I
E
W
S  ──┬──>  
A
L
L  ───────────┬───>
                      └┬─>  view-name  ──┬──┘
                       └──────  , <──────┘

 Selects the views Data Distributor defines on the target database
 during an extraction or a replication transfer.  All the relations,
 views, and fields on which the transferred views are based must also
 be explicitly or implicitly named in the DEFINE TRANSFER statement.
 The transfer definition will fail if any underlying relation, view,
 or field is not named when you define the transfer.

 If you specify a view name in this clause, the view definition is
 transferred to the target database.  You can include only one
 move-views-clause in a DEFINE TRANSFER statement.  However, you can
 specify two or more views in that move-views-clause.

 Transferring views is limited by the following restrictions:


  o  COMPUTED_BY fields

     Data Distributor transfers those COMPUTED_BY fields that depend
     only on the values of the relation in which the field is defined.
     Views that contain unsupported COMPUTED_BY fields cannot be
     transferred.  If views that contain unsupported COMPUTED_BY
     fields are specified in the move-views-clause of a DEFINE
     TRANSFER statement, the transfer definition fails.  You need to
     redefine the transfer, excluding the views that refer to the
     unsupported COMPUTED_BY fields.

  o  READ privilege for the view

     For a view in an Rdb/VMS database to be transferred, Data
     Distributor requires that you have Rdb/VMS READ privilege for the
     view and for the underlying relations.  If you do not have READ
     privilege for views you specify in the move-views-clause of a
     DEFINE TRANSFER statement, the transfer will fail.  You need to
     obtain READ privilege for these views before including them in a
     DEFINE TRANSFER statement.

     For VIDA databases, Data Distributor does not check for READ
     privilege for views.


 You can also move views with the move-relations-clause.  However,
 when you use the move-relations-clause to move a view, the view
 becomes a relation in the target database.

Additional information available:

view-name

 The name of the view Data Distributor transfers to the target during
 a transfer.  If you do not specify a view name, Data Distributor
 assumes the default, MOVE VIEWS ALL.

 move-relations-rollup-clause =

 ─┬─> 
M
O
V
E 
R
E
L
A
T
I
O
N ────┬────────>────────┬─> rse ────┬────┬─>
  │                     └─> typebox (/) typebox (*)text*/─────┘           │    │
  │    ┌─────────────────────────<────────────────────┘    │
  │    └──┬──────────────────────>───────────────────┬─┐   │
  │       └─> 
I
N
T
O 
R
E
L
A
T
I
O
N ────> relation-name ─────┘ │   │
  │    ┌─────────────────────────<─────────────────────┘   │
  │    └─> 
S
E
L
E
C
T 
F
I
E
L
D
S ──┬──> select-field-name ─────┬─┬─┘
  │                        └────────── , <─────────────┘ │
  └─────────────────────────── typebox (;) <───────────────────────┘

 Selects the records Data Distributor transfers into the target
 database from a number of source databases during an extraction
 rollup transfer.  The move-relations-rollup-clause has the following
 restrictions:

  o  Data Distributor requires you to invoke each source database with
     a different database handle.  You must then use these handles in
     the move-relations-rollup-clause.
  o  The move-relations-rollup-clause must be used with the EXTRACTION
     ROLLUP parameter.

     Rollup transfers must be extractions.  If you attempt to use the
     move-relations-rollup-clause with a replication transfer, the
     transfer definition will fail.
  o  The MOVE RELATIONS ALL and SELECT FIELDS ALL clauses are not
     allowed in rollup transfers.

Additional information available:

rseselect-field-name

 For more information on record selection expression, select the
 subtopic RSE under the DEFINE_TRANSFER Format subtopic.

 select-field-name =

    ────────> context-variable ──> . ───> field-name ─────>

 Allows you to name a specific field or group of fields you want moved
 to the target database.  You can specify only one SELECT clause for
 each MOVE clause.  Data Distributor moves only the named fields to
 the target database.  If you do not specify SELECT FIELDS ALL, the
 select-field-name clause is required.

 Data Distributor supports COMPUTED_BY fields named in the
 select-field-name clause if the fields are defined using the value
 expressions shown in the value-expr syntax diagram in this section.
 If the fields are not defined by a supported value expression, you
 will receive a fatal error message.

 transfer-file-options-clause

   ─┬─┬─────────────────────────>───────────────────────────┬───────>
    │ ├──> 
P
R
O
L
O
G
U
E Ftypebox (I)typebox (L)typebox (E) typebox (I)typebox (S) ────> prologue-file-spec ───────┤
    │ ├──> 
N
O
P
R
O
L
O
G
U
E ──────────>───────────────────────────┤
    │ ├──> 
E
P
I
L
O
G
U
E Ftypebox (I)typebox (L)typebox (E) typebox (I)typebox (S) ────> epilogue-file-spec ───────┤
    │ ├──> 
N
O
E
P
I
L
O
G
U
E ──────────>───────────────────────────┤
    │ ├──> 
L
O
G Ftypebox (I)typebox (L)typebox (E) 
I
S ─────────> log-file-spec ────────────┤
    │ └──> 
N
O
L
O
G ───────────────>───────────────────────────┤
    └───────────────────────────<───────────────────────────┘

 The DCL command procedures to be executed before or after transfers
 and the VMS file where logging information related to the transfer
 execution is located.

Additional information available:

prologue-file-specepilogue-file-speclog-file-spec

 The name of the prologue command procedure file to be run before the
 transfer executes.  This file runs at the beginning of the first
 execution of the transfer and of all subsequent transfers.  The
 prologue file is a DCL command file.  You can include a version
 number and a remote node name in the file specification.  The name is
 resolved when the transfer is defined.

 The prologue-file-spec parameter is optional.  If you do not include
 this parameter, Data Distributor assumes that NOPROLOGUE is in
 effect.  The default file type is .COM.  The default directory for
 the prologue file is SYS$LOGIN.

 The name of the epilogue command procedure file to be run after the
 transfer executes.  This file runs after the first execution of the
 transfer and after all subsequent transfers.  The epilogue file is a
 DCL command file.  You can include a version number or a remote node
 name in the file specification.  The name is resolved when the
 transfer is defined.

 The epilogue-file-spec parameter is optional.  If you do not include
 this parameter, Data Distributor assumes that NOEPILOGUE is in
 effect.  The default file type is .COM.  The default directory for
 the epilogue file is SYS$LOGIN.

 The VMS file where the Data Distributor copy process writes any
 logging information related to the execution of the transfer.  If you
 include a version number or a node name in the file specification,
 Data Distributor returns an error.  Data Distributor creates a new
 log file every time a transfer executes.  The name is resolved when
 the transfer is defined.

 The log-file-spec parameter is optional.  If you do not include this
 parameter, Data Distributor assumes that NOLOG is in effect.  The
 default file type is .LOG.  The default directory for the log file is
 SYS$LOGIN.

 rse =

 ──┬────────>────────┬──> relation-clause ──>────────────────────┐
   └─> first-clause ─┘                                           │
 ┌───────────────────────────────────────────────────────────────┘
 └┬───────>────────┬─┬────────>──────────┬──┬────────>────────┬───>
  └─> with-clause ─┘ └─> reduce-clause ──┘  └─> sort-clause ──┘

 The record selection expression (RSE) used to identify records from
 the source database that Data Distributor includes in a record stream
 and transfers to the target database.  The RSE specifies conditions
 that individual records must satisfy in order to be included in the
 transfer to the target database.

 Data Distributor supports COMPUTED_BY fields named in an RSE if the
 fields are defined using the value expressions shown in the
 value-expr syntax diagram in this section.  If the fields are not
 defined by a supported value expression, you will receive a fatal
 error message.

 In extraction, extraction rollup, and replication transfers, you can
 use a relation-clause and with-clause.  In extraction and extraction
 rollup transfers, you can also use a first-clause, reduce-clause, and
 sort-clause.

Additional information available:

first-clauserelation-clausewith-clausereduce-clausesort-clause

 first-clause =

 ────> 
F
I
R
S
T ──────> value-expr ───────────>

 value-expr =

    ───────┬────> database-field ──────┬──>
           ├────> quoted-string ───────┤
           ├────> numeric-literal ─────┤
           ├────> arithmetic-expr ─────┤
           ├────> missing-value ───────┤
           ├────> concat-expr ─────────┤
           ├────> ( value-expr ) ──────┤
           └────> ─  ──> value-expr ───┘

 Specifies how many records are selected from the record stream formed
 by the record selection expression (RSE).  You can only use the
 first-clause for an extraction or an extraction rollup transfer.  If
 you specify a first-clause for a replication transfer, Data
 Distributor issues an error message.

 relation-clause =

 ─> context-variable ─> 
I
N ┬────────>────────┬─> relation-name ─>
                           └> db-handle ─> . ┘

 The context variables and relations to be included in the record
 stream or loop.

 If you specify a view name in the relation-clause, the moved view
 becomes a relation in the target database.

 The context-variable supplies a temporary name to identify the record
 stream.  Once you have associated a context-variable with a relation,
 you use the context-variable to refer to fields from that relation.

 The db-handle is a host variable or name used to refer to a specific
 database you have invoked.

 In extraction or replication transfers, you should not use database
 handles in the RSE of a MOVE RELATION clause.  Data Distributor
 returns an error message if you include a database handle in the RSE.
 However, in an extraction rollup transfer, you must use database
 handles in the RSE to specify the relation or Data Distributor will
 return an error message.

 with-clause =

 ─────────────> 
W
I
T
H ──────────> conditional-expr ───────────>

 conditional-expr =

  ─┬───> conditional-expr ──> 
A
N
D ──> conditional-expr ───┬───>
   ├───> conditional-expr ──> 
O
R ───> conditional-expr ───┤
   ├────────────────────────> 
N
O
T ──> conditional-expr ───┤
   ├───> value-expr1 ──> rel-oper ──> value-expr2 ────────┤
   ├───> between-clause ──────────────────────────────────┤
   ├───> containing-clause ───────────────────────────────┤
   ├───> matching-clause ─────────────────────────────────┤
   ├───> starting-with-clause ────────────────────────────┤
   └───> missing-clause ──────────────────────────────────┘

 The with-clause contains a conditional expression that allows you to
 specify conditions that must be true for a record to be included in a
 record stream.

 reduce-clause =

 ──────────────> 
R
E
D
U
C
E
D 
T
O ───┬─────> value-expr ───┬─────>
                               └──────── , <─────────┘

 value-expr =

    ───────┬────> database-field ──────┬──>
           ├────> quoted-string ───────┤
           ├────> numeric-literal ─────┤
           ├────> arithmetic-expr ─────┤
           ├────> missing-value ───────┤
           ├────> concat-expr ─────────┤
           ├────> ( value-expr ) ──────┤
           └────> ─  ──> value-expr ───┘

 Allows you to eliminate duplicate values for fields in a record
 stream.  You can use the reduce-clause for an extraction or an
 extraction rollup transfer.  If you specify a reduce-clause for a
 replication transfer, Data Distributor issues an error message.

 sort-clause =

 ───> 
S
O
R
T
E
D 
B
Y ──┬─┬──────────────────┬─────> value-expr ──┬───>
                  │ ├──> 
A
S
C
E
N
D
I
N
G ────┤                    │
                  │ └──> 
D
E
S
C
E
N
D
I
N
G ───┘                    │
                  └────────────────────── , <───────────────┘

 value-expr =

    ───────┬────> database-field ──────┬──>
           ├────> quoted-string ───────┤
           ├────> numeric-literal ─────┤
           ├────> arithmetic-expr ─────┤
           ├────> missing-value ───────┤
           ├────> concat-expr ─────────┤
           ├────> ( value-expr ) ──────┤
           └────> ─  ──> value-expr ───┘

 Allows you to sort the records in the record stream by the values of
 specific fields.  You can sort the records according to a value
 expression called a sort key.  The sort key determines the order of
 the records in the record stream.  You can use the sort-clause for an
 extraction or an extraction rollup transfer.  If you specify a
 sort-clause for a replication transfer, Data Distributor issues an
 error message.

 Specifying ASCENDING (the default) causes the records to be sorted in
 ascending order.  Specifying DESCENDING causes Rdb/VMS to sort the
 records in descending order.

 The value expression specifies the sort value.  This value is called
 the sort key.

 You need the Rdb/VMS WRITE privilege for the transfer relation to use
 the DEFINE TRANSFER statement.

 You must have the Rdb/VMS READ privilege for the relations and views
 of an Rdb/VMS source database that you specify in a DEFINE TRANSFER
 statement.  Data Distributor returns an error message when you
 specify relations and views in a DEFINE TRANSFER statement for which
 you do not have READ privilege.  If you specify a VIDA database, Data
 Distributor does not check for READ privilege for the relations and
 views.

 You must execute the DEFINE TRANSFER statement outside of the scope
 of a transaction.  If you issue this statement when a transaction is
 outstanding, Data Distributor returns an error message.

 You can refer to relations, fields, and views in a DEFINE TRANSFER
 statement either implicitly or explicitly.  When you include either
 the MOVE RELATIONS ALL, SELECT FIELDS ALL, or MOVE VIEWS ALL clause,
 you refer to relations, fields, or views implicitly.  Data
 Distributor uses the current definitions of the relations, fields,
 and views in the source database and stores those names explicitly in
 the transfer definition.  You refer to relations, fields, and views
 explicitly when you include the MOVE RELATION, SELECT FIELDS, or MOVE
 VIEWS clauses and supply specific relation, field, or view names.

 Data Distributor transfers those COMPUTED_BY fields that depend only
 on the values of a relation in which the field is defined.  You
 cannot transfer views that contain unsupported COMPUTED_BY fields.
 If views that contain unsupported COMPUTED_BY fields are specified in
 the move-views-clause of a DEFINE TRANSFER statement, the transfer
 definition fails.  You need to redefine the transfer, excluding the
 views that refer to the unsupported COMPUTED_BY fields.

 Data Distributor allows you to transfer views in two ways:

  o  Using the move-views-clause

     Data Distributor transfers the definition of the view when you
     specify MOVE VIEWS view-name or MOVE VIEWS ALL.  You must also
     explicitly or implicitly name in the DEFINE TRANSFER statement
     all the relations, views, or fields on which the transferred view
     definitions are based.  The transfer will fail if any underlying
     relations, views, or fields are not named.
  o  Using the move-relations-clause

     Data Distributor transfers a view by creating a relation in the
     target database containing the view's records when you use the
     MOVE RELATION clause.  This method improves query performance in
     the target database.  For example, you can achieve the effect of
     a CROSS clause by transferring a view that is a CROSS in the
     source.


 You specify the relations you wish to move in the
 move-relations-clause and the views in the move-views-clause of the
 DEFINE TRANSFER statement.  When you are doing an extraction rollup
 transfer, you specify the relations you wish to move in the
 move-relations-rollup-clause of the DEFINE TRANSFER statement.

 The same clause can occur in a DEFINE TRANSFER statement no more than
 once.  You cannot specify the same relation or view more than once in
 the move clauses.  If a relation name or view name appears in more
 than one move clause, Data Distributor returns an error.

 Individual move-relations clauses are separated by semicolons, as
 indicated in the syntax diagrams.  You can implement the
 move-relations-clause in two ways:

  o  Specify MOVE RELATIONS ALL
  o  Specify a series of relations separated by semicolons


 The move-relations-clause has the following characteristics and
 limitations:

  o  All fields in each move-relations-clause must reside in the same
     relation.
  o  You cannot name the same relation in more than one MOVE clause of
     a single transfer definition.


 The move-relations-rollup-clause has the following characteristics
 and limitations:

  o  All fields in each move-relations-rollup-clause must reside in
     the same relation.
  o  You cannot name the same relation in more than one MOVE clause of
     a single transfer definition.
  o  For each relation of a move-relations-rollup-clause that you
     enter, you can supply a target relation specification in the form
     of an INTO RELATION clause.  You can create one or many relations
     in the target database from several source database relations by
     renaming the target relations in the transfer definition.
  o  You cannot specify MOVE RELATIONS ALL or SELECT FIELDS ALL in a
     move-relations-rollup-clause.  When you specify these clauses in
     the DEFINE TRANSFER statement, the transfer will fail at the time
     of definition.


 If a transfer fails during execution, the transfer will begin again
 at one of the two following times:

  o  The next scheduled retry time if the failure results from a
     nonfatal error
  o  The next scheduled transfer time if the failure results from a
     fatal error


 This next transfer will start from the beginning to ensure
 consistency with any updates that might have been made to the source
 database.

 Data Distributor transfers only definitions for the database, fields,
 and relations specified in the transfer definition.  If the source
 database includes additional database entities such as indexes,
 constraints, or access control lists, these are not transferred to
 the target database.  You must either directly access the individual
 target database and explicitly define these entities or run command
 procedures to define the entities after the transfer executes.

 When relations specified in the transfer definition are created in
 the target database, they are given the access control lists (ACLs)
 that have the Rdb/VMS default values.  You can change the ACLs in the
 target database after it has been created.

 In a transfer definition, you can use logical symbol names to name
 the source database file, the target database file, the copy process
 log file, and the prologue and the epilogue command procedure files.
 However, Data Distributor treats these file names differently:

  o  Source database file logical names

     If the source file name is a logical symbol that translates to a
     standard VMS file name specification, Data Distributor performs
     the logical name translation.  The SHOW TRANSFER DEFINITION
     statement shows the source file name in its translated form.  The
     logical symbol can also translate into strings that, in turn,
     contain logical symbols.  As long as the resulting string looks
     like a VMS file specification and the logical symbol is not a
     concealed device name, the translation process is repeated.

     If the logical symbol translates into a VIDA access string (for
     example, /TYPE=VIDA/FILE=ACCESS_FILE/...), Data Distributor does
     no further translations.  Even if the VIDA name string contains
     logical symbol references, these references are not translated
     into VMS file specifications.  You can use a logical name in
     place of the string to identify a VIDA database.

  o  Target database file logical name

     If the target database name is a logical name, it is not
     translated by Data Distributor when it is stored in the transfer
     definition.

  o  Copy process log file logical name

     Data Distributor translates the log file logical name in the same
     way as source file logical names, with the following exceptions:

      o  The log file specification is translated in RDO when the
         DEFINE TRANSFER statement is executed.

      o  These log file names must be standard VMS file
         specifications.  Node names or version numbers are not
         allowed.


  o  Prologue and epilogue command procedure file logical names

     Data Distributor translates the prologue and epilogue file
     logical names in the same way as the source file logical name,
     with the following exceptions:

      o  The prologue and epilogue file specifications are translated
         in RDO when the DEFINE TRANSFER statement is executed.

      o  The log file names must be standard VMS file specifications.
         Node names and version numbers are allowed.

 Example 1

 The following example defines a transfer, NH_EMPLOYEES, that creates
 an extraction database.  The transfer definition selects New
 Hampshire employees' address records for transfer to the remote node.

 RDO> INVOKE DATABASE FILENAME PERSONNEL
 RDO> DEFINE TRANSFER NH_EMPLOYEES EXTRACTION
 cont>  DESCRIPTION IS /* Employees who live in New Hampshire */
 cont>  TO NODE1::DISK1:[ADAMS]NH_EMP
 cont>  MOVE RELATION E IN EMPLOYEES WITH E.STATE = "NH"
 cont>  SELECT FIELDS E.EMPLOYEE_ID,
 cont>     E.LAST_NAME,
 cont>     E.FIRST_NAME,
 cont>     E.MIDDLE_INITIAL,
 cont>     E.ADDRESS_DATA_1,
 cont>     E.ADDRESS_DATA_2,
 cont>     E.CITY,
 cont>     E.STATE,
 cont>     E.POSTAL_CODE
 cont>  LOG IS NH_EMPLOYEES.LOG
 cont>  END.


 Example 2

 This example shows an extraction from a remote source database to a
 local target database.  The DEFINE TRANSFER statement specifies the
 transfer of all personnel records to the target node.

 RDO> INVOKE DATABASE FILENAME NODE1::DISK1:[DIR1]PERSONNEL
 RDO> DEFINE TRANSFER PERS_EXAMP EXTRACTION
 cont>  DESCRIPTION IS /* Extraction of personnel records*/
 cont>  TO [LEARNER.PERS]PERS_COPY
 cont>  MOVE RELATIONS ALL
 cont>  LOG IS [LEARNER.PERS]PERS_EXAMP.LOG
 cont>  END.


 Example 3

 This example shows an extraction transfer from a remote source to a
 remote target database.  The log file, PERS_EXAMP.LOG, is located on
 the source node.

 RDO> INVOKE DATABASE FILENAME NODE1::DISK1:[DIR1]PERSONNEL
 RDO> DEFINE TRANSFER PERS_EXAMP EXTRACTION
 cont>  DESCRIPTION IS /* Extraction of personnel records*/
 cont>  TO NODE2::DISK2:[PROTO]PERS_TARGET
 cont>  MOVE RELATIONS ALL
 cont>  LOG IS PERS_EXAMP.LOG
 cont>  END.


 Example 4

 This example of a replication transfer definition sends the entire
 colleges relation and the entire degrees relation to the target
 database.  The replication database can be accessed for information
 about employees' college and degree histories.  The transfer
 definition includes some database parameters for the target database.

 RDO> INVOKE DATABASE FILENAME PERSONNEL
 RDO> DEFINE TRANSFER COLLEGE_INFO REPLICATION
 cont>  DESCRIPTION IS /* Info about employees' colleges only */
 cont>  TO NODE1::DISK1:[BURTON]EMP_COLLEGE
 cont>  NUMBER OF USERS IS 25
 cont>  SNAPSHOT ALLOCATION IS 150 PAGES
 cont>  MOVE RELATION C IN COLLEGES
 cont>  SELECT FIELDS ALL;
 cont>  MOVE RELATION D IN DEGREES
 cont>  SELECT FIELDS ALL
 cont>  LOG IS COLLEGE_INFO.LOG
 cont>  END.


 Example 5

 This replication transfer specifies three fields from the
 CREDIT_CARDS source database for transfer to the target database.
 The fields are CARD_NUM, EXPIRATION_DATE, and VALID.  Only invalid
 credit card records are selected for the transfer.

 RDO> INVOKE DATABASE FILENAME CREDIT_CARDS
 RDO> DEFINE TRANSFER BAD_CARDS REPLICATION
 cont>  DESCRIPTION IS /* Invalid credit cards */
 cont>  TO NODE1::DISK1:[CREDIT]BAD_CARDS
 cont>  MOVE RELATION C IN CARDS WITH C.VALID = "N"
 cont>  SELECT FIELDS C.CARD_NUM,
 cont>     C.EXPIRATION_DATE,
 cont>     C.VALID
 cont>  LOG IS BAD_CARDS.LOG
 cont>  END.


 Example 6

 The following example defines a replication transfer that sends the
 entire EMPLOYEES, JOB_HISTORY, SALARY_HISTORY, DEPARTMENTS, and JOBS
 relations.  The definition also selects three views for transfer:
 CURRENT_INFO, CURRENT_JOB, and CURRENT_SALARY.

 RDO> INVOKE DATABASE FILENAME PERSONNEL
 RDO> DEFINE TRANSFER NH_PERSONNEL REPLICATION
 cont> TO NODE1::DISK1:[DBADMIN]NHP.RDB
 cont>   MOVE RELATION E IN EMPLOYEES        SELECT FIELDS ALL;
 cont>   MOVE RELATION JH IN JOB_HISTORY     SELECT FIELDS ALL;
 cont>   MOVE RELATION SH IN SALARY_HISTORY  SELECT FIELDS ALL;
 cont>   MOVE RELATION D IN DEPARTMENTS      SELECT FIELDS ALL;
 cont>   MOVE RELATION J IN JOBS             SELECT FIELDS ALL
 cont>   MOVE VIEWS CURRENT_INFO, CURRENT_JOB, CURRENT_SALARY
 cont> LOG FILE IS DISK1:[DBADMIN]NHP.LOG
 cont> END.


 Example 7

 The following example moves the CURRENT_JOB view defined in the
 source database as a CROSS of the EMPLOYEES relation and the
 JOB_HISTORY relation.  You can achieve the effect of a CROSS clause
 by transferring a view that is a CROSS in the source database.  On
 the target database, the records selected by the view are created as
 a relation.

 RDO> INVOKE DATABASE FILENAME PERSONNEL
 RDO> DEFINE TRANSFER CJOB EXTRACTION
 cont>  TO NODE1::DISK1:[RAMESH]JOB_DB
 cont>  MOVE RELATION C IN CURRENT_JOB WITH C.JOB_CODE = "SEII"
 cont>     SELECT FIELDS C.LAST_NAME, C.FIRST_NAME, C.ADDRESS
 cont>  LOG FILE IS CJOB.LOG
 cont>  END TRANSFER.



 Example 8

 The following example shows an extraction rollup transfer that
 invokes several source databases:  PERSONNEL, WORKERS, and STAFF.
 The transfer selects fields in the EMPLOYEES relations from the three
 databases identified by the database handles DB1, DB2, and DB3 and
 located on three different nodes and in the JOBS relation from DB1.
 Then the transfer moves these relations to a single target database,
 LOCAL_DB.

 RDO> INVOKE DATABASE DB1=FILENAME "NODE1::DISK1:[DIR1]PERSONNEL"
 RDO> INVOKE DATABASE DB2=FILENAME "NODE2::DISK2:[DIR2]WORKERS"
 RDO> INVOKE DATABASE DB3=FILENAME "NODE3::DISK3:[DIR1]STAFF"
 RDO> DEFINE TRANSFER LABOR EXTRACTION ROLLUP
 cont>  TO NODE4::DISK4:[DIR4]LOCAL_DB
 cont>  MOVE RELATION E IN DB1.EMPLOYEES WITH E.EMP_CODE= "A+"
 cont>    INTO RELATION EXEMPT_EMPLOYEES
 cont>      SELECT FIELDS E.EMP.ID,E.SALARY,E.JOB_CODE;
 cont>  MOVE RELATION E IN DB2.EMPLOYEES WITH E.EMP_CODE= "A+"
 cont>    INTO RELATION EXEMPT_EMPLOYEES
 cont>      SELECT FIELDS E.EMP_ID,E.SALARY,E.JOB_CODE;
 cont>  MOVE RELATION E IN DB3.EMPLOYEES WITH E.EMP_CODE= "A+"
 cont>    INTO RELATION EXEMPT_EMPLOYEES
 cont>      SELECT FIELDS E.EMP.ID,E.SALARY,E.JOB_CODE;
 cont>  MOVE RELATION J IN DB1.JOBS WITH J.JOB_CODE= "J17"
 cont>    INTO RELATION ENTRY_JOBS
 cont>      SELECT FIELDS J.JOB_NAME,J.JOB_CODE
 cont>  LOG FILE IS DISK4:[DIR4]LOCAL.LOG
 cont>  END.


 Example 9

 The following EMPLOYEES transfer creates an extraction database.  The
 transfer selects records using a first-clause, with-clause,
 reduce-clause, and sort-clause.

 RDO> INVOKE DATABASE FILENAME PERSONNEL
 RDO> DEFINE TRANSFER EMPLOYEES EXTRACTION
 cont>   TO NODE1::DISK1:[NELSON]EMPLOYEES_INFO
 cont>   MOVE RELATION FIRST 10 E IN EMPLOYEES
 cont>     WITH E.CITY = "BOSTON"
 cont>     REDUCED TO E.LAST_NAME, E.FIRST_NAME, E.ADDRESS
 cont>     SORTED BY DESCENDING E.LAST_NAME
 cont>   SELECT FIELDS E.LAST_NAME, E.FIRST_NAME, E.ADDRESS
 cont> LOG FILE IS DISK1:[NELSON]EMPLOYEES.LOG
 cont> END TRANSFER.



 Example 10

 The following extraction transfer includes two command files.  The
 prologue command procedure establishes a connection to a remote node,
 and the epilogue command procedure terminates the connection.  This
 example shows how to specify the prologue file and epilogue file; it
 does not show the command procedures.

 RDO> INVOKE DATABASE FILENAME NODE1::DISK1:[DBADMIN.PERS]PERSONNEL
 RDO> DEFINE TRANSFER PERS_SAMPLE EXTRACTION
 cont>  TO PERS_COPY
 cont>  MOVE RELATIONS ALL
 cont>  PROLOGUE FILE IS DIALUP.COM
 cont>  EPILOGUE FILE IS HANGUP.COM
 cont>  LOG IS PERS_SAMPLE.LOG
 cont>  END.

 Creates a schedule definition and stores it in the transfer database.
 The schedule definition specifies when and how often a transfer
 should execute.  A transfer can have only one schedule definition
 associated with it.  Data Distributor returns an error if you attempt
 to define a schedule for a transfer that already has one.

Additional information available:

FormatMoreExamples

 DEFINE SCHEDULE ──> Ftypebox (O)typebox (R) ──> transfer-name ───┐
 ┌────────────────────────────────────────────┘
 └───┬─────────────────────────────────┬─┐
     └──> 
S
T
A
R
T ──> start-date-time ───┘ │
 ┌───────────────────────────────────────┘
 └───┬─────────────────────────────────────────┬─┐
     └──> 
E
V
E
R
Y ──┬─> every-delta-time ─────┬──┘ │
                  └─> every-absolute-time ──┘    │
 ┌───────────────────────────────────────────────┘
 └─┬─────────────────────────────────────────────────────────────┬─┐
   └─> 
R
E
T
R
Y ─> count ─> 
T
I
M
E
S ─┬───────────────────────────────┬┘ │
                                └─> 
R
E
T
R
Y 
E
V
E
R
Y ──> delta-time ─┘  │
 ┌─────────────────────────────────────────────────────────────────┘
 └──> 
E
N
D ─┬───────────────────┬─┬─────────────┬───>  .
           └──> transfer-name ─┘ └─> typebox (S)typebox (C)typebox (H)typebox (E)typebox (D)typebox (U)typebox (L)typebox (E) ─┘

Additional information available:

transfer-namestart-date-timeevery-delta-timeevery-absolute-time
countdelta-time

 The transfer for which this schedule is being defined.  The transfer
 must already exist when you create a schedule definition for it.  The
 transfer-name parameter is required.

 The time to execute the initial transfer.  You can specify an
 absolute or delta time.  If you supply an absolute time, the initial
 transfer will be executed at the time specified.  If you use a delta
 time, Data Distributor uses the current time and the delta-time value
 to calculate the actual transfer time.  The START clause is optional.
 If you do not include a START clause, the start time is set to the
 current time so that the transfer will execute as soon as the
 transfer schedule definition is processed.

 The start-date-time parameter uses the following absolute and
 delta-time formats.  You can omit any of the trailing fields in the
 date or time.  You can omit any of the fields in the middle of the
 format as long as you include the punctuation marks.  For more
 information on date and time formats, see the entry on the $BINTIM
 VMS system service in the VMS documentation set.

 Absolute-time

 dd-mmm-yyyy hh:mm:ss.cc

 Delta time

 dddd:hh:mm:ss.cc

 In the absolute and delta time designations, the abbreviations have
 the following meanings:

 dddd   Number of days
 dd     Day of the month
 mmm    Month
 yyyy   Year
 hh     Hours
 mm     Minutes
 ss     Seconds
 cc     Hundredths of a second

 Used to calculate the time to execute the next transfer.  The EVERY
 clause is optional.  If you specify the EVERY clause, you must
 specify either every-delta-time or every-absolute-time.  If you omit
 the EVERY clause, the transfer occurs only once.

 The valid specification for every-delta-time is the delta format used
 by the $BINTIM VMS system service.  The delta time you specify is the
 time from the completion of the last transfer sequence until the
 start of the next one.  A transfer sequence is the set of transfers
 from the first attempt until one of the following conditions is met:
 the execution is successful, the maximum number of retries specified
 in the RETRY clause has been reached, or a fatal error has occurred
 (one for which retries are not attempted).

 every-absolute-time =

   ─────┬──────> 
D
A
Y ──────┬──┬───────────>─────────┬─┬───>
        ├──────> 
W
E
E
K ─────┤  └──> 
A
T ──> at-time ──┘ │
        ├──────> 
M
O
N
T
H ────┘                          │
        └──┬───> weekday ───┬──────────>────────┬──┬──┘
           │                └─> 
A
T ──>at-time ──┘  │
           └──────────────── , <───────────────────┘

 Used to calculate the time to execute the next transfer.  The EVERY
 clause is optional.  If you specify the EVERY clause, you must
 specify either every-absolute-time or every-delta-time.  If you omit
 the EVERY clause, the transfer occurs only once.

Additional information available:

DAYWEEKMONTH

weekdayat-time

 The transfer executes on a daily basis.

 The transfer occurs every week on the same day of the week as the
 initial transfer.

 The transfer occurs on a monthly cycle on the same day of the month
 as the initial transfer.

 Note that if the initial transfer starts on the 31st of the month and
 the transfer schedule specifies EVERY MONTH, the next execution of
 the transfer will be on the last day of the following month, whether
 the last day is the 28th, 29th, 30th, or 31st.

 The transfer executes on the weekdays that you list.  If you list
 more than one weekday, separate the days with commas.  Valid weekday
 specifications are:

 SUNDAY
 MONDAY
 TUESDAY
 WEDNESDAY
 THURSDAY
 FRIDAY
 SATURDAY

 Qualifies every-absolute-time by specifying the time of day at which
 the transfer should occur.  This parameter is optional.  If you
 specify DAY, WEEK, or MONTH, but do not specify an at-time, Data
 Distributor uses the time of day of the initial transfer.  In the
 case of a list of weekdays, the at-time for each day can be
 specified.  If the at-time for any weekday is not specified, the
 default is the time used for the previous entry in the list.  For the
 first entry in the list, the time of day of the initial transfer is
 used, if none is specified.

 The maximum number of times to retry a transfer if a transfer
 execution fails.  If you do not include a retry count or if the count
 value is set to zero, Data Distributor does not attempt to retry the
 transfer until the next scheduled transfer time as indicated by the
 EVERY clause.

 Data Distributor does not retry a transfer if the transfer failed as
 a result of a fatal error.  You can recover from a fatal error only
 by manual intervention.

 The length of time Data Distributor waits between the time of the
 last failed attempt and the time of the next retry attempt.  The
 RETRY EVERY delta-time clause is optional and can only be specified
 if the RETRY count TIMES clause is included.

 If you specify RETRY count TIMES in the schedule definition, but do
 not specify RETRY EVERY delta-time, Data Distributor attempts the
 retry immediately.  See the description of the start-date-time
 parameter earlier in this section for valid delta-time values.

 To define a transfer schedule, you must have the same user
 identification code (UIC) as the user who defined the transfer.  If
 you define a schedule for a transfer defined by a user with a
 different UIC, Data Distributor returns an error message and prevents
 the schedule from executing.  If you have BYPASS privilege, you can
 define a schedule for a transfer associated with a different UIC.  In
 this case, the UIC associated with the transfer does not change.

 When you define a schedule for a transfer in the unscheduled state,
 that transfer is placed in the scheduled state.  If the transfer is
 in the suspended state, it remains in the suspended state.  To place
 the suspended transfer in the scheduled state, use the START TRANSFER
 statement.  When the transfer executes, Data Distributor places the
 transfer in the active state.

 You cannot modify a schedule definition.  If you need to change a
 parameter value in a schedule definition, you must first delete the
 schedule using the DELETE SCHEDULE statement and then define a new
 schedule.

 You must execute the DEFINE SCHEDULE statement outside of the scope
 of a transaction.  If you issue this statement when a transaction is
 outstanding, Data Distributor returns an error message.

 Example 1

 Executes the NH_EMPLOYEES transfer at 1:24 a.m.  on June 24, 1988.
 The transfer will then execute every day at 5:30 p.m.  If a nonfatal
 error occurs, the transfer execution will be retried three times with
 30 minutes between the end of the failed transfer execution and the
 start of the next one.

 RDO> DEFINE SCHEDULE FOR NH_EMPLOYEES
 cont>  START 24-JUN-1988 01:24:00.00       <---- Absolute time
 cont>     EVERY DAY AT 17:30               <---- Absolute time
 cont>     RETRY 3 TIMES
 cont>     RETRY EVERY 0 00:30:00
 cont>  END SCHEDULE.


 Example 2

 This example uses a delta-time specification to have 36 hours (1 day
 plus 12 hours) between the completion of one transfer execution and
 the beginning of the next.  The example uses two delta times, EVERY 1
 12:00 and RETRY EVERY 0 03:00:00.  EVERY 1 12:00 states that there
 will be 36 hours (1 day plus 12 hours) between the completion of the
 first transfer and the beginning of the next.  If transfer execution
 does not succeed on the first attempt, the transfer schedule permits
 Data Distributor to make up to five additional attempts to complete
 the transfer.  RETRY EVERY 0 03:00:00 means Data Distributor should
 retry the transfer three hours after a nonfatal failure until the
 transfer completes successfully or until the maximum of five retries
 has been attempted.  If the transfer does not complete successfully
 after five retries, the next attempt will be 36 hours after the last
 failed attempt.

 RDO> DEFINE SCHEDULE FOR NH_EMPLOYEES
 cont>  START 15-MAY-1988
 cont>  EVERY 1 12:00                  !<---- 1 day plus 12 hours
 cont>  RETRY 5 TIMES
 cont>  RETRY EVERY 0 03:00:00         !<---- 3 hours
 cont>  END.



 Example 3

 The following transfer schedule causes Data Distributor to execute a
 transfer for the first time at 12 noon on the 15th of October 1988.
 Subsequent transfers will occur every day thereafter at 5:30 p.m.  If
 an error occurs preventing a successful transfer, Data Distributor
 will retry every 30 minutes until the transfer is successful or the
 maximum of three retries has been reached.


 RDO> DEFINE SCHEDULE FOR NH_EMPLOYEES
 cont>  START 15-OCT-1988  12:00
 cont>     EVERY DAY AT 17:30             !<---- Every day
 cont>     RETRY 3 TIMES
 cont>     RETRY EVERY 0 00:30:00
 cont>  END SCHEDULE.

 Example 4

 The following schedule definition assumes that you want to execute
 the transfer immediately after you complete the schedule definition
 and, therefore, it contains no START clause.  If the system time is
 20-OCT-1988 16:00:00 when you complete the DEFINE SCHEDULE statement,
 the next execution of the NH_EMPLOYEES transfer will start on
 20-NOV-1988 16:00:00.

 RDO> DEFINE SCHEDULE FOR NH_EMPLOYEES
 cont>   EVERY MONTH
 cont>   RETRY 3 TIMES
 cont>   RETRY EVERY 0 00:30:00
 cont>  END.


 Example 5

 This example calls for the NH_EMPLOYEES transfer to execute at 3:00
 p.m.  every Wednesday.  The schedule definition calls for a maximum
 of three retries occurring at intervals of 30 minutes.

 RDO> DEFINE SCHEDULE FOR NH_EMPLOYEES
 cont>  START 12-NOV-1988 15:00:00.00
 cont>     EVERY WEDNESDAY AT 15:00:00     !<---- Wednesdays at 3 p.m.
 cont>     RETRY 3 TIMES
 cont>     RETRY EVERY 0 00:30:00
 cont>  END.

 Example 6

 The following example causes an initial transfer to execute on the
 15th of July at 5 p.m., on every Monday after the 15th at 5 p.m.,
 every Tuesday at 11 a.m., and every Friday at 11 a.m.  Because a
 RETRY clause is not specified, even if a nonfatal failure occurs, the
 transfer will not execute until the next regularly scheduled time.

 RDO> DEFINE SCHEDULE FOR NH_EMPLOYEES
 cont>   START 15-JUL-1988 17:00
 cont>   EVERY MONDAY, TUESDAY AT 11:00, FRIDAY
 cont>  END.


 Example 7

 This example causes a transfer to start at midnight on July 15th and
 on the 15th of every month thereafter at 7 p.m.

 RDO> DEFINE SCHEDULE FOR NH_EMPLOYEES
 cont>   START 15-JUL-1988
 cont>   EVERY MONTH AT 19:00
 cont>  END.

 Reinitializes a replication transfer.  You use this statement when
 the source database and the replication target database are no longer
 consistent with each other.

Additional information available:

FormatMoreExample

 REINITIALIZE TRANSFER ──────> transfer-name ───>

Additional information available:

transfer-name

 The replication transfer that you want to reinitialize.  The
 transfer-name parameter is required.

 If you want to reinitialize a particular transfer, the transfer
 definition must be associated with your UIC.

 You can reinitialize a transfer only when the transfer is in the
 suspended state.  To suspend a transfer, first issue a STOP TRANSFER
 statement.  You must execute the REINITIALIZE TRANSFER statement
 outside the scope of a transaction.  If you issue this statement when
 a transaction is outstanding, Data Distributor returns an error
 message.

 After you enter the REINITIALIZE statement, the transfer remains in
 the suspended state.  You must then issue a START TRANSFER statement
 to restart the transfer.

 The REINITIALIZE statement forces the next execution of a replication
 transfer to create a new replication database in the target
 directory.  You must reinitialize a transfer when someone restores a
 previous version of the source database.

 This example places the CARS_LAX transfer in a suspended state and
 then reinitializes it.  The schedule and definition for this
 replication transfer remain in place.  Once the transfer has been
 reinitialized, you can restart it.

 RDO> STOP TRANSFER CARS_LAX
 RDO> REINITIALIZE TRANSFER CARS_LAX
 RDO> START TRANSFER CARS_LAX

 Executes a transfer on demand, or changes the state of a transfer
 from the suspended state to the scheduled, unscheduled, or active
 state.

Additional information available:

FormatMoreExamples

 START TRANSFER ─────> transfer-name ──┐
    ┌──────────────────────────────────┘
    └───┬────────────>──────────────┬────>
        └───> 
N
O
W ──┬────────────┬──┘
                    ├─> 
W
A
I
T ────┤
                    └─> 
N
O
W
A
I
T ──┘

Additional information available:

NOWWAIT_NOWAIT

transfer-name

 The transfer to be started.  The transfer-name parameter is required.

 Changes the transfer state to active and begins execution.  If the
 transfer has a schedule defined for it, subsequent transfers occur as
 specified by that schedule.  The NOW argument is optional.

 Specifies whether Data Distributor returns control to RDO immediately
 after the transfer starts or waits until the transfer completes.  You
 must use the NOW argument if you specify WAIT or NOWAIT.  The
 default, NOWAIT, causes Data Distributor to return control
 immediately to the RDO command mode while the transfer executes.
 With NOWAIT in effect, you can enter other RDO statements while the
 copy process completes the transfer of database records to the target
 database.

 The WAIT option ensures that the transfer completes before control is
 returned to RDO.

 You can use the START TRANSFER statement without any qualifiers to
 change the state of a suspended transfer.  Issuing the START TRANSFER
 statement places the transfer in the scheduled state if a schedule
 definition exists for the transfer.  Execution then occurs at the
 next scheduled time.  If a schedule definition does not exist, the
 transfer is placed in the unscheduled state and will execute only
 when you issue a START TRANSFER statement using the NOW qualifier or
 you define a schedule for the transfer.

 You cannot enter the START TRANSFER statement when a transaction is
 outstanding.  You must terminate any outstanding transactions before
 issuing the START TRANSFER statement.

 You can use the START TRANSFER statement to initiate a transfer on
 demand by including the NOW option.  The NOW option immediately
 places the transfer in the active state.  This execute-on-demand
 feature is useful in batch processing environments when you want to
 initiate the transfer after another job has completed successfully,
 regardless of the transfer's schedule.

 If you want to start a transfer, the transfer definition must be
 associated with your UIC.

 Example 1

 This example starts a transfer called ENROLL_SPANISH1.  If this
 transfer has a schedule defined for execution one hour from now but
 the transfer is suspended, issuing the START TRANSFER statement only
 changes the transfer's state to scheduled.  Execution of the transfer
 will not occur for another hour.

 RDO> START TRANSFER ENROLL_SPANISH1


 Example 2

 In this example, transfer ENROLL_SPANISH1 has been defined but has no
 schedule.  You issue this START TRANSFER NOW statement because you
 want to execute the transfer immediately.  Control returns to RDO as
 soon as the transfer begins.

 RDO> START TRANSFER ENROLL_SPANISH1 NOW

 Places a transfer in the suspended state.  Data Distributor does not
 attempt to execute the transfer until you remove it from the
 suspended state using the START TRANSFER statement.  If the transfer
 is in the active state, the STOP TRANSFER statement also stops the
 copy process associated with that transfer.

Additional information available:

FormatMoreExample

 STOP TRANSFER ───────> transfer-name ─────>

Additional information available:

transfer-name

 The transfer to be suspended.  The transfer-name parameter is
 required.

 You must terminate any outstanding transactions before you issue a
 STOP TRANSFER statement.

 If you want to stop a particular transfer, the transfer definition
 must be associated with your UIC.

 The following example places the EUROPE_PERS transfer in the
 suspended state.

 RDO> STOP TRANSFER EUROPE_PERS

 Gives access to DCL from inside RDO.

 The dollar sign ($) instructs RDO to spawn a subprocess and pass the
 next keyword to DCL for processing.  You must follow the dollar sign
 with a DCL command.  After DCL processes the command, it logs out of
 the subprocess and returns control to RDO.

 Example:

      RDO> $ MAIL

      MAIL>

 Format

      $ dcl-command

Additional information available:

MoreExample

 You need no special Rdb/VMS privileges to use this statement.

 Show current default VMS directory:

 RDO> $ DIRECTORY

 Directory DISK2:[DEPT3.ACCT]

 DEFPRO.RDO;6    NOTEQUAL.RDO;1   QUERY.RDO;1    REFEXAM.RDO;12
 STORE.RDO;1     UPDATE.RDO;2

 Total of 6 files.

 RDO>

 To see an online demonstration of Rdb/VMS, type the following:

      $ @RDM$DEMO:RDBDEMO

 Help is available on the following types of error messages:

 1.  RDB facility error messages -- Common to all Rdb relational
     database systems.

 2.  RDMS facility error messages -- Specific to Rdb/VMS.

 3.  RDO facility error messages -- Seen when you are running the
     interactive RDO utility.

Additional information available:

RDBRDMSRDO

 Print or type the SYS$HELP:RDB_MSG.DOC file for information on
 messages returned by the RDB facility.  The RDB facility is common
 code shared by all DIGITAL Standard Relational Interface (DSRI)
 compliant database systems.

 The SYS$HELP:RDB_MSG.DOC file contains the RDB facility messages from
 the most recently installed version of a DSRI-compliant database
 product on your system or VAXcluster.  (Installation of a new version
 of VIDA, VAX Rdb/ELN, or Rdb/VMS upgrades the RDB_MSG.DOC file
 whenever the RDB message image, RDBMSGS.EXE, includes new or revised
 error messages.

Additional information available:

ACCVIOACENOTFNDACTQUERYACTUPDREQAIJACTIVE
AIJALLDONEAIJBADAREAAIJBCKACTAIJBCKFAIL
AIJBCKSEQAIJCONFIRMAIJCURSEQAIJDEVDIRAIJDISABLED
AIJENABLEDAIJFILEGONEAIJFNLSEQAIJGOODAREA
AIJMODSEQAIJMOREWORKAIJNOACTIVEAIJNOENABLED
AIJNXTFILAIJNXTSEQAIJONEDONEAIJOPTSUCAIJPREPARE
AIJQUIETPTAIJRECOBSAIJRECTRMAIJROOSEQAIJSEQAFT
AIJSEQPRIAIJVNOSYNCALLMINALROPEANAEXTOBS
AREABUSYAREA_CORRUPTAREA_DELETEDAREA_INCONSIST
AREA_NAMEAREA_RESTRUCTARITHBADAIJBCK
BADAIJFILEBADAIJSEQBADAIJUNTILBADAIJVER
BADASCTOIDBADBNDPRMBADBOUNDSBADBUFSIZ
BADDATDEFBADDBNAMEBADFILTYPBADHANDLE
BADPARAMBADROOTMATCHBADSEGSTROPTBADSPAMINT
BAD_AREA_NAMEBAD_CODEBAD_DATATYPEBAD_NAME
BAD_SYMBAD_XPRBDDATRANGBKUPEMPTYAIJBOUND
BPPMAXBPPMINBUFLIMEXCBUFSMLPAGBUFTOOSML
BUGCHECKBUGCHKDMPCANTASSMBXCANTBINDRT
CANTCLOSEDBCANTCREDBRCANTCREGBLCANTCREMBX
CANTCREMONCANTDELETECANTLCKTRMCANTMAPTROOT
CANTOPENDBCANTOPENINCANTQIOMBXCANTREADDB
CANTREADDBSCANTSNAPCANTSPAWNCANTWRITEDBS
CATALOGEXISTSCATALOGINUSECATNOTFOUNDCDDDICTALONE
CDDISREQDCDDREQALONECHECKSUMCHGIDXNOADDMAP
CMTCONNOTDELCNVNUMDATCOLEXTSCOLINVFLDTYP
COLLFAILURECOLLFMTUNKCOLNOEXTSCOLNOTDEF
COLRESERVEDCOLUSEDDBCOLUSEDFLDCOLUSEDREL
COMPLEXCOMPNOTENACOMPNOTNUMCOMPNOTTEXT
CONDELVIARELCONEXICONEXTSCONFTXNOPTIONCONNOEXI
CONNOTDEFCONNOTDELCONVERRCONVWCSETBADASSIGN
CSETBADCOMPARECSETBADCONCATCSETBADESCAPECSETBADOPER
CSETNOASCIICSETNOTFOUNDDATCNVERRDBACTIVE
DBBUSYDBCRUPTDBNOTACTIVEDBNOTEXTENDBNOTINTRAN
DBNOTMULTSCHEMDBNOTOPENDBRABORTEDDBSHUTDOWN
DB_CORRECT_VERDEADLOCKDEFLISTWORMDOFULLBCK
DT_FRACMBZDT_PRECMBZDUPLANAMEDUPLFNAME
DUPLTRGTYPEDUPNOTALLEMPTYAIJEMPTYFILE
ENDERRFOREIGNERROPENINERROPENOUT
ERRWRITEEXQUOTAEXTDBONLYEXT_LENGTH_CHEXT_NEED_DT
EXT_WEEKDAY_TSFCJOUDISFIEUSETRAFILACCERRFLDEXFLDINCOM
FLDINCOMRELFLDINCONFLDINSTOFLDINTRGFLDINUSEFLDINVIEW
FLDLSTCONDUPSFLDNOEXFLDNOEXIFLDNOTCHGFLDNOTDEL
FLDNOTINRELFLDVALIDIFGETTXNOPTIONGFLDEXTS
GFLDNOEXGOODAIJSEQHASHEDMIXIDXCOMPLENERR
IDXMAPLIMIDXMAPLMTIDXMAPLMTERRIDXNOTDEF
IDXNOTDELILLNCHARINDEXTSINDEX_S_MAXINDEX_S_MIN
INDINMAPINDLIMITBADINDNEEDSLIMITINDNOTEXIINDNOTREL
INDTOOBIGINFUNKINVACE_LENGTHINVCATALOGID
INVDATOPRINVDBSFILINVDB_NAMEINVDB_TYPE
INVDTYPINDXINVDTYPKEYINVFORUPDATEINVHEADER
INVIDENTINVMAXROWSINVMAXTIMEINVNAMEINVOPTPREF
INVSCHEMAIDINVSUBSTRLENINVTBL_NAMEINVTRGACT_STMT
INV_DATE_CHGINV_DIGITSINV_PCT_FILLINV_PRECISION
INV_RATORINV_ROOTINV_SCALEINV_SUB_TYPE
JOIN_CTX_UPDLASTARENOLIMITLBMAXLBMINLCKCNFLCT
LOGAIJBCKLOGCREOPTLOGMODSPMLOGMODSTO
LOGRECOVRLOGRECSTATLOGRESOLVELOGSUMMARY
MAPAREAINUSEMAPBLRMISSINGMAPNMINUSEMAPREFAREA
MAXRECLIMMAXRELVERMAXTIMLIMMAX_CCTX
MISMMORDDMISSINGINVMIXCLUSTMONALSTART
MONFLRMSGMONMBXOPNMONSTOPPEDMULTCHGAREA
MULTPLACEVIAMULTSCHEMALONEMULTSCHEMNODISMULTSCHEMNOW
MUSTRECDBNBMAXNBMINNDXPMTDUPSNOACCSEGSTR
NOAIJDEFNOCATALOGNOCHARNOCHGRDBSYSNOCHGVW
NOCREMBXNOCRESYNONYMNODBKNODELPRIVANSI
NODELSEGSTRNODEVDIRNODMAXNODMINNODROPSYNONYM
NODUPSANSINOGRPANSINOIDENTANSINOINTERUNI
NOLOCKSOUTNOMAPONVIEWNOMETAUPDNOMETSYSREL
NOMONITORNOMOREGBNONODENOOPTCURNOOPTNOQUIET
NOOPTOPTNOOPTPRVNOQUIETNOOPTUNRESNOPLACEANSI
NOPRIVNORTUPBNOSCHEMANOSIPNOSNAPSNOSTAREAEXT
NOSTATSNOSTRTUPNOSYNONYMNOTBOOLNOTDSKFIL
NOTHRESUNINOTIMPLYETNOTIPNOTOPENOTRANAPP
NOTROOTNOTSYSCONCEALNOT_BOUNDNOT_LARDY
NOT_LICENSEDNOT_READYNOT_RESERVNOT_UPDATE
NOT_VALID_FRNOVIEWINDNOWILDNOWORMSPT
OBSVEROK_NO_ACEOPCLOOBSOPERCLOSEOPERSHUTDN
OPTINCONSISOPTNOAREARECOPTNOUNTILRECOVERFLOW
PARTDTXNERRPARTOPERBADPLACEVIA1STPREMEOF
PRI_RELCONEXTSQIOXFRLENQUIETPTREADONLYREAD_ONLY
RECMAXEXCREFINGFLDMSMTCHRELALRDYMPRELCONEXTS
RELCONNOEXIRELEXIRELEXTSRELFLDEXRELFLDNOC
RELFLDNODRELINCOMRELNEXTSRELNOEXIRELNOTCHG
RELNOTDELRELNOTEMPTYRELUSETRAREQPBLCANSI
REQUNIFORMRESTARTRLCREFDBYRLCROOMAJVER
ROOTMAJVERRUJDEVDIRSCHEMAEXISTSSCHEMAINUSE
SCHNOTFOUNDSEGALRDYMPSEGMAPONWORMSEGSTR_AREA_INC
SEGSTR_NO_CHGSEGTOOBIGSETWIDTHSIPSNAPFULL
SNPDISCJSORTKEYEXTSORTOPERRSPAMNOTDIS
SPAMNOTRDONLYSPAMNOTWRMSPIMAXSPIMINSSAREANOTEMPTY
SSNOTINROOTSTALLSTAREAFULSTOMAPNOEXI
SYMTOOBIGSYNERRSYSRDONLYTABIDNOTDEF
TABNOTDEFTADMISMATCHTERMINATETHRESHAREEXI
THRESHUNIFTIMEOUTTRANSFDEFTRAN_IN_PROG
TRGEXITRGEXTSTRGINUPDREQTRGNOEXITRGNOSUBJCTX
TRGVWTRIGNODELTRIG_ERRORTRNNOTDEF
TRNNOTDELTRUETRUNCATIONTRUNRGTSTR
UNDERFLOWUNI_RELCONNOEXIUNLIKECOLLUNSARITH
UNSCATALOGUNSCOMPUNSCONVUNSSCHEMAUNSSYNONYM
UNS_DTYPEUPDINSNAPUPDRECURSTRIGUSEUNOPTAIJ
USRMAXUSRMINVCO_NOFIRSTNVIEWEXIVIEWINVIEW
VIEWNOEXIVIEWNORETVIEWNOTDELVIEWNOUP
VIEW_NO_ANAWASBOOLWISH_LISTWRMNOTMIXWRMRDONLY
WRNG_RELXPR_STACK_OFLO