To define a transfer schedule, you must have the same user
    identification code (UIC) as the user who defined the transfer,
    or have the ALTER transfer privilege or the OpenVMS BYPASS
    privilege. If you try to define a transfer schedule for a
    transfer defined by a user with a different UIC, and you do
    not have the appropriate access right or privilege, Replication
    Option returns an error message and prevents the schedule
    from executing. If you have BYPASS privilege and define a
    schedule for a transfer associated with a different UIC, 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,
    Replication Option places the transfer in the active state.

    You cannot modify a schedule definition using RDO. 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, or, use the SQL ALTER SCHEDULE statement.

    When you define a one-time-only transfer schedule and specify
    a transfer time that has already passed, issuing a START
    TRANSFER statement changes the transfer status from suspended
    to scheduled. However, when you issue a SHOW TRANSFER STATUS
    statement, the "next transfer to be executed" phrase is not
    included. To avoid this problem and cause the transfer to
    execute, use the START TRANSFER NOW statement.

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

    You can change the default date/time format that was established
    before VMS Version 5.0 to a date/time format that complies with
    the LIB$ international date and time formatting routines of VMS
    Version 5.0 and higher. For example, you might want to change the
    input format from 1-APR-1989 to one that allows entry of dates in
    the form April 1, 1989. You can change the output format as well.

    To change the input date/time format, define the LIB$DT_INPUT_
    FORMAT logical name as discussed in the OpenVMS RTL Library (LIB$)
    documentation. To change the output date/time format, define the
    logical name LIB$DT_FORMAT. If you change the date/time format from
    the one used prior to VMS Version 5.0, then you must place the date
    and time in quotation marks. If you continue to use the date
    /time format in effect before VMS Version 5.0, you can enter the
    date and time with or without quotation marks as you wish. ,b
    For further information about the date/time routines provided by
    the OpenVMS Run-Time Library, refer to the OpenVMS RTL Library
    (LIB$) documentation. Refer also to the Oracle Rdb documentation
    set for details specific to that product's use of international
    date/time formats.

    Replication Option does not guarantee the reexecution of
    a transfer at the specified rate. If the copy process is
    tied up for any reason and cannot finish its task before the
    next transfer repetition cycle, the copy process ignores the
    repetition. The cycle is reset to the next expected transfer
    time.

    A replication transfer with a schedule that runs on an infrequent
    basis can consume a considerable amount of disk space in the
    source database. For example, if a replication transfer is
    scheduled to occur once a month, any new or changed records
    to be transferred are duplicated in the relation RDB$CHANGES
    in the source database and are retained for the remainder of
    the month until the schedule starts the transfer. This space is
    released only after the duplicate records have been transferred
    and erased. Thus, for the entire month that the duplication
    records are stored, they take up disk space. In general, you
    should not choose an infrequent transfer cycle if the number of
    daily changes to the source database is high.

    In addition, even if this monthly replication transfers only a
    single record each month, another problem can arise if other
    replication transfers use the same source database. Although
    those transfers might execute more frequently than once a month,
    their records are not necessarily erased from the RDB$CHANGES
    relation right away. Replication Option erases the records only
    if no records entered earlier are waiting to be transferred.