Cardinal Software

FAQ

	APX Return Codes

Contact

Who is Cardinal Software?

Cardinal Software is new owner of the APX product set currently in use at Fortune 500 companies in the U.S. and Canada. We are dedicated to support and enhance these products both on the traditional MVS platform as well as on several non-MVS platforms such as NT and Unix. Our goal is to help customers build robust, enterprise-wide distributed applications.

The original APX product set was designed in the late 1980s to enable constuction of high performance distributed systems with particular emphasis on real-time applications. The corporation founded to support development and sales of the products was Advanced Program Xchange Laboratories. After several years under the umbrella of APX Labs, the product rights were sold to Vmark Software (which became Ardent Software), and then finally sold by Ardent to Cardinal Software.

We will usually refer to the products as either the "APX" or "Cardinal" products because we think something like "CA-APX" is just silly.

What is APX?

APX refers to a set of middleware software products and application APIs that enable real-time synchronous inter-process communication. While Windows/NT and Unix are supported, the products also work extremely well in MVS/XA, ESA and OS/390. APX makes "hard to reach" legacy data easily accessible.

How does it work?

Interprocess communication can be accomplished several ways in OS/390. The APX architecture relies on standard cross memory and VTAM mechanisms to implement an extremely fast and scalable SEND/RECV API. XMS is used within an OS/390 image. A combination of XMS and VTAM are used when spanning images. Finally, when non-MVS platforms are involved, TCP/IP is also employed. Typical message lengths are 32K, but unlimited sized messages are possible.

What does APX do?

APX connects applications with each other by establishing synchronous, connectionless dialogs between them. The applications can reside in any MVS address space including IDMS, CICS (TS2-transaction server 2) (TS2-transaction server 2), IMS, and TSO. They can also be TCP/IP connected processes on Windows/NT or Unix. They can be written in any language. Any number of concurrent dialogs can be hosted by a given application. APX makes it easy to build bridges between new client/server applications and the most impenetrable legacy applications.

How do I use APX?

To use the APX API, you embed two simple calls (SEND and RECEIVE) into your applications. The first send in a dialog names a receiver. The send might even start the receiver. When the sender and receiver are recognized by the APX broker, rendezvous takes place and data is transferred.

How do I find out more?

Contact Tom Kinney or choose another form of communication from the contact page.

What are the APX return codes?

Return codes from APX Send and Recv calls are 3 characters long and can be found in the 2nd through 4th bytes of the 8-byte control field. The control field is the 4th parameter in a Send or Recv call. Of the 3 bytes in the return code, generally only the last one has application significance. Definitions can be found here.