|
CTFS can be used to perform a number
of features and functions. Some of these features and functions
are described below.
Back to top
ALC Terminal Feature
This feature allows ALC terminals on a TPF server machine
to redirect the processing to be performed on the CMSTPF user
machine instead of on the server machine.
With this feature, the ALC network belongs to the TPF Server,
and when a transaction is entered on the ALC terminal the
transaction is initially read by the server and then re-directed
(routed) to the individual CMSTPF user who requested intercepting
transactions for the specific LnIaTa.
The network belongs to the TPF Server machine, and there
is no network on each CMSTPF user machine. The TPF server
is a stable virtual machine executing TPF and providing only
network, communication services and other functions. Each
CMSTPF user machine performs all the application level processing
for the transactions being executed on the ALC terminal. Updates
to databases, etc. are done on the individual CMSTPF machine
and not on the TPF machine where the physical ALC terminal
is connected.
To test the transaction, the user uses all the features of
CMSTPF to trace the transaction, load programs, etc. Any non-stable
code (new code, modified code, etc.) resides on the individual
CMSTPF user machine, and not on the TPF Server, which is being
used by all CMSTPF users and other TPF users.
When input is received from the ALC terminal, it is queued/re-directed
to the CMSTPF user virtual machine, where it executes to completion.
When the application program on the CMSTPF user virtual machine
sends a reply (ROUTC) to the terminal, CMSTPF on the user
virtual machine recognizes that the terminal is physically
connected to the TPF Server, and CMSTPF uses CTFS to redirect
the output back to the TPF Server, which on receipt will send
the output back to the ALC terminal.
This feature enables installations with ALC terminals to
test transactions from the ALC terminal in CMSTPF, even though
the terminal is physically not connected (or in session) with
CMSTPF.
The advantage provided with this approach is that the TPF
Server machine executes only stable code, and the CMSTPF machine
executes any test level code.
Back to top
ALC Boarding Pass Printer Feature
This feature allows CMSTPF Users to route output to a physical
Boarding Pass Printer, even though the Boarding Pass Printer
is not physically connected to the user's CMSTPF session.
With the current release of CMSTPF, if an application program
sends output to a Boarding Pass Printer, CMSTPF understands
that there is no physical Boarding Pass Printer, and interprets
and writes the output to a CMS file.
With CTFS, the user connects to the TPF Server, which has
the physical Boarding Pass Printer. Once CTFS is connected,
the user would enter transactions which send output to the
Boarding Pass Printer, when output is sent to the Boarding
Pass Printer, CMSTPF recognizes that the physical printer
is connected via CTFS, as such, the output is re-directed
to the TPF Server, where the route is done to the physical
Boarding Pass Printer.
Since the Boarding Pass Printer is an output only device,
and can be used by multiple CMSTPF clients (users), the device
is defined in the TPF Server as being a shared resource, that
can be connected by multiple CMSTPF clients (users).
The advantage provided with this approach is that each CMSTPF
user has access to a physical Boarding Pass Printer, without
the Boarding Pass Printer being physically connected to the
user's CMSTPF session.
Back to top
ALC Ticketing Printer Feature
This feature allows CMSTPF Users to route output to a physical
Ticketing Printer, even though the Ticketing Printer is not
physically connected to the user's CMSTPF session.
When output is sent to a Ticketing Printer, normally, an
answer-back is generated by the physical Ticket Printer, and
this answer back needs to be passed back to the application
program, so that the application program can perform any clean-up
processing, relating to the ticket.
With the current release of CMSTPF, if an application program
sends output to a Ticketing Printer, CMSTPF understands that
there is no physical Ticketing Printer, and interprets and
writes the output to a CMS file. Since no physical printer
is defined, answer-backs are accomplished in the current environment,
by user developed execs to simulate the answer back.
With CTFS, the user connects to the TPF Server, which has
the physical Ticketing Printer. Once CTFS is connected, the
user would enter transactions which send output to the Ticketing
Printer, when output is sent to the Ticketing Printer, CMSTPF
recognizes that the physical printer is connected via CTFS,
as such, the output is re-directed to the TPF Server, where
the route is done to the physical Ticketing Printer.
CTFS invokes User Exit routines, to enable the User Exit
Routines, to keep track of relevant context data, so that,
on receipt of the Answer Back, the Answer Back can be sent
back to the originating (correct) CMSTPF client (user) which
routed data to the Ticket Printer. The User Exit Routines,
need to manage and keep track of the context data to ensure
that the Answer Back is sent back to the correct CMSTPF client
(user).
The advantage provided with this approach is that each CMSTPF
user has access to a physical Ticketing Printer, without the
Ticketing Printer being physically connected to the user's
CMSTPF session.
Since multiple CMSTPF clients (users) share the Ticketing
printer, the Ticketing printer is defined as a shared resource
in the TPF server.
Back to top
ALC Host-to-Host Feature
This feature enables CMSTPF clients (users) to request and
receive data from other hosts, even though the other hosts
are not physically connected to the user's CMSTPF session.
With the current release of CMSTPF, if an application program
needs data from another host, it cannot retrieve data from
the other host, because no physical connection exists to the
other host (links). Because of this, certain application transactions
cannot be tested under CMSTPF.
With CTFS, the user would connect to the TPF Server which
has connection to the other host (links). Once CTFS is connected,
the user would enter transactions that send requests to the
other host. When one of these requests is made, CMSTPF will
re-direct the request to the TPF Server, since the TPF Server,
has connection to the other host. The route is done on the
TPF Server to the other host, and on receipt of the reply/response,
the reply/response is re-directed back to the waiting CMSTPF
client (user).
CTFS invokes User Exit routines, to enable the User Exit
Routines, to keep track of relevant context data, so that,
on receipt of the reply/response, the reply/response can be
sent back to the correct CMSTPF client (user) which routed
request to the other Host (links). The User Exit Routines
need to manage and keep track of the context data to ensure
that the reply/response is sent back to the correct CMSTPF
client (user).
The advantage provided with this approach is that each CMSTPF
user has access to other Hosts (links), without the other
Hosts (links) being physically connected to the user's CMSTPF
session.
Since the Host to Host connection (links) is expected to
be shared by multiple CMSTPF clients (users), the resources
that make up the Host to Host (links) connection are defined
as shared resources in the TPF server.
Back to top
SNA Terminal Feature
This feature allows SNA terminals on a TPF Server machine,
to redirect the processing to be performed on the CMSTPF User
machine, instead of on the TPF Server machine.
This implementation of CTFS, is to allow CMSTPF Users to
inform the TPF Server machine, that they (the CMSTPF User)
would like to handle transactions from an SNA Logical Unit
(SNA LU).
With this feature, the SNA network belongs to the TPF Server,
and when a transaction is entered on the SNA terminal, the
transaction can be re-directed (routed) by the TPF Server
to the individual CMSTPF User who requested intercepting transactions
for the SNA LU.
Using this approach, the network would belong to the TPF
Server machine, and there would be no network on each CMSTPF
user machine. The TPF Server would be a stable virtual machine
executing TPF and providing only network, communication services
and other functions. Each CMSTPF user machine would perform
all the application level processing for the transactions
being executed on the SNA terminal. Updates to databases,
etc. would be done on the individual CMSTPF User Id, and not
on the TPF machine, where the SNA terminal is connected.
To test the transaction, the user would use all the features
of CMSTPF and TPF/GI to trace the transaction, load programs,
etc. With this approach, any non-stable code (new code, modified
code, etc.) would be on the individual CMSTPF User machine,
and not on the TPF Server, which is being used by all CMSTPF
Users and other TPF users.
With this implementation, when input is received from the
SNA terminal, it is queued/re-directed to the CMSTPF User
Virtual machine, where it executes to completion. When the
application program on the CMSTPF User Virtual machine sends
a reply (ROUTC) to the terminal, CMSTPF on the User Virtual
machine recognizes that the terminal is physically connected
to the TPF Server, and CMSTPF uses CTFS to redirect the output
back to the TPF Server, which on receipt will send the output
back to the SNA terminal.
This feature enables installations with SNA terminals to
test transactions from the SNA terminal in CMSTPF, even though
the terminal is physically not connected (or in session) with
CMSTPF.
The advantage provided with this approach is that the TPF
Server machine executes only stable code, and the CMSTPF machine
executes any test level code.
Back to top
Black Box Encryption/Decryption Feature
This feature enables CMSTPF users to do encryption/decryption,
without each user having a physical encryption/decryption
machine connected to their user virtual machine. There would
be one encryption/decryption device (black box) which will
be directly connected to the TPF Server. When a CMSTPF User
needs this function (encryption/decryption), the CMSTPF User
will use CTFS to request the TPF Server to perform the function.
This Feature is not part of the base product, and can be
accomplished in CTFS Rel 1.0 using User Exits, since the communication
between the Black Box and the TPF Server most probably is
a customer unique protocol. User Exits are available within
CMSTPF and CTFS, and can be used to implement this type of
function.
Back to top
SQL Database-TPF/AR Feature
TPFAR provides TPF application programmers with the ability to store or
retrieve data from a relational database which supports the DRDA interface
(Distributed Relational Database Architecture). TPFAR is used by customers to
store customer related files (frequent flyer information, etc.). TPF Applications
using TPFAR call the relational database in real time to store and to
retrieve customer information.
Since the relational database is on an OS390 or Oracle database, TPF
application programmers who use CMSTPF and TPFGI need a mechanism to access
this relational database. Using CTFS, TPF applications now have access to
the relational database.
When an application program does a DRDA (SQL) call, CMSTPF intercepts the
call, and sends the call through CTFS to the TPF Server machine, where the
DRDA (SQL) call is re-executed and sent to the OS390 or Oracle database. When the response is received on the TPF Server machine,
the response is sent back to the originating CMSTPF user.
This feature allows the TPF application programmer to test their
applications, even though they do not have physical connectivity to the
OS390 or Oracle database.
Back to top
|
