História stránky

If some files - the external and user libraries for Java, placed in directory %lt;appldirgt;/java/shared are changed, the D2000 Server will send these files to all running clients.

DI ON/OFF

DI /E+dbginfo

DI /E-dbginfo

Debug Info - shows (DI ON)/ hides (DI OFF) internal debug information of D2000 Server (in the process window and in the process D2000 Sysconsole).

The command allows show/hide viewing debug information by category as the SysConsole user interface allows.

Example 1: Show debug information

DI /E+DBG.CFG_RQ

Example 2: Hide debug information

DI /E-DBG.CFG_RQ

Since version v23.0

If the kernel was started with the /N parameter, i.e. so that it does not start processes, by calling this tell command, startup is turned on and kernel processes start.

Initialize the path to the repository. If the directory does not exist, a new one will be created. If there is a repository on a given path, this one will be used for storing object history. History capturing must be disabled.

REPOSITORY DISCONNECT

Remove the setup path to the repository. History capturing must be disabled.

REPOSITORY ON|OFF

Enable/disable history capturing. A path to the repository must be set. 

Note: If the process is stopped (Stop or Crash status), the command just starts it.

The command writes the list of the names registered by the GETACCESS action within the application (with the keyword PUBLIC) into the text console and to the log file (kernel.log) of the D2000 Server process.
The list contains the owner of the registered name as follows:
computer_name;process_name;event_name/activepicture_name

Example:
ACCESS LIST BEGIN
GETACCESS : "RegisteredName" is locked by : ComputerName;SELF.EVH;E.EventName
GETACCESS : "RegisteredName2" is locked by : ComputerName;ComputerName.HIP;S.PictureName
ACCESS LIST END

• start parameters of process D2000 Server,
• configuration parameters of D2000 system installation common for all applications,
• parameters of process D2000 Server specified in Windows registry (specific for running application),
• in redundant systems parameters of redundancy specified in Windows registry (specific for running application),
• parameters specific for ODBC and OCI versions of process D2000 Server.
• detailed information on the number and structure of the tags
  For Structured Variables: Object Name; the number of tags; the number of tags according to the methodology into the version D2000 V11
  ;D2RECORD;SV.DaE_Export_Head; 0; 11
  For Structured Eval Tags: Object Name; the number of tags;
  ;CLC_VAL Struct;P.TASK_SUM_Pending; 13
  
  Summary information on the contribution to the total number of tags for each object types:
  Number of tags for structured variables from V11 and to V11
  ;D2RECORD;Summary V11+; 9126
  ;D2RECORD;Summary OLD; 49044

  Number of tags for structured eval tags
  ;CLC_VAL Struct;Summary; 314
  
  Number of tags for eval variables
  ;CLC_VAL;; 98
  Number of tags for I/O tags
  ;POINT;; 25
  Number of tags for user variables
  ;USER_VAR;; 2095
  Number of tags for remote objects
  ;REM_OBJ;; 2
  The total number of application tags
  ;TOTAL TAGS;; 11510

Shows dynamic information on the specified object (list of objects that dynamically or statically use the object) on the text console of the D2000 Server process.

Note: The command is intended to be used mainly for the D2000 system diagnostic purposes.

Note: The command is intended to be used mainly for the D2000 System diagnostic purposes.

Example:
D2000 on OpenVMS platform: STDOUT "_TNA2:" (output is redirected to the terminal _TNA2:)
D2000 on Windows platform: STDOUT C:\output.txt (output is redirected to the file output.txt)

Note: If a D2000 process is run on the Windows platform as a service, the console output is disabled.

• Path - defines the path for saving the configuration.
• FileName - defines the name of the output file. E.g. for the "systemtxt" file, a file with the name "systemtxt.xml" is created.
• TableName - defines the table of the database, from which the configuration is to be exported.
  TableName can acquire the following values: SYS_COLORS, SYSTEM_TEXT, TRANS_MASKA, DICTIONARY, LANGUAGES, LOGDEF, NAME_RULES.

Warning: Extension ".xml" is added automatically, do not explicitly specify it.

XML file(s) import of a specific file or of all XML files from specified directory, depending on path_to_dir / path_to_file parameter:

