Event Replicator for Adabas processes the same operator commands that may be given to an Adabas nucleus. For example, ADAEND will terminate the Event Replicator for Adabas. For more information about Adabas operator commands and how to enter them, read the Operations documentation for Adabas.
If you choose to secure both an Event Replicator Server nucleus and the operator command using Adabas SAF Security, only use the first eight (8) characters (or less) of the command name in the respective ADAEOPTB table (macro). Putting the truncated versions of the commands (RPLREFRESH or RPLCLEAN, for example) into ADAEOPTB is sufficient for Adabas SAF Security to identify the commands and allow or disallow them to function as expected. For more information about the ADAEOPTB table, refer to your Adabas SAF Security documentation.
This document describes all of the operator commands pertinent only to the Event Replicator for Adabas. The following table categorizes the commands as they apply to the source Adabas nucleus, the Event Replicator Server nucleus, and the ADARPL utility. For detailed information about each command, click on the command name in the table.
| Command Category | Applicable Commands |
|---|---|
| Source Adabas nucleus | DONLSTAT DRPLSTAT ONLRESUME ONLSTOP ONLSUSPEND RPLCONNECT RPLCONNECTCOUNT RPLCONNECTINTERVAL |
| Event Replicator Server nucleus | DRPLPARM DRPLSTAT RPLCHECK RPLCLEANUP RPLCONNECT RPLCONNECTCOUNT RPLCONNECTINTERVAL RPLREFRESH TLOG |
| ADARPL utility | DSTAT |
Use the DONLSTAT command to display the status of each active reorder, invert online, or Event Replicator for Adabas initial-state process together with the process ID.
Use this command to display information about the replication definitions that are currently in use by an Event Replicator Server. This command can only be issued against an Event Replicator Server.
Each parameter of the DRPLPARM command is optional and is described in the following table. If you do not specify any of these parameters, information about all replication definitions in the Event Replicator Server is displayed.
| Parameter | Displays information for: |
|---|---|
| D=destname | The specified destination definition (destname). |
| G=gfbname | The specified global format buffer definition (gfbname). |
| GLOBALS | All global value definitions only. |
| Q=qname | The specified input queue definition (qname). |
| R=rbname | The specified resend buffer definition (rbname). |
| S=sname | The specified subscription definition (sname). |
Use this command to display the replication-related statistics for an Adabas database (with replication turned on) or for an Event Replicator Server.
When issued against an Adabas database (with replication turned on), the statistics listed include:
The total number of replication transactions completely processed.
The current number of pending replicated transactions (transactions that have been committed, but not yet processed)
The current number of incomplete transactions that will be replicated (but are not yet committed).
When issued against an Event Replicator Server, the statistics related to destinations, global values, and subscriptions in the database are listed. Replay Utility (ADARPL) statistics are also included.
The syntax for DRPLSTAT is:
The DRPLSTAT parameters are always optional and should be used only when the command is issued against an Event Replicator Server; the parameters are not valid when DRPLSTAT is issued for an Adabas database.
Note:
Errors will occur if you attempt to run DRPLSTAT for an Adabas database
using any of the parameters.
DRPLSTAT parameters are described in the following table. If you do not specify any of these parameters, replication-related statistics about all destinations, global values, and subscriptions in the Event Replicator Server are displayed.
| Parameter | Displays replication-related statistics for: |
|---|---|
| D=destname | The specified destination (destname). |
| GLOBALS | All global values only. |
| S=sname | The specified subscription (sname). |
| TOKENS | ADARPL or ADALOD tokens. When a synchronized or replay-only request is submitted, a token is created in the Event Replicator Server nucleus. The TOKENS option of the DRPLSTAT facility allows you to view the details of the token, including the DBID, subscription, destination, start date, start time, end date, and end time in the token. |
Use the DSTAT command to display statistics about the current Adabas nucleus status.
When this command is issued against a running Event Replicator ADARPL job, the Replay Utility (ADARPL) statistics are displayed.
Note:
After issuing a REFRESHSTATS, DSTAT displays the refreshed
statistics.
Use the ONLRESUME command to resume a previously suspended online reorder, invert, or Event Replicator for Adabas initial-state process.
Use the ONLSTOP command to stop an online reorder, invert, or Event Replicator for Adabas initial-state process cleanly. The process continues up to its next interrupt point in order to produce a consistent state, and then terminates after performing all necessary cleanup.
Use the ONLSUSPEND command to suspend an online reorder, invert, or Event Replicator for Adabas initial-state process. The process continues up to its next interrupt point in order to produce a consistent state, performs a command throwback, and enters a state where it cannot be selected for processing. This command is useful if the online process is consuming too much of the nucleus resources.
Use this command to perform the replication cross-check function for all active databases known (defined in one or more subscriptions) to the Event Replicator Server. When this command is run using the ADADBS OPERCOM function, the information about the cross-check function is printed to the ADADBS DDDRUCK data set. The information printed by ADADBS is the same as the information printed by the Event Replicator Server during the cross-check process initiated by the RPLCHECK operator command.
Note:
This command can only be issued against an Event Replicator Server; it is not valid for
the Adabas nucleus. If this command is issued against a database that is not an
Event Replicator Server, error messages result.
Use this command if the Replay Utility (ADARPL) or an ADALOD job (with RPLLOAD=YES) abends and to stop replay processing (if it is running when the RPLCLEANUP command is entered). This command will clean up any open transactions in the Event Replicator Server that are associated with ADARPL or ADALOD (with RPLLOAD=YES) processing. Specify the token ID returned at startup for tokenid to perform this cleanup for a particular run; specify "ALL" to clean up transactions related to any run. Token IDs for running ADARPL processes or ADALOD jobs (with RPLLOAD=YES) can be listed using the DRPLSTAT command.
Use this command to dynamically force a connection attempt to either a specific Event Replicator Server or Adabas database ID or to all related Event Replicator Server or Adabas database IDs.
One of the parameters of the RPLCONNECT command must be specified. There is no default. The parameters are described in the following table:
| Parameter | Forces a reconnection attempt with: |
|---|---|
| ALL | All known Event Replicator Server or Adabas database IDs |
| dbid | The specified Event Replicator Server or Adabas database ID. |
Use this command to dynamically specify the number of connection attempts made for the Adabas or Event Replicator Server nucleus after an attempt fails (response 148 is issued).
For nnn, specify a valid integer ranging from zero (0) through 2147483647. A value of zero indicates that no connection attempts should occur; a value of zero makes the most sense in situations where the Adabas database and the Event Replicator Server execute together on the same logical partition (LPAR). If the Adabas database and the Event Replicator Server execute on different LPARs, however, setting a real value using this command helps avoid errors that might arise if network problems occur because the network is not started or a network connection between the Adabas database and the Event Replicator Server is lost.
Use this command to dynamically specify the interval between connection attempts made for the Adabas or Event Replicator Server nucleus after an attempt fails (response 148 is issued).
For nnn, specify the number of seconds for the interval, ranging from zero (0) through 2147483647 seconds. A value of zero indicates that no connection attempts should occur; a value of zero makes the most sense in situations where the Adabas database and the Event Replicator Server execute together on the same logical partition (LPAR). If the Adabas database and the Event Replicator Server execute on different LPARs, however, setting a real value using this command helps avoid errors that might arise if network problems occur because the network is not started or a network connection between the Adabas database and the Event Replicator Server is lost.
You can use the RPLREFRESH command to refresh resource definitions in your Event Replicator Server configuration while the Event Replicator Server is running or to abort scheduled (pending) RPLREFRESH processing. This command can be used to avoid the system downtime usually necessary to make configuration changes.
Two types of refresh processing can occur:
A partial refresh occurs when a specific resource is refreshed. This is only supported if the Event Replicator Server resource definitions are stored in the Replicator system file and not if they are provided via DDKARTE statements in the Event Replicator Server startup job. In other words, ADARUN RPLPARMS=FILE must be specified or the RPLPARMS parameter must not be specified and the Replicator system file must be loaded on the Event Replicator Server.
A complete refresh (using the ALL option) refreshes all Event Replicator Server resource definitions. It can be run whether the Event Replicator Server resource definitions are specified in either the Replicator system file or in DDKARTE statements in the Event Replicator Server startup job.
Note:
On z/VSE systems, you cannot refresh resource definitions, if
they are defined via an in-stream reader on SYSIPT.
You can refresh the configurations of the following resources:
Subscription definitions, including the other definitions required by a subscription (such as global format definitions and transaction filter definitions).
Destination definitions
Resend buffer definitions
Note:
Special processing is necessary if you want to modify a
resend buffer; you cannot use the RPLREFRESH command to dynamically modify a
resend buffer. For information on modifying a resend buffer, read
Resend Buffer Modification and
Refresh Requirements, later in this section.
Initial-state definitions
Input queue definitions
Subscription user exit
Note:
Subscription user exits can be only refreshed with
SX=name parameter, one subscription user exit at a time. Subscription
user exits cannot be refreshed by RPLREFRESH,ALL
command. For information on refreshing a subscription user exit, read
Refreshing Subscription User
Exit, later in this section.
Global definitions.
Note:
The SUBTASKS, NPADACALLS, ETBBROKERNAME, and MAXOUTPUTSIZE
initialization parameter settings cannot be changed using
RPLREFRESH.
This section covers the following topics:
RPLREFRESH can be used to initiate refresh processing or to abort previously requested RPLREFRESH processing. The syntax of the command differs, depending on which function you are trying to perform:
The RPLREFRESH syntax to initiate a refresh attempt of a single resource is:
RPLREFRESH,{D | I | Q | R | S | SX}=name
Specify "D" to refresh a destination resource, "I" to refresh an initial-state resource, "Q" to refresh an input queue resource, "R" to refresh a resend buffer resource, "S" to refresh a subscription resource, or "SX" to refresh a subscription user exit. Specify the name of the resource for name.
The RPLREFRESH syntax to initiate a refresh attempt for the global value parameters is:
RPLREFRESH,GL[obals]
For a complete description of the global values available to the Event Replicator Server, read Setting Global Values using the Adabas Event Replicator Subsystem.
The RPLREFRESH syntax to initiate a refresh attempt for all Event Replicator Server resources is:
RPLREFRESH,ALL
When ALL is specified, the RPLREFRESH processing logic will compare the current configuration with the configuration specified in the Replicator system file or in the DDKARTE statements in the Event Replicator Server startup job. Each resource that has been changed will be refreshed by the system.
Refreshing all resources is implemented by making a series of RPLREFRESH passes through the resources in an hierarchical sequence to ensure that resources without dependencies are refreshed immediately, followed by lower-level resources associated with the refreshed resources and the resources that depend on them. All additions and modifications occur as part of the primary loop processing with resource deletion occurring when all additions and modifications have completed or failed.
RPLREFRESH,ALL processing will continually retry refresh attempts until all resources have been refreshed, the refresh attempt fails, or the time limit to wait for resources to be quiesced is exceeded.
The following hierarchical sequence for refresh additions and modifications is used:
Global value resource definitions are refreshed first. This is only done once, the first time through, because it cannot fail and does not currently require a quiesce.
Input queue definitions are refreshed, assuming they are closed. No other Event Replicator Server definitions have dependencies on input queue definitions.
Resend buffer definitions are refreshed third as subscription definitions and, indirectly, initial-state definitions have dependencies on them.
Destinations are refreshed fourth as subscription and initial-state definitions have dependencies on them.
Subscriptions are refreshed fifth as initial-state definitions have dependencies on them.
Initial-state definitions are refreshed last because they have dependencies on many other Event Replicator Server definitions.
When an error occurs during the addition or modification of a resource in this hierarchical processing, the refresh of that resource and the refresh of any other resources with dependencies on it are removed from the RPLREFRESH,ALL attempt.
If a resource cannot be modified because it must be quiesced first, the resource and any other resources with dependencies on it are left until the next pass of the RPLREFRESH, ALL processing. During the next pass, an attempt is made to modify the resource again.
Once all modifications and additions have completed or failed, each of the resources that are to be deleted during RPLREFRESH processing are deleted in the following sequence:
Initial-state definitions are deleted first, because no other Event Replicator Server definitions have dependencies on them.
Subscription definitions are deleted second because any initial-state definitions with dependencies on them should have already been deleted.
Destination definitions are deleted third because any subscription and initial-state definitions with dependencies on them should have already been deleted.
Resend buffer definitions are deleted fourth because any subscription and initial-state definitions with dependencies on them should have already been deleted.
Input queue definitions are deleted last.
When an error occurs during the deletion of a resource in this hierarchical processing, the refresh of that resource and the refresh of any other resources with dependencies on it are removed from the RPLREFRESH,ALL attempt.
If a resource cannot be deleted because it must be quiesced first, the resource and any other resources with dependencies on it are left until the next pass of the RPLREFRESH, ALL processing. During the next pass, an attempt is made to delete the resource again.
The RPLREFRESH syntax to abort a scheduled (delayed) refresh attempt is:
RPLREFRESH,AB[ort]
Note:
Refresh of a subscription user exit cannot be aborted.
For information about what scheduled, or pending, refresh processing is, read Refresh Processing.
RPLREFRESH,SX=subscription_user_exit_name
Only one subscription user exit will be refreshed at a time and its name stays the same.
This new parameter is supported only for z/OS operating system, ADABAS version 8.4 or higher and running APF-authorized.
EXITLIB DD must be specified for the Reptor job.
The specified exit is loaded from the EXITLIB module with the specified name, both during Reptor start and during an RPLREFRESH operation. To change a loaded exit, the new version of the exit must be placed under the same name in the EXITLIB.
The new version of the exit becomes effective immediately for all subscriptions for which it has been specified.
Once the new version of the exit has been successfully loaded, a Terminate function for the old version of the exit will be called and the old version will be is deleted.
For the new version of the exit the Initialize function will be called.
If the new version of the exit cannot be loaded, the old version stays in effect (and its Terminate function is not called).
Refreshing an exit with RPLREFRESH,SX=exit_name is different from refreshing an exit as part of an RPLREFRESH,S=subscription_name operation in that
Refreshing a subscription loads only an exit with a new name. If the name is not changed, no new exit is loaded and the old exit stays in effect.
Refreshing a subscription may change the exit only for this subscription. Refreshing an exit changes the exit for all subscriptions for which it has been specified.
Refresh processing occurs in the following sequence:
The parameters for the resource are read from the Replicator system file and validated.
If this is a request to refresh a subscription definition, the global format buffer definitions and filter definitions are also read and validated.
If the global format buffer validation parameter (FBVALIDATION) is set to something other than "NONE", the validation behaves in the following fashion during a refresh:
If FBVALIDATION is set to "ABORT", when a format buffer error is encountered during refresh processing, the refresh request fails.
If FBVALIDATION is set to "DEAC", when a format buffer error is encountered during refresh processing, the refresh request fails.
If FBVALIDATION is set to "WARN", when a format buffer error is encountered during refresh processing, a warning message is issued and refresh processing continues.
If this is an attempt to refresh an initial-state definition, the definition is automatically deactivated (if it is not already inactive) or it is rescheduled.
The system determines what kind of a refresh request is being submitted, based on the existence of the resource definition in the running Replicator system file.
If the resource definition exists in the running configuration as well as the refresh request configuration, the request is to modify the resource.
If the resource definition exists in the running configuration, but not in the refresh request configuration, the request is to delete the resource.
If the resource definition does not exist in the running configuration, but does exist in the refresh request configuration, the request is to add the resource.
The system is checked to determine if the refresh request can be performed at all. Appropriate messages are issued if the refresh request cannot be performed.
The system is checked to determine if it can perform the refresh immediately or if the refresh must be delayed. A refresh can only occur immediately when the resources in the system are in a state acceptable to Event Replicator for Adabas for a refresh. The refresh state requirements vary, depending on the resource definition involved and depending on the change for that resource. For further information, read the following sections, as appropriate:
If these conditions are not met, the refresh request is delayed for five minutes.
Note:
It is during this wait (delay) time that an
RPLREFRESH,ABORT request can be issued for a refresh
request.
If, after five minutes, the conditions are still not met, the refresh request will fail. Otherwise, the refresh occurs when the conditions for the refresh are right.
Messages are issued following an RPLREFRESH attempt, indicating whether the refresh was successful or not. If the attempt was unsuccessful, additional messages will identify the reason why it failed.
A refresh for a destination definition can only occur immediately if the definition is not in use; otherwise, the refresh is delayed.
The following table describes each parameter that can be provided to a destination and the refresh state requirements for the parameter. When more than one parameter is changed, the requirements are cumulative so that all requirements must be met before refresh processing can occur.
| Parameter | Requirement |
|---|---|
| DACTIVE | None; this parameter can be refreshed at any time. |
| DAIDBID | This parameter can be refreshed only if the Adabas destination is not actively producing data. |
| DAIFILE | This parameter can be refreshed only if the Adabas destination is not actively producing data. |
| DARC | This parameter can be refreshed only if the destination is not actively outputting data. |
| DATDBID | This parameter can be refreshed only if the Adabas destination is not actively producing data. |
| DATFILE | This parameter can be refreshed only after the destination is closed. |
| DCOMMITTHRESHHOLD | None; this parameter can be refreshed at any time. |
| DETBBROKERID | This parameter can be refreshed only after the destination is closed. |
| DETBSERVICE | This parameter can be refreshed only after the destination is closed. |
| DETBSERVICECLASS | This parameter can be refreshed only after the destination is closed. |
| DETBSERVICENAME | This parameter can be refreshed only after the destination is closed. |
| DEXIT | This parameter can be refreshed only if the destination is not actively producing data. |
| DEXITWORKSIZE | This parameter can be refreshed only if the destination is not actively producing data. |
| DLOG | This parameter setting can be changed from "NO" to "YES" at any time. However, it can only be changed from "YES" to "NO" if there is no data on the SLOG file and no data is available to be written to the SLOG for the destination. |
| DMQDYNQNAME | This parameter can be refreshed only after the destination is closed. |
| DMQQMGRNAME | This parameter can be refreshed only after the destination is closed. |
| DMQQNAME | This parameter can be refreshed only after the destination is closed. |
| DQFULLDELAY | None; this parameter can be refreshed at any time. |
| DTLASSIGN | None; this parameter can be refreshed at any time. |
| DTLCOMP | None; this parameter can be refreshed at any time. |
| DTLSLOGREAD | None; this parameter can be refreshed at any time. |
| DTLSLOGWRITE | None; this parameter can be refreshed at any time. |
| DTYPE | This parameter can be refreshed only after the destination is closed. |
The following table describes the refresh requirements for some of the global value parameters that can be specified for the Event Replicator Server. When more than one parameter is changed, the requirements are cumulative so that all requirements must be met before refresh processing can occur.
| Parameter | Requirement |
|---|---|
| IRMSGINTERVAL | None; this parameter can be refreshed at any time, without need to quiesce any part of the Event Replicator Server. |
| IRMSGLIMIT | None; this parameter can be refreshed at any time, without need to quiesce any part of the Event Replicator Server. |
| MAXOUTPUTSIZE | This parameter cannot be changed with RPLREFRESH. |
| NPADACALLS | This parameter cannot be changed with RPLREFRESH. |
| SUBTASKS | This parameter cannot be changed with RPLREFRESH. |
| TLOG Parameters | None; these parameters can be changed at any time, without need to quiesce any part of the Event Replicator Server. |
| VERIFYMODE | This parameter cannot be changed with RPLREFRESH. |
A refresh for an initial-state definition can only occur immediately if the definition is not in use; otherwise, the refresh is delayed.
The following table describes each parameter that can be provided to an initial-state definition and the refresh state requirements for the parameter. When more than one parameter is changed, the requirements are cumulative so that all requirements must be met before refresh processing can occur.
| Parameter | Requirement | Operations |
|---|---|---|
| IDESTINATION | This parameter can be refreshed only if no instances of the initial-state request are active. | Modify |
| IFILE | This parameter can be refreshed only if no instances of the initial-state request are active. | Add |
| Delete | ||
| IDBID | This parameter can be refreshed only if no instances of the initial-state request are active. | Add |
| Delete | ||
| IMAXREQ | This parameter can be increased at any time, without need to quiesce any part of the Event Replicator Server. However, if this parameter needs to decreased, no instances of the initial-state request can be active. | Modify |
| INITIALSTATE | This definition can be refreshed only if no instances of it are active. | Add |
| Delete | ||
| ISNLIST | This parameter can be refreshed only if no instances of the initial-state request are active. | Modify |
| ISUBSCRIPTION | This parameter can be refreshed only if no instances of the initial-state request are active. | Modify |
| SELCRIT | This parameter can be refreshed only if no instances of the initial-state request are active. | Modify |
When adding an initial-state definition during RPLREFRESH processing, all of the destinations and subscriptions referenced by the initial-state definition must already be defined to the Event Replicator Server. Also, you can only delete an initial-state definition during RPLREFRESH processing if there are no active requests in progress for the initial-state definition.
If any of the following conditions is true, the initial-state definition refresh can only be scheduled.
If changes have been made to the destination, subscription, or file definitions referenced by the initial-state definition, there may be no active requests in progress for the initial-state definition.
If the IMAXREQ parameter value has been decreased, there may be no active requests in progress for the initial-state definition.
The input queue definition must be closed if you are modifying or deleting the definition using RPLREFRESH. Otherwise, the refresh request will fail.
A resend buffer definition cannot be dynamically modified and refreshed using RPLREFRESH. You can only add or delete resend buffer definitions using RPLREFRESH.
Note:
If you want to delete a resend buffer definition during an RPLREFRESH
run, the resend buffer definition may not be referenced by any
subscription.
If you want to modify a resend buffer and refresh its definition, you must follow complete these steps:
Delete the resend buffer definition. This may require removing references to it from one or more subscriptions.
Recreate the resend buffer definition, with the required changes.
Restore the references to the resend buffer definition in the appropriate subscriptions.
Use RPLREFRESH to refresh the resend buffer definition.
Use RPLREFRESH to refresh the subscriptions that reference the resend buffer definition.
A refresh for a subscription definition can only occur immediately if the definition is not in use; otherwise, the refresh is delayed.
The following table describes each parameter that can be provided to a subscription and the refresh requirements for the parameter. When more than one parameter is changed, the requirements are cumulative so that all requirements must be met before refresh processing can occur. If the requirements listed in this table are not met, the refresh request is delayed (scheduled) for a later time.
The Operations column indicates whether the changes to the parameter affect the addition, deletion, or modification of a subscription definition.
| Parameter | Requirement | Operations |
|---|---|---|
| SACODE | None; this parameter can be refreshed at any time. | Modify |
| SACTIVE | None; this parameter can be refreshed at any time. | Modify |
| SARC | None; this parameter can be refreshed at any time. | Modify |
| SDESTINATION | If an attempt is being made to add a destination
to the subscription, the refresh attempt can occur at any time.
If an attempt is being made to delete a destination from the subscription, the refresh attempt can occur only when all transactions for the subscription to that destination are processed and if all SLOG data for the destination is also processed. |
Add, Delete |
| SFBAI | This parameter can be refreshed only when all transactions for the subscription have been processed and if all the SLOG data for any destination to which the subscription sends data has also been processed. | Modify |
| SFBBI | This parameter can be refreshed only when all transactions for the subscription have been processed and if all the SLOG data for any destination to which the subscription sends data has also been processed. | Modify |
| SFBKEY | This parameter can be refreshed only when all transactions for the subscription have been processed and if all the SLOG data for any destination to which the subscription sends data has also been processed. | Modify |
| SFDBID | If an attempt is being made to add a subscription
definition, it is delayed when input transactions are queued for assignment to
any subscription. In this case, the refresh attempt is scheduled for later,
when all input transactions have processed.
If an attempt is being made to delete a subscription definition during a refresh, it can occur only when:
|
Add, delete |
| SFFILTER | None; this parameter can be refreshed at any time. | Modify |
| SFILE | If an attempt is being made to add a subscription
definition, it is delayed when input transactions are queued for assignment to
any subscription. In this case, the refresh attempt is scheduled for later,
when all input transactions have processed.
If an attempt is being made to delete a subscription definition during a refresh, it can occur only when:
|
Add, delete |
| SFREPLICATEDELETE | None; this parameter can be refreshed at any time. | Modify |
| SFREPLICATEINSERT | None; this parameter can be refreshed at any time. | Modify |
| SFREPLICATENOTCHANGED | None; this parameter can be refreshed at any time. | Modify |
| SFREPLICATEUPDATE | None; this parameter can be refreshed at any time. | Modify |
| SFSEXIT | None; this parameter can be refreshed at any time. | Modify |
| SGFORMATAI | This parameter can be refreshed only when all transactions for the subscription have been processed and if all the SLOG data for any destination to which the subscription sends data has also been processed. | Modify |
| SGFORMATBI | This parameter can be refreshed only when all transactions for the subscription have been processed and if all the SLOG data for any destination to which the subscription sends data has also been processed. | Modify |
| SGFORMATKEY | This parameter can be refreshed only when all transactions for the subscription have been processed and if all the SLOG data for any destination to which the subscription sends data has also been processed. | Modify |
| SIDESTINATION | If an attempt is being made to add a destination
to the subscription, the refresh attempt can occur at any time.
If an attempt is being made to delete a destination from the subscription, the refresh attempt can occur only when all transactions for the subscription to that destination are completed and if all SLOG data for the destination is also processed. |
Add, Delete |
| SINCREMENTIS | None; this parameter can be refreshed at any time. | Modify |
| SRESENDBUFFER | None; this parameter can be refreshed at any time. | Modify |
| STLFILTER | None; this parameter can be refreshed at any time. | Modify |
| STLINPUT | None; this parameter can be refreshed at any time. | Modify |
| STLOUTPUT | None; this parameter can be refreshed at any time. | Modify |
| SUBSCRIPTION | If an attempt is being made to add a subscription
definition, it is delayed when input transactions are queued for assignment to
any subscription. In this case, the refresh attempt is scheduled for later,
when all input transactions have processed.
If an attempt is being made to delete a subscription definition during a refresh, it can occur only when:
|
Add, delete |
| SVERSION | None; this parameter can be refreshed at any time. | Modify |
| SWCODE | None; this parameter can be refreshed at any time. | Modify |
Use this command to dynamically alter the level of transaction logging occurring for replication. The complete format of this command is:
TLOG[,[S=subscription|D=destination]]event-name=level
where subscription is an optional subscription definition name, destination is an optional destination definition name, event-name is the valid name of a TLOG parameter, as defined in the following table, and level is a valid transaction logging level as defined for each parameter.
The following table lists the valid TLOG parameters, their ranges, their defaults, and whether or not the S or D options need to be specified with a TLOG operator command for the parameter. Complete descriptions of each parameter can be found by clicking on the link in the table reading about the appropriate parameter in Transaction Log (TLOG) Settings in Event Replicator for Adabas Reference Guide.
| Event-Name (Parameter) | Value Range | Default | S or D Option Required for Command? |
|---|---|---|---|
| DDTLASSIGN | 0-3 | 0 | D required |
| DTLCOMP | 0-3 | 0 | D required |
| DTLSLOGREAD | 0-3 | 0 | D required |
| DTSLOGWRITE | 0-3 | 0 | D required |
| STLFILTER | 0-3 | 0 | S required |
| STLINPUT | 0-3 | 0 | S required |
| STLOUTPUT | 0-3 | 0 | S required |
| TLCOMP | 0-1 | 0 | No |
| TLINPUT | 0-3 | 0 | No |
| TLISTATE | 0-3 | 0 | No |
| TLISTATECOMP | 0-3 | 0 | No |
| TLNOSUB | 0-3 | 0 | No |
| TLQCOMP | 0-3 | 0 | No |
| TLREQERR | 0-3 | 0 | No |
| TLREQRECV | 0-2 | 0 | No |
| TLREQREJECT | 0-2 | 0 | No |
| TLRETRANS | 0-3 | 0 | No |
| TLSTATUS | 0-3 | 0 | No |