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.
Top
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:
-
a
user code (20 characters maximum),
-
one
or two passwords (20 characters maximum),
-
a
chosen application (8 characters maximum),
-
a
date in the format YYMMDD or in format N meaning to
days date - N (optional),
-
a
sequence number (6 characters maximum, optional) ,
-
two
free selection criteria (each 8 characters maximum,
optional),
-
the
number of records to be received by the server (8 characters
maximum, optional).
Top
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.
Top
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.
Top
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.
Commercial doc.