path_to_dir - directory name with XML files (eg D:\temp). Note - the directory is searched for xml files recursively.

path_to_file - absolute path to the XML file (eg D:\temp\H.Sec.xml)

For this TELL command to be executed, a configuration key must be present!.

The path for the file import on VMS should be entered in Unix format.
Correct syntax: /DKB0/d2000/d2000-app/RIS_ROVE/XML/
Incorrect syntax: DKB0:[d2000.d2000-app.RIS_ROVE.XML] - this syntax is not supported, import of directory containing XML files ends with an error

The import of one file supports both records:
Correct syntax: /DKB0/d2000/d2000-app/RIS_ROVE/XML/file.xml
Correct syntax: DKB0:[d2000.d2000-app.RIS_ROVE.XML]file.xml

Note: The command belongs to the "security" TELL commands. I.e., it can be activated only from interactive processes with configuration key or from process D2000 Event Handler.

• Path - defines the path from which the configuration will be read.
• FileName - defines the name of the input file without XML extension. For example, "systemtxt" for the file with the name "systemtxt.xml".
• TableName - defines the table of the database to which the configuration is to be imported.
  TableName can acquire the following values: SYS_COLORS, SYSTEM_TEXT, TRANS_MASKA, DICTIONARY, LANGUAGES, LOGDEF, NAME_RULES.
• CleanTable - defines whether the table in the database will be cleaned before import.
  This parameter is optional, the default value is FALSE.
  The parameter can acquire two values: TRUE - clean table, FALSE - the table is updated.

The initialization of the TELL command is conditioned by using the configuration key.

Note: The command belongs to the "security" TELL commands. I.e., it can be activated only from interactive processes with configuration key or from process D2000 Event Handler.

Note: The command belongs to the "security" TELL commands. I.e., it can be activated only from interactive processes with configuration key or from process D2000 Event Handler.

Note: This command fails if the archive parameter DropOldRequests has value 1 because in this case the recalcs would be again stored to the file after being read.

• the parameter before is not defined - for individual archive objects, there will be deleted all data that are older than the history depth (the parameter History depth) defined in the configuration of the objects,
• the parameter before is defined - there will be deleted all data with the timestamps older than defined by the parameter before.

Example:
DP ON H.Test1 3 4 - enables debug information for the item of structured historical value H.Test1 on row 3 and column 4
DP ON H.Test2 - enables debug information for historical value H.Test2 (for all items if the object is a structure)
DP OFF 1234 0 4 - disables debug information for the whole column 4 in the structured historical value with HOBJ=1234

By default, debug information shows just the time and the value of historical value. Enabling the debug category DBG.ARCHIV.DATA (in the process D2000 System Console or using the start parameter /E+DBG.ARCHIV.DATA when starting the process D2000 Archiv), allows to show the complete stored data designed for the D2000 System developers:
Time (archive value time)
Value (value)
Status (a True/False array containing Valid, ProcAlarm, NoAckPAlarm, PrAlSilent, Weak, NoAckValue, Transient, Default, Manual, AlCrit, Unknown values)
Limits (one of the value of InLimit, VL_Limit, L_Limit, H_Limit, VH_Limit, LimitsProblem)
ArchFlags (a True/False array containing Start, Stop, Block, UnBlock, Deleted, UserModify, OldVal, ProcesModify, LoadData, MONO_TIME, K, L, M, N, O, Ver1 values)

• for Sybase - name of a depository database
• for Oracle - number of depository tablespace
• for PostgreSQL - number of a depository database

The command is used to force the reading of the last values of the specified objects from the archive database. Objects can be specified by name/mask and by type:

• SCRIPT - script
• PRIMARY - primary archive objects
• STATISTIC - statistical archive objects
• EVAL - calculated archive objects
• ALL - all types of archive objects

If e.g. in the test environment the inserting of values of script-filled archives is not possible, but these are inserted into the archive database by the arcsynchro utility, it is possible to execute this command after the insertion is completed (e.g. RELOAD_VALUES * STATISTIC). Subsequently, a read (e.g. of all script-filled archive objects) is performed and recalculations of archive objects that depend on the read objects can be initiated.

Note: For Oracle, PostgreSQL, and Sybase 8.0 (and above) platforms only.

