Power
PathPort FAQSPower
PathPort FAQS
Conversion of existing Pathway applications to client/server architecture simultaneously yields both significantly improved user response time and a large reduction in host CPU requirements.
These two benefits are a direct result of the fact that both terminal I/O as well as the need to run a Pathway TCP are entirely eliminated.
Because PathPort creates workstation based requesters (clients) that communicate Pathway transactions to the host based servers via the network.
In other words, the actual data sent and received between the client machines and the host is the same as what the Pathway TCP sends to the Pathway servers. Pathway servers never require modification to be used with PathPort workstations.
A Pathway TCP is simply no longer required.
The Screen COBOL compiler does not generate machine code; instead it generates pseudo-code (P-CODE) which the Pathway TCP interprets repeatedly as it executes a SCOBOL program.
The PathPort generated clients are actual machine code executing on personal computers instead of on the centralized host system. Host CPU cycles need not be consumed performing the less efficient P-CODE interpretation; the cycles that are consumed are on more cost efficient personal computers.
In the legacy Pathway environment, the Pathway TCP communicates with terminals (usually Tandem 6530 terminals) using terminal protocol and in terminal format. This implies several things.
First, the 6530 terminal protocol is an ACK/NAK protocol requiring that data streams be broken into blocks, each of which must be acknowledged before the next block can be sent. As a result, a single data stream (such as a Pathway screen) may require many I/O's to effect proper delivery.
Secondly, the data stream itself must be constructed from Pathway internal format (in the case of an outgoing screen) or into Pathway internal format (in the case of an incoming terminal screen). The data stream conversion takes place on each and every I/O to and from each and every terminal.
Finally, Pathway screens are downloaded to terminals repeatedly as needed to service user requests.
In the PathPort environment, all I/O done with the client workstation is performed on a transaction basis (i.e., the format of the transaction destined for the Pathway server or the format of a Pathway server response). The host CPU time associated with handling terminal protocol, reformatting between terminal and internal format, and downloading screens is entirely eliminated.
Our testing has shown that the elimination of terminal I/O and the Pathway TCP yields between an eight-fold and a ten-fold improvement in user response time.
It looks like an improved (i.e., a "GUI'ized") version of the original Pathway screen, but it still retains a good deal of its original page mode terminal flavor.
Remember, PathPort provides an automated conversion process. By definition, it is simply impossible to provide a customized GUI using an automated conversion tool.
However, we have recognized that customers desire to not only achieve the benefits associated with client/server architecture, but they also want to migrate their application environments from legacy terminal format to modern GUI technology. It precisely for this reason that we interfaced this product with PowerBuilder which allows customers to rapidly customize the GUI.
No. The default screen presentation generated by PathPort is more than sufficient initially.
Customers may subsequently enhance the GUI presentation to their application using PowerBuilder. To what extent the GUI is enhanced is entirely up to the customer and may be done at whatever pace is comfortable for their environment.
In fact, it may be desirable to initially implement using the default screen presentation as it minimizes disruption to and retraining of existing users in the short run. A GUI enhanced version of the application may be subsequently deployed when convenient.
Because it is clearly the leading development tool allowing rapid construction of a customized GUI. It supports the ability to import the legacy Pathway screen presentation (as generated by the PathPort cross compiler) and to easily customize it.
Simply because there was no need to "reinvent the wheel" and also because many customers have already adopted PowerBuilder in their environment, eliminating the need to learn another product.
This certainly is an option, but clearly a less attractive one. There is simply no need to reimplement what already exists.
Additionally, reimplementation carries the risk that it may not be entirely correct in terms of server communication which in turn may cause unpredictable problems.
Finally, the expense associated with complete reimplementation typically far outweighs the cost associated with using the PathPort approach.
The PathPort solution has been designed from its inception to protect the customer's existing investment in both software and hardware.
This of course depends upon the size of your applications as measured by the number of SCOBOL programs. Small applications can be ported in less than a day while larger applications would require more time.
Even conceiving of a very large application requiring weeks to port, this time frame compares quite favorably with the alternative solution requiring rewriting workstation based requesters, frequently involving time frames measured at best in many man-months or usually in man-years.
The primary reason why the SCOBOL compiler approach was discarded was that it would simply continue to propagate the proprietary and nonstandard Screen COBOL programming language.
While SCOBOL may have been acceptable in the technology climate of the 1970's when it was originally devised, the intense demand for standards based solutions in the 1990's argues strongly against such an approach.
ANSI C++ is a standards compliant programming language which is well known, generally accepted, highly portable, and widely implemented.
We considered pseudo-code (P-CODE) interpretation to be the least desirable solution for PathPort.
First, it continues to propagate the proprietary and nonstandard SCOBOL programming language as discussed above.
Secondly, it would leave the product vulnerable to any internal changes to the P-CODE that may be implemented in the future.
Thirdly, it forever confines the customer to whatever functionality that the Screen COBOL requester supports. The workstation based client can never be extended to accomplish additional functions (for example, adding code to access a file server).
Finally, such an implementation would involve reverse engineering the P-CODE itself, which is difficult, error prone, and of questionable legality.
The product has been tested with both Microsoft Visual C++ as well as Borland C++ compilers.
No. Most applications can be speedily ported to client/server without any C++ programming work of any kind.
Requesters which utilize user conversion routines will require that those routines be recoded. This of course is a significantly smaller task than reimplementing all requesters for an application.
Should you not be in a position to undertake the recoding of user conversion routines within your organization, Failsafe can perform this task for you.
In spite of the Windows interface, you are still using old 6530 terminal technology through Pathway TCP's.
Although this Windows based product is prettier than an actual terminal, it provides none of the advantages of client/server and it accomplishes no host system off-loading simply because a terminal emulator does not use the client/server architecture.
Since the PathPort solution implements true client/server, it off-loads the host system, significantly improves response time for users, and provides a sophisticated and customizable GUI that is far more comprehensive than that which can be offered by a terminal emulator.
This approach is commonly referred to as "wallpapering". As the term implies, all that is accomplished by this approach is to hide the old terminal based technology, and nothing more.
PathPort accomplishes significantly more than simply putting a pretty face on your application, including host system off-loading, greatly improved response time and true client/server architecture.
No. Both users on terminals as well as PathPort users on PC's and workstations may simultaneously access the same applications. Note that since PathPort requires no changes to the application server programs, the host based application software remains the same.
Of course, Pathway TCP's and SCOBOL requesters must continue to be used for the terminal user population. User's employing the "PathPort'ed" application on PC's or workstations would not require Pathway TCP's at all.
Note that you are positioned to migrate users from the old style terminal technology to the modern PathPort solution over time and at the pace that is correct for your company.
On the contrary, the PathPort approach is the only way to avoid dual source codes.
In this situation, we recommend that the SCOBOL programs be considered the primary point of reference. When a SCOBOL module is changed, all that needs to be done is to port that individual module again.
The new workstation requester (i.e., the PathPort requester with the modified module) would be used with the workstations, while the modified SCOBOL module would be used with the terminals.
Note the significant advantage that is offered with this approach when compared to the "throw it away and recode the requester" alternative to PathPort. Using that alternative, you would in fact be forced to maintain two versions of the requester.
The workstation based client requester needs to make Guardian procedure calls just like the Pathway TCP based requester invokes procedures such as the TMF procedures or SERVER_CLASS_SEND.
Conceptually, a remote procedure call mechanism is employed allowing Guardian procedures to be invoked over the network. In other words, remote procedure call technology makes calling procedures on another machine as easy as calling them from the same machine.
This is provided as part of the standard PathPort run time library.
From its very inception, PathPort has been designed to include RSC as an alternative method of making host procedure calls. This version of PathPort is intended to accommodate customers for whom standards compliance is unimportant and who are willing to accept proprietary and nonstandard solutions.
It is important to note that for this RSC version, some of the products goals of standards compliance, cross platform portability, and "future proofing" may be compromised due to the lack of standards compliance.
We have also adopted the Open Systems Standard ONC RPC/XDR mechanism as the RPC method of choice.
This is primarily due to the fact that ONC RPC/XDR is both technically and commercially mature, widely implemented, and a formal standard.
From its very inception, a number of goals were established for the product which were considered to be of paramount importance. Among these goals were the ability to accommodate cross platform portability for client machines as well as the ability to adapt to future changes in technology ("future proofing").
Products that do not comply with open systems standards are very vulnerable to problems associated with technology changes, portability, and interoperability with different types of systems. These types of problems would seriously compromise any client/server project. As a result, PathPort has been designed and implemented to be 100% standards compliant.
PathPort is standards compliant with respect to the programming language, windowing systems, remote procedure call technology, and networking technology.
PathPort employs the TCP/IP protocols in conjunction with the ONC RPC/XDR remote procedure call mechanism.
Additionally, the RSC version of PathPort may be employed with any of the protocols which are supported by RSC. These include asynchronous connections, NETBIOS, X.25 and TCP/IP.
You must be careful to look closely at the technologies being employed in each product.
While PathPort is entirely standards compliant, other solutions actually employ proprietary and nonstandard techniques or propagate obsolete technologies, or both.
The danger of proprietary technologies is of course that they lock users into using specific vendors products. The whole point of the industry movement to standards compliance is to permit users to avoid this trap and to choose products as desired.
A downloadable demonstration is available which is designed to show how easily legacy Pathway applications can be ported to client/server as well as how rapidly the GUI may be customized.
You might also be interested in our prototyping program under which customer applications are converted to client/server by Failsafe.
A restricted on site demonstration of the product is also available.