general.dialer Definition/General

general.dialer

Command general.dialer Definition/General
Applicable release versions: AP 6.1
Category General (155)
Description defines a subsystem which allows Advanced Pick systems to communicate over serial lines to transfer items, execute commands on remote sites and to synchronize data bases by transferring updates. This section is a general introduction to the dialer subsystem. See the section "dialer, TCL" for a detailed description of the TCL command.


Overview :
The dialer subsystem is a set of processes running on each system, which communicate with each other at predetermined times set by the System Administrator, in a batch mode. The main functions are:
- Copying items from system to system(s) (See the section "dialer-copy, TCL".
- Submitting commands for remote execution on a system (See the section "dialer-submit, TCL".
- Synchronizing a data base across several machines. The data base is replicated on each system, and updates made on the various systems are propagated to the other systems. For example, if the attribute 2 of item A is modified on system M1, and the attribute 3 of the same item A is modified on the system M2, the dialer subsystem will transmit both updates to the machines so that they are applied to all systems.
The various systems on the network are identified on each system by a name and the phone number(s) where they can be reached.
All communication is protected by an authentication process which makes sure the remote system are allowed to call in, to submit commands and to make updates to the data base.

Definitions :
"Local System"
The local system represents the system where the user is currently connected to.

"Remote System"
A remote system is a system which is accessible from the local system. Note that all systems must be known to all other systems, for security reason. On large network, the maintenance of the list of systems can be cumbersome, so it might be advised to maintain the list of all systems on one central administration machine which has to be declared manually to all other systems, and use the dialer copy capability to copy the list to all other sites.

"Serial Device"
The System Administrator designates one or more serial devices to be used by the dialer subsystem. The devices can be dedicated to the dialer subsystem, or they can be shared (not at the same time, of course) with regular terminal activities. For example, a modem line can be used during the day for remote logon, and used at night for data transfer. The serial devices are identified by a unique name. See the section 'Sharing a Serial Device' below.
Serial devices can be designated as input only (they cannot call another system), output only (they refuse incoming calls), or mixed (they can either call or accept incoming calls). Input only channels are useful for configurations where a system may receive calls from many other systems. It reduces the probability that calls will be refused because the system is busy calling other systems. Note that an input only serial CAN transmit data to another system: it does so only after this other system has sent all it had to send.
IMPORTANT: The device MUST be able to support 8 bit characters to be able to transmit the Pick system delimiters ( char(253), char(254), char(255) ).


"IO Daemon"
An IO daemon is a Pick background phantom process which performs all IO. There is one IO daemon per enabled serial device used for the communication.

"Dialer"
A dialer is a program responsible for managing a communication device (a modem). It understands the particular protocol required to instruct the modem to dial a number, hangup, etc... A dialer is normally associated to a serial device. Currently, only the 'hayes' dialer is provided. It may be necessary to modify the dialer program to adapt to a special modem type.

"Update Posting'
For the dialer subsystem to transmit an update to other systems, the system must be made aware of the fact that an update took place. This is done by inserting a CALLX call to "dm,bp, dialer.post" in the correlative (attribute 8) of the D pointer of the file being updated. The dialer front end menu allows to do this on whole accounts. When an item is filed, the "dialer.post" subroutine compares the old and the new item and build a 'difference string' which describes what has changed: the original value, the old value and where it has changed. This not only allows a description of the change, but it also reduces the amount of data that has to be transmitted. The changes are determined at the value level. In other words, if the second value of an attribute has been changed, for example, only the second value is transmitted. If a subvalue is changed, the whole value is transmitted. If more than one change is made to an item, the changes are merged, so that only one record of the change is kept, and only one transmission occurs. For example, consider the item 'A' updated as follows:

Old New
--- ---
A: -----> A:
001 a 001 A
002 b 002 b
bb bbb
bbb 003 c
003 c
The data transmitted is:
- Change attribute 1 from 'a' to 'A'
- Change value 2 in attribute 2 from 'bb' to 'bbb'
- Delete value 3 in attribute 2

"Conflicts"
When a system receives an update from another system, the updates are applied to the local item. However, the receiving system checks for conflict by making sure that the 'old value' received from the remote system is identical to the 'old value' on the local system. For example, consider two systems M1 and M2, where the item 'A' is updated:
System M1
---------
A: -----> A:
001 a 001 a
002 b 002 b
bb BB
bbb bbb
003 c 003 c

System M2
---------
A: -----> A:
001 a 001 a
002 b 002 b
bb bb
bbb BBB
003 c 003 c

In this example, there is no conflict, and the resulting item will have both changes in the 2nd and 3rd values on the second attribute. However, consider the following:
System M1
---------
A: -----> A:
001 a 001 a
002 b 002 b
bb BB
bbb bbb
003 c 003 c

System M2
---------
A: -----> A:
001 a 001 a
002 b 002 b
bb BBB
bbb bbb
003 c 003 c

In this example, there is a conflict, because the system cannot determine whether 'BB' or 'BBB' is 'right' for the 2nd value of the third attribute. The update will be logged as conflict on BOTH systems, will NOT be applied to either data base and the System Administrator will have to resolve it by determining which, if any, is correct. A 'copy' operation can then be done to transfer the correct version to the other system. The dialer menu has an option to show the conflicts, at what times (adjusted by the different time zones) they occurred, and what the conflict is.

"System Map"
The system map defines to which systems an update is to be transmitted. The granularity is the account, but it is possible to define an exception list, to send selected files to a different system. Updates can be sent to more than one system. The system map is created using a dialer menu option. For performance reason, the system map is kept in a named common. Therefore, if the system map is changed, the user processes must be logged off and logged back on.
IMPORTANT: The dialer.post routine must be able to determine the actual account in which the file being updated resides. The account in which the application is run must either own the file (i.e., have a D pointer), or have a valid direct q-pointer to the actual file. Explicit path names (i.e., 'dm,bp,') are not permitted, nor q-pointers to q-pointers.

"Billboard"
The billboard is a system wide file which contains a record for each posted update not yet being transmitted. This file is checked every time an update is posted to be able to merge the various changes made to an item. On large systems, it might be necessary to resize that file.

"Spool"
The spool file contains the actual data to be transmitted. The spool items are referenced by other elements of the dialer subsystem.

"Queue"
A special queue file is created for each remote system. This queue contains a linked chain of requests to be sent to a given system. The body of the request is not stored in this file. In the case of a 'copy' operation (copy an entire item), the body of the item is either left in the original file, or is copied into a 'spool' file. In the case of an update item (result of posting an update), the difference string is stored in the spool file.


Sharing a Serial Device :

Mosts systems will not be able to have one serial port and modem dedicated to the dialer subsystem. More likely, the modem port will be used for remote maintenance, remote logon for most of the day. It is however possible to instruct the dialer subsystem to take over the serial port for a specified period, for example from midnight to 2:00 a.m. every day, to call remote systems, or to accept incoming calls from other systems. This way, the port can be used normally during the day. This is done when declaring the serial devices to the dialer subsystem, using the following convention:
- A dedicated device number is prefixed by a 'S'
- A shared device number is the Pick process number to which the device is normally linked to.
For example, 'S119' designates a dedicated serial port. '200' represents a shared serial device. The dialer subsystem, when it is time to establish a communication, will steal the device associated to the Pick process '200' (usually the device '200') by doing an 'unlink-pibdev' to free the device. If the process was logged on to a user, it is logged off prior to the stealing and the modem is hung up.


Dialer Programs :

A dialer program is a Pick/BASIC subroutine which handles the modem specific protocol. These programs must be stored and compiled in the file 'dm,bp,dialers'. They do not need to be cataloged in any account. The module 'hayes' handles the Hayes AT protocol. This module can be used as an example to develop custom dialer programs. The commands the subroutine must be able to handle are:
- DIAL$IDENTIFY
Return an identification string (type and version number). This string is for information purpose only. It should return at least the dialer name and version, and may interrogate the modem itself to get its type and revision number.
- DIAL$RESET
Reset the modem. This command must set the modem in an appropriate state for a dial command to succeed and to accept incoming calls. This command may be sent in the middle of a communication, therefore, it must hangup any on going session.
- DIAL$CALL
Dial out. The argument is the phone number, including any special characters required for the modem and/or the phone system (prefix, pauses, ...). The return code, is positive, is an indication of the communication speed, expressed in bauds. If unknown, the dialer must return 0 for a successful dial out.
- DIAL$HANGUP
Hangup the modem. This command is sent in the middle of a communication to interrupt it.
- DIAL$DEFAULT
Reset the modem to the factory defaults.
Syntax
Options
Example
Purpose
Related tcl.dialer
tcl.dialer-copy