On-line reorganization of archive table of an object with specified HOBJ or with a name matching the specified mask. If the parameter tablespace is also defined, the given archive table will be moved to the specified tablespace. If time slices are on, all slices of one archive object will be reorganized/moved unless a slice number slice is specified.

Note 1: The parameter tablespace can be used on Oracle and PostgreSQL platforms only.
Note 2: The slice number, except for ordinary values, supports special values:

• value -1 means "all slices"
• value -2 means "slice for current time"
• value -3 means "previous time slice"
• value -4 means "all slices older than current time slice"
• value -5 means "only those archive objects that do not have time slices" (if time slices are configured only for structured archives, then only simple ones will be reorganized)

Note: The command is mainly intended for D2000 system diagnostic purposes.

• start parameters of the process specified in the configuration of the archive process (if the archive process is run by process D2000 Server), or archive service (if the archive process is run by its own watchdog), or command-line parameters (if the archive process is run manually),
• parameters for archive specified in Windows registry,
• parameters stored directly in the archive database in the LOG_DATA table (see the parameter /CLD of arcsynchro utility),
• specific parameters of the database (currently only for the Oracle platform).

Example:
D2000 on OpenVMS platform: STDOUT "_TNA2:" (output is redirected to the terminal _TNA2:)
D2000 on Windows platform: STDOUT C:\output.txt (output is redirected to the file output.txt)
Note: If a D2000 process is running on the Windows platform as a service, the console output is disabled. Therefore if this functionality is required, it is necessary for a D2000 process to be started by D2000 Server without /X parameter.

The Id parameter specifies the number of a depository database whose data is to be compressed. The SEGMENT seg parameter, where seg is the number of the depository database segment (between 0 and TrezorCountSegments), allows you to compress a specific depository segment if depository segment creation is enabled.
Note: The compression of a depository is possible if it is mounted for writing (see MOUNT_TREZOR command with WRITE parameter).

The Id parameter specifies the number of a depository database whose data is to be decompressed. The SEGMENT seg parameter, where seg is the number of the depository database segment (between 0 and TrezorCountSegments), allows you to compress a specific depository segment if depository segment creation is enabled.
Note: The decompression of a depository is possible if it is mounted for writing (see MOUNT_TREZOR command with WRITE parameter).

• I/O tag with specified HOBJ,
• all I/O tags on the station with specified HOBJ,
• I/O tags with the name matching the given mask,
• all I/O tags on the stations with the names matching the given mask.

The command allows switching between the primary (OFF or PRIMARY) and backup (ON or BACKUP) devices for lines of categories "SerialOverUDP Device Redundant", "SerialOverUDP Line Redundant", and "SerialOverUDP System&Line Redundant", or discovering the active device (QUERY). The active device is used to write UDP packets and packets received from it are processed. Data received from the inactive device is ignored. Similar functionality is also supported for lines of the "TCP/IP-TCP System Redundant" category - the TCP connection is connected to a primary or backup device.

The third parameter (numbers 1-4) specifies the subline. For a line of category the category "SerialOverUDP Device Redundant", it need not be specified or must be equal to 1. For a line of category the category "SerialOverUDP Line Redundant", it can be equal to 1 (the device on the Primary line is set) or 2 (the device on the Secondary line is set). For a "SerialOverUDP System&Line Redundant" or  "TCP/IP-TCP System Redundant" category line, it can be equal to 1 - 4 (the device on the Primary/Secondary line of the system A/B is set). If an active device is detected (QUERY) and the third parameter is not entered, all active devices are listed (1, 2, or 4 depending on the line type).

The command is also applicable on the OPC UA Client line in the OPC Unified Architecture Data Access Client protocol for Client Type=Default. Using the command, it is possible to find out which of several specified hosts the D2000 KOM process is connected to (QUERY) or to force a connection to a specific one (ON, third parameter set to 1 .. N).

The command is also applicable on RFC2217 Client, TCP/IP-TCP, and TCP/IP-TCP Redundant lines. With the help of the command, it is possible to find out which of several specified hosts the D2000 KOM process is connected to (QUERY, or QUERY PRIMARY/BACKUP) or to force a connection to a specific one (PRIMARY/BACKUP, third parameter set to 1 .. N).

