Client-based Application Integration

PASSPORT APIs Provide Client-Based Legacy Integration

Host Application Integration Using Screen Information is Low Cost and Low Risk

With its low cost and low risk approach to host application integration, client-based TN3270, TN5250, VT100, VT220, VT420, SCO ANSI or Wyse 60 terminal emulation for Microsoft Windows can be an ideal platform to integrate valuable processes found in legacy applications. For this reason, the Zephyr line of PASSPORT terminal emulation products offers up to APIs to assist developers with options for client-based host integration.

Zephyr offers the PASSPORT Object toolkit to ease programmatic application integration efforts. The toolkit is available free of charge to customers who license at least 500 units of PASSPORT via an annual subscription license.

Desktop Based Host Integration APIs

• HLLAPI Interface
• Object Interface
• Macro Interface

Using the host application screen display as an API, developers can quickly navigate through TN3270, TN5250, VT100/VT220/VT420 and SCO ANSI applications to locate specific screens, fields and text, and cut and paste data to and from the host session.

The APIs listed above can be used with either PASSPORT PC TO HOST® or PASSPORT WEB TO HOST®. PASSPORT PC TO HOST® is a desktop based terminal emulation product, whereas PASSPORT WEB TO HOST® is a server deployed web-based terminal emulation product.

Sample Integration Projects

• Microsoft Access macros can be written to update information in a host application using data from an Access database with PASSPORT terminal emulation for host access

• A PowerBuilder HLLAPI application originally written for the NetManage Rumba desktop based terminal emulator can be ported to the PASSPORT WEB TO HOST® web-based terminal emulation program

• Complex Attachmate EXTRA!® macros and applications written specifically for Attachmate EXTRA!® can be easily ported for use with PASSPORT terminal emulation

• A corporate desktop-based application that integrates multiple applications can embed and interface a complete terminal emulation program

HLLAPI Interface

The HLLAPI (High Level Language Application Programming Interface) Interface was originally developed by IBM in the mid 1980's and first used with the MS DOS-based IBM PC 3270 Emulation Program. It has evolved over two decades to become the most widely used API to link thousands of desktop-based applications to IBM mainframe applications.

A library file (.LIB) is provided that may be linked into an application in order to use the HLLAPI interface. Only C++ applications need an explicit link to the .LIB file. HLLAPI is not an ActiveX COM object and isn't object oriented. HLLAPI provides a single function that has four parameters. The first parameter indicates which HLLAPI function to perform. PASSPORT uses either hllapi() or winhllapi () as the function name entry point.

The IBM HLLAPI DLL name is PCSHLL.DLL whereas PASSPORT uses the PASSHLL.DLL file name. When migrating an HLLAPI application to PASSPORT it's important to check:

1. The name of the HLLAPI DLL being loaded is correct (normally needs to be changed)
2. The HHLAPI application can find the HLLAPI DLL by adding the PASSPORT installation directory to the PATH environment variable
3. The HLLAPI function entry point is correct, either hllapi() or winhllapi () or something else (normally does not need to be changed).

The HLLAPI short name, which ranges from the letter 'A' to the letter 'Z', is used to identify which host session is being used.

When to Use: The HLLAPI Interface is recommended when PASSPORT is being used to replace an existing terminal emulator and an existing PC HLLAPI application. Also, third party applications may require HLLAPI for host access.

Object Interface

The PASSPORT Object Interface was originally added to PASSPORT to provide the ability to convert Attachmate EXTRA!® macros to PASSPORT macros. It can also be used to run PC applications designed using the Attachmate EXTRA!® Objects. The Object Toolit is available free of charge to customers who license at least 500 units of PASSPORT via an annual subscription license.

This interface is an ActiveX COM object called PASSOBJ.DLL. There is an hierarchy of objects used for host access which includes Sessions, Session, Screen, OIA, Area, Toolbars, Toolbar, QuickPads and QuickPad. The COM object can be used with any programming language that can use ActiveX COM objects, including C++, Visual Basic, VB Script and Java Script. The PASSPORT Object Toolkit provides a sample VB Script application and source code.

When migrating an existing Attachmate EXTRA!® application to PASSPORT, the only change necessary is to change the name of the object used in the CreateObject () method. An Attachmate EXTRA!® application uses CreateObject ("EXTRA.SYSTEM"). For PASSPORT you would use CreateObject ("PASSPORT.SYSTEM"). The Area object can be used to select parts of the host screen, and the copy and paste methods can be used to copy data from one host session to another. The Object Interface does not have any event driven functions.

When to Use: The Object Interface is recommended in order to run existing Attachmate OLE automation applications, complex Attachmate EXTRA!® macros that have been converted to PASSPORT, or new host access applications that require an object-oriented interface.

Macro Interface

The Zephyr Macro Interface, originally designed for MS DOS and later transitioned to a 32-bit platform, is used whenever a PASSPORT macro is run. The Zephyr PASSPORT macro scripting language uses the VBSCRIPT.DLL provided by Microsoft®.

The PASSPORT PASSMAC.DLL provides the interface used for host access and is an ActiveX COM object. It is one single object and all methods and properties are accessed from this one object. The macro interface can be used by any application that can use an ActiveX COM object, including C++, VB, VB Script, Java Script., etc. Documentation and sample source code are provided with PASSPORT in the on-line Technical Reference. The macro interface contains special event methods that can be used to tell when host screens are received or when keystrokes have been initiated by the end-user.

When to Use: The Macro Interface is recommended when a lightweight screen scraping API is needed to access a single host session with simple event functions.