tbt/400.com French version
French version
  Home page Info. request Contact us Wished Evolutions Download

Sample of Etebac 3 Server

The server ETEBAC allows each station or client computer, to connect to TBT/400 in ETEBAC protocol to exchange files. The main functionalities are:

Access security

TBT/400 uses the internal directory. All of the ETEBAC correspondents have to be listed therein by a logical name, a name under which it will have to identified by a sign-on. The updates are immediately effected. To a correspondent, several attributes are associated, one of which is a pass-word, and an optional list of X25 call numbers. The correspondent will be able only therefore to call via ETEBAC 3, and exclusively from one of these numbers ( maximal security option). In addition, correspondents can either be authorized or not at the application level.


Applicative identification 

Once the call has been identified, and therefore the ETEBAC protocol utilized, an identity by application comes into play. This is effected by the reception and the decoding of a sign -on .

The structure of this sign-on is defined at installation time (location and each field length), with:

  1. a user code (20 characters maximum),

  2. one or two passwords (20 characters maximum),

  3. a chosen application (8 characters maximum),

  4. a date in the format YYMMDD or in format N meaning to days date - N (optional),

  5. a sequence number (6 characters maximum, optional) ,

  6. two free selection criteria (each 8 characters maximum, optional),

  7. the number of records to be received by the server (8 characters maximum, optional).


Provision of a file

Each file provided to be received by the client (R on the sign-on) will have been previously defined to TBT/400 via the transmission APIs. A file provided is a file transmitted by TBT/400 to an ETEBAC correspondent, for an application, a date and a defined sequence number. The transmission API validates this information against pre-defined elements (in Directory, list of applications). The various up-dates are synchronous, that is to say, with immediate effect. During of the delivery of a message, the status of the TBT/400 sub-system is unaffected: the delivery can be effected whether the driver is active or not. The transfer demand does not presume either BSC or X25 output.

Moreover, TBT/400 offer a flexibility at the level of files to be sent. For example, during the transmission request, a file copy option can be used, in which case TBT/400 frees up the initial file from the time of the delivery of the request, and will take in charge the cleaning up of the files according to various optional criteria:

  • purge after transmission to the network: in this case, the user can only process the file once .

  • purge linked to the history (based on a global retention criteria): the file is transferred to the history file after transmission.

  • purge not linked to the history (based on a global retention criteria): in the case of the automatic purging of components.


Treatment of an incoming call

When TBT/400 receives an incoming call type ETEBAC, it reads and decodes the sign-on, and after certain controls, accepts it or refuses it. In ETEBAC 3 the refusal represented by an answer NOKXXXX awaiting the following sign-on, and in ETEBAC 1 - 2 by a rupture of the communication.

The controls are:

  • validity of the transmission direction receive/transmit,

  • validity of the user code according to the directory,

  • validity of the number of the caller (if requested, in which case only X25 is authorized),

  • validity of the application,

  • validity of the date (by default to days date + a parameterable numeric increment)

  • validity of the sequence number (by default 1),

  • if in the sense transmission, validity of the presence of the file that has to be previously delivered. An installation option allows or not to the ability to receive the file several times .

When the access is authorized and validated, the transfer can be effected:

  • in the case of reception (A on the sign-on), a file is allocated dynamically, and a message type event is inserted at the end of the reception in the message queue. A processing application can be able to be initiated immediately by TBT/400, or by a later session.

  • in the case of an transmission (R on the sign-on), an acknowledgment event is deposited in the message queue, to inform the application. This event is deposited only during the first reception, if the multiple reception option is authorized.


Dual signature or order confirmation

TBT/400 allows you, as standard, to use an option of a double signature: in this case, the correspondent has to confirm their order by sending a second password, either whilst during the transmission of the file, or later during another transmission by the sending of a second sign-on with the second password. The file is not considered as being able to be processed until the two valid passwords have been received.


Functions & specifications

Summary of TBT400 functions

Directory functions

Programming help

Supervisory services

Miscellaneous functionalities

Applicative interfaces

Gateways with translators or messaging software

Example of Etebac3 server


Multi TBT


** new ** webTBT, module GUI

** new ** SNADS recovery

>> Download
technical documentations of TBT400

All rights reserved © 2015 IPLS - Legal informations >>Top Updated: Novembre 14, 2019 14:13