CTFS

CTFS (the CMSTPF Function Server) provides virtual connectivity to remote resources for CMSTPF and TPF/GI users.

Virtual Connections
During their normal operation, TPF application programs often need access to remote systems that are not conveniently available during ordinary TPF testing.

CTFS solves this problem by providing virtual connections. It enables multiple CMSTPF clients to connect to a TPF Server machine when access to external networks and resources are required and are not directly available on CMSTPF.

Using CTFS, users can request functions from a TPF server machine. CTFS acts as the communications vehicle for the requests, and the TPF server processes the requests.

Once the connection is established between the user's virtual CMSTPF machine and the TPF server machine, and a protocol is established for communicating between the two virtual machines, requests can flow from one machine to the other for processing.

Overview:
The Connectivity Problem in Testing
With distributed processing, transactions are no longer processed in a single system or environment, but instead are processed across multiple platforms and multiple systems.

This distributed environment raises the level of complexity for application programmers trying to test their transactions. Because of this new complexity, to test a transaction a programmer needs a complex testing environment—one that includes multiple networks, multiple platforms, and multiple systems.

Without this complex level of connectivity, only parts of the transaction can be tested, not the entire transaction. In addition, the programmer must try to simulate the response from the other environment to continue testing. However, setting up simulation routines and test cases takes a great deal of time and makes programmers less productive.

Possible Solutions
Any solution to this testing problem has to take two things into account. First of all, each programmer requires a certain level of isolation to reliably test application transactions. Second of all, at the same time the programmer requires connectivity to other networks, terminals, systems, and so forth for testing the remaining parts of the transaction.

One approach is to provide each programmer with a complete network, terminals, systems, and so forth. This naive approach would be very expensive, however, and would require a very large amount of resources, as well as duplicate sets of resources. Another approach would be to isolate the testing routines and provide server systems that do some of the common or already tested functions. However, this approach puts a great deal of stress on the testing organization and requires constant upkeep.

In our mind, neither of these approaches is satisfactory. What is needed is an in-depth test facility where programmers can test their transactions using enhanced trace, edit features, and source level trace features. At the same time, these programmers should have nearly transparent access to other networks or systems where certain sub-functions of the transaction being tested can be performed. And all this should be provided without intensive use of resources.

CMSTPF and TPF/GI already provide programmers with the powerful trace, edit and source level trace features with a minimum use of resources. The need for network connectivity is where CTFS steps in. With CTFS and a TPF server machine connected to a network, CMSTPF and TPF/GI programmers can perform the sub-functions (network functions, and so forth) needed by their transactions. Complete testing is possible without intensive resource use.

Features & Benefits
CTFS can be used to perform a number of features and functions. Some of these features and functions are described below.
  • ALC terminal feature
  • ALC boarding pass printer feature
  • ALC ticketing printer feature
  • ALC host-to-host feature
  • SNA terminal feature
  • Black box encryption-decription feature
  • SQL database-TPF/AR feature

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.

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.

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.

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.

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.

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.
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.

CTFS Benefits
Each TPF/GI user no longer needs to have direct connectivity to all devices and the network. The devices or network can be connected or owned by the TPF Server machine. When the TPF/GI User wishes to test from a terminal that is not connected to the CMSTPF User virtual machine, the user can inform the TPF Server, using CTFS, that all traffic from the terminal is to be re-directed to the specific CMSTPF User Virtual machine.

Similarly, if the user needs functions performed, for which the user does not have connectivity to networks, devices, black boxes, etc., the user can use CTFS to request the TPF Server to perform the function on behalf of the TPF/GI user.

TPF/GI users now have access to functions which may not be directly available on CMSTPF, and which are available on a TPF Server machine. In this case, the CMSTPF User will use CTFS to request the function from the TPF Server.

With CTFS, TPF/GI users can now do Remote Procedure Calls to a TPF Server machine. The Remote Procedure Call can be input/output to network devices, encryption/decryption from a black box, etc. Certain Remote Procedure Calls are unique to an installation, and User Exits are available within CMSTPF to enable the installer to perform the Remote Procedure Call.

TPF/GI Users now have access to physical terminals and networks, which would have to be replicated, if CTFS was not available.

Since only stable code will be executed on the TPF Server, and non-stable (new code being tested) is executing on the CMSTPF user machines, there is less likely chance of the TPF Server failing.

The powerful trace features, edit features, source level trace, etc. of TPF/GI can now be used to trace transactions from devices that are not physically connected to TPF/GI.

The ability to test (trace) transactions from remote devices, networks, etc. was previously unavailable with CMSTPF, as such installations had to carry forward trace facilities on their native TPF system. With the implementation of CTFS, installations do not have to carry forward trace facilities on their native TPF system. Test tools are provided with TPF/GI, these can be used for TPF application testing.

Testimonials View all

  • test-img

    CTFS - A great tool to allow access to communication links through a TPF/GI or CMSTPF session.

    IT Engineer,

    United States, Travelport .

  • test-img

    TPFGI - I quality test prior to release of production products for my team. We use CTFSS in conjuction with TPFGI to receive real time link traffic which gives us a very powerful desktop tool.

    Project Manager,

    United States, Travelport .