Examples of use:
LNALTERPATH L.MyLine ON 3
LNALTERPATH L.MyLine BACKUP 3
LNALTERPATH L.MyLine QUERY

Return codes:

• SUCCESS - transaction successful, data transfer to the system finished,
• IGNORED - the process D2000 KOM is not running in the mode of KOM Archiv,
• ERROR - invalid parameters (time format: dd-mm-yyyy hh:mi:ss), wrong sequence of entered times - BeginTime > EndTime.

The command de-configures the object (line or station) and its descendants (stations, I/O tags) and reloads them. The command can be used to apply configuration changes that would otherwise require restarting the KOM process. The command is currently implemented for protocols:

• IEC 60870-6 ICCP/TASE.2
• IEC 870-5-101 (client, server, balanced mode)
• IEC 870-5-104, IEC 870-5-104 Server
• Modbus Client, Modbus Server
• OPC UA Client

Return codes:

• SUCCESS - changed address (the value of the I/O tag is invalid until it is read from the new address).
• IGNORED - The D2000 KOM process does not support dynamic address change for the specified protocol.
• ERROR
  1. duplicate address
  2. point not found
  3. bad address format

Dynamic change of the I/O tag address is implemented only for a limited group of communication protocols:

• AMiT ATOUCH32 DB-Net
• BACnet
• General Electric SRTP protocol
• Honeywell C-Bus
• L&G TOCCATA
• L&G TOCCATA via UNIP2
• MODBUS Client
• OPC Data Access 2.05 & 3.0 Client
• Siemens SAPHIR
• SNMP

Return codes:

• SUCCESS - changed address,
• IGNORED - The D2000 KOM does not support a dynamic change of address for the specified protocol,
• ERROR
  1. object not found
  2. invalid number of parameters

Dynamic change of address is implemented only for a limited group of communication protocols:

• ALYA Lubrikacie
• MODBUS Client
• MODBUS Server
• MODBUS Telemecanique TSX
• MODBUS Valmet Damatic RTU
• MODBUS RTU Quad2000
• MODBUS SCT PPU

Example:
Data files, recorded by the TELL command:
START_RECORD DirName "01-12-2008 08:22:27" "01-12-2008 11:02:07"

These four data files (it relates to four hourly intervals) are the result of recording:
KOM-SELF_2008_12_01_08.dat < 01-12-2008 08:22:27 ; 01-12-2008 09:00:00 >
KOM-SELF_2008_12_01_09.dat < 01-12-2008 09:00:00 ; 01-12-2008 10:00:00 >
KOM-SELF_2008_12_01_10.dat < 01-12-2008 10:00:00 ; 01-12-2008 11:00:00 >
KOM-SELF_2008_12_01_11.dat < 01-12-2008 11:00:00 ; 01-12-2008 11:02:07 >

Note: The TELL command uses "dd-mm-rrrr hh:mm:ss" format for the parameters of DateTime type.
It is possible to initialize this TELL command from the D2000 Server, as well as directly from the clients (currently only from the D2000 KOM and Gateway Client processes).
Data are recorded into the specified subdirectory in the application directory, where a separate data file is created for every hourly time period.

Note: It is possible to start up this TELL command from the D2000 Server, as well as directly from the clients (currently only from the D2000 KOM and Gateway Client processes).

Example of data replaying:
Time Stamp (TS) - blue color, current time (CT) - red color

If /LOOP is used, data replaying will be again started automatically. It can be stopped by the STOP_REPLAY command.

Note: This TELL command uses the "dd-mm-rrrr hh:mm:ss" format for the parameters of DateTime type.
It is possible to start this TELL command from the D2000 Server, as well as directly from the clients (currently only from KOM client).
The  D2000 KOM process can be started up in replay mode only with the start parameter /Replay. It causes the process D2000KOM not to communicate with devices.

Note: There is possible to start up this TELL command from the D2000 Server, as well as directly from the clients (currently only from KOM client).

Example:
D2000 on OpenVMS platform: STDOUT "_TNA2:" (output is redirected to the terminal _TNA2:)
D2000 on Windows platform: STDOUT C:\output.txt (output is redirected to the file output.txt)
Note: See a note for STDOUT command for D2000 Archiv.

The first form of the command enables the communication (the parameter  START) or disables the communication (parameter STOP) with the StationName station. The station will get the StON (START) or StOFF (STOP) value.

The second form of the command sets the station's value to a communication error (StComErr or StHardErr). This form can be used for some communication protocols (e.g. KNX protocol, MQTT Client) if there is an external way to detect the outage (e.g. the value of I/O tag serving as a watchdog doesn't come in time).

For protocols based on periodic polling of I/O tags (request-response protocols): the command generates one or several requests for priority reading of all I/O tags on a specified station. The Number parameter defines the number of requests, possible value is within 1...5. If the parameter is not specified, a single request will be generated.

For protocols based on sending of changes (change-based protocols): the command generates one or several requests for the reading of all data. The command is implemented for a selected set of communication protocols:

• BACnet (sends ReadProperty, ReadPropertyMultiple, and Subscribe messages depending on the configuration of I/O tags)
• DNP3 (sends requests for reading of all configured Poll Classes specified in the configuration of station parameters and for reading of values of all objects with "Explicit read" enabled)
• IEC 60870-6 ICCP/TASE.2 (sends requests for reading values of all I/O tags)
• IEC 61850 (sends requests for reading values of all I/O tags)
• IEC 870-5-101 (sends Interrogation Command/Counter Interrogation Command depending on station protocol parameters)
• IEC 870-5-104 (sends Interrogation Command/Counter Interrogation Command depending on station protocol parameters)
• IEC 870-5-104 Server (sends Interrogation Command/Counter Interrogation Command depending on station protocol parameters)
• IEC 870-5-104 Sinaut (sends Interrogation Command/Counter Interrogation Command depending on station protocol parameters)
• OPC Data Access (sends requests for synchronous reading values of all I/O tags)
• OPC UA (sends requests for reading values of all I/O tags)

MONITOR_TRANS SHOW {ALL/<id>} [<file_path>]

MONITOR_TRANS ON <history_depth_sec>

MONITOR_TRANS OFF

MONITOR_TRANS RESET

The mechanism for monitoring of the transactions.

ON - activates the monitoring. <history_depth_sec> means a time-depth history of closed transactions.
OFF - deactivates the monitoring
RESET - resets the list of transactions (including the opened ones)
SHOW - shows either the list of transactions including the history (ALL) or the particular transaction (<id>) to a console or file <file_path> in CSV format separated by ";"

Columns in the list:
- ID (transaction identifier)
- time, task, traceback (time the last operation within the group of identical ones, task, traceback in the internal code)
- comment, count (the last comment and the number of consecutive identical operations) (the identical operations has the same task and traceback)

Note: After starting DBManager, the monitoring is switched off.

MONITOR_CONNECTS SHOW {ALL/<id>} [<file_path>]

MONITOR_CONNECTS ON <history_depth_sec>

MONITOR_CONNECTS OFF

MONITOR_CONNECTS RESET

Monitoring the connections.

ON - activates the monitoring. <history_depth_sec> represents the time-depth history of closed connections.
OFF - deactivates the monitoring
RESET - resets the list of connections (including the opened ones)
SHOW - shows either the list of connections including the history (ALL), or the particular connection (<id>) to a console or file <file_path> in CSV format separated by ";"

Columns in the list:
- ID (auxiliary identifier of connection)
- logon_time, logon_task, logon_traceback (time of connection, task and traceback in internal code)
- logoff_time, logoff_task, logoff_traceback (time of disconnection, task, and traceback in internal code)
- comment (the last written comment for the given connection, e.g. traceback in ESL code)

Note: After starting DBManager, the monitoring is activated with the time-depth history of closed connections which is 3 hours (10 800 seconds).

The command allows you to close and reopen connections to the database that are not currently in use (there is no transaction in progress or a cursor in use).

Note: This command was implemented to work with temporary tables in PostgreSQL. These are only dropped when the database connection ends, and while they exist, the data in them is not visible outside the database connection that inserted them, so they cannot be accessed by vacuum, and therefore internal transaction IDs (XIDs) can be exhausted if a connection is open for a long time.