Benefits of APPC/MVS for Application Programs

Many types of applications are good candidates for using APPC/MVS services. The most obvious candidates are applications that need to link MVS functions or data with processing done on other computers in an SNA network. When an MVS program must communicate with a program on another system, APPC/MVS can provide a temporary connection, freeing you from having to make a permanent connection between the programs or create a special access method.

A prime example of a cooperative processing application involving APPC/MVS is one in which a transaction program on an z/OS server provides z/OS services and data to a user interface program on a workstation. For example, a database-accessing program on MVS could receive requests from a partner program on the workstation, access an MVS database, perform intensive computations, and send results back to the partner program. This cooperative application would combine the usability of the workstation, with its end-user interface features such as graphics and windows, with the processing power and resources of the z/OS server.

The APPC/MVS part of an APPC cooperative application—an APPC/MVS transaction program (TP)—is any program in any address space on MVS that issues APPC/MVS or CPI Communications calls. The TP can run in task or SRB mode and can use other MVS services. A TP can also:

Be scheduled in response to inbound allocate requests
Initiate multiple, concurrent, and asynchronous APPC service requests
Use JES SYSOUT and Job Submit facilities (only inbound TPs using the APPC/MVS scheduler)
Use certain TSO/E programming services and TSO/E command facilities.

An APPC/MVS application can be a powerful adjunct to existing subsystems and environments such as TSO/E, IMS, CICS and DB2. An APPC/MVS application can create or access the following types of data:

New or existing VSAM, sequential or partitioned data sets can be created, read, or updated through dynamic allocation or the TP profile.
To update and extract CICS VSAM data, a conversation to a CICS transaction that uses CICS file control may be required. In some cases it may be possible to read CICS VSAM data using dynamic allocation, assuming a data disposition of SHR and the possibility of updates in progress.
IMS data may be accessed by a conversation request to an IMS application, through an IMS scheduler, to either extract or update DL/I data. Direct access is possible if the APPC application is coded to the rules for an IMS BMP.
DB2 data may be accessed directly through the call attach facilities provided by DB2.

APPC/MVS TPs may also participate in resource recovery by using the CPI Communications or MVS Commit or Backout services to synchronize changes with partner TPs.

In addition, APPC/MVS applications can use MVS facilities such as shared data spaces, hiperspaces or look-aside techniques to enhance performance and sharing of data across APPC/MVS transactions.

With this capacity for joining high-end data processing with end-user interfaces, APPC/MVS lends itself to compute-intensive and I/O- and data-intensive programs such as:

Planning and control programs
Knowledge-based processing
Collector applications (example: gathering regional sales data)
Distributor applications (example: price dissemination)
Exception/alert processing
Large sorts
Monitoring/report generation
Graphics
Decision support (spread-sheet) applications
Batch application scheduling
Extensions of current subsystem environments

In addition to making cross-system connections, APPC/MVS presents a consistent interface for communications within the same z/OS system. A local TP can use APPC/MVS to hold a conversation with a partner TP that is under APPC/MVS control on the same system. The two TPs can be either:

Defined to the same VTAM logical unit (LU=OWN)
Defined to different VTAM logical units that are on the same z/OS system (LU=LOCAL).

A good analogy for this type of intra-MVS communication is a hotel telephone network; when a guest wants to call another guest in the same hotel, the hotel switchboard puts the call through to that room directly, and they have a conversation without using the public phone system at all.

Before designing a new application or adapting an existing one to take advantage of APPC/MVS, it is important to understand how the parts of the application communicate; what the partners can exchange in a conversation, and how they do it.