6. DATA SOURCES › 6.10 APPC/MVS Overview
6.10 APPC/MVS Overview
The APPC/MVS ASCH scheduled transaction program (TP) supports
cooperative processing across different platforms in the IBM
SNA network.
APPC CONCEPTS AND TERMINOLOGY
Advanced Program to Program Communication (APPC) uses the
LU6.2 protocol to allow programs to communicate over the
Systems Network Architecture (SNA). APPC/MVS extends the
support to the z/OS mainframe.
Programs that communicate using APPC services are called
transaction programs (TPs). A TP on one system uses APPC
communication calls to access a TP on another system to
perform some task. This communication is called a
conversation. The task is considered a single cooperative
application executing on different (or the same) systems.
From the z/OS perspective, the TP residing on the z/OS system
is considered the local TP, while the TP it is communicating
with is the partner TP. If both TPs reside on z/OS, the TP
initiating the conversation is considered local.
APPC/MVS is implemented primarily with two address spaces:
the APPC address space and the ASCH scheduler address space.
The APPC address space is a VTAM application that intercepts
and handles all requests for APPC services. When a request
is for a z/OS TP on the same system, it is considered an
inbound request. When a request is for a TP elsewhere in the
SNA network, it is considered an outbound request.
Inbound requests are passed to the APPC/MVS scheduler address
space (ASCH). The ASCH scheduler is responsible for a set of
full-function address spaces, called subordinate address
spaces, that use APPC initiators to initiate and execute TPs
on the z/OS system.
APPC/MVS is not just a transaction handler, like CICS or IMS.
The primary difference is that APPC/MVS ASCH-scheduled TPs
execute in independent, full-function address spaces, and
have access to all z/OS services. For example, an
APPC/MVS ASCH-scheduled TP can use hiperspaces and data
spaces. The cooperative processing model used with APPC/MVS
supports a true peer-to-peer relationship between partner
TPs.
Although TSO sessions, batch programs, started tasks, and
even ASCH scheduled TPs can allocate a conversation with a
z/OS ASCH-scheduled TP on the same system, the real power of
APPC/MVS is found in the ability of a program running on a PC
workstation to access the resources of the mainframe to
accomplish some task. This is the gap that IBM intends to
bridge with APPC/MVS: using the power of the mainframe to
access and process information, then sending the results back
to the presentation-rich workstation environment.
ENABLING APPC/MVS
Setting up the APPC/MVS environment is not a trivial task.
o One or more profile data sets must be established in the
z/OS environment with entries for each local APPC/MVS TP
that will be the target of an inbound allocation
request.
o Local TPs (for example, TSO session, batch job, started
task, ASCH-scheduled TP) can use symbolic names for the
partner TP with whom they want to establish a
conversation. A side information data set must be
established that the APPC address space uses to
translate these symbolic names to the true network ID
and TP name of the targeted TP.
o The APPCPMxx members of SYS1.PARMLIB must have all
local LUs defined and associated with TP profile data
sets and schedulers. The ASCH scheduler is the default,
but other schedulers may also be used. These other
schedulers might be used for inbound CICS or IMS
transactions and do not generate any of the SMF records
used by the CA MICS Batch and Operations Analyzer. This
discussion is limited to TPs scheduled by the APPC/MVS
ASCH scheduler.
o The local APPC/MVS LUs must be defined in
SYS1.VTAMLST and the logon mode names in SYS1.VTAMLIB.
o Session characteristics that override VTAM defaults
for local and partner LUs must be defined in the
APPCPMxx members of SYS1.PARMLIB.
o The valid APPC initiator classes must be defined in
the APPCPMxx members of SYS1.PARMLIB. All local TPs
must be assigned one of these classes in the profile
data sets.
o If RACF security is required, LUs and TPs must be
defined to the RACF system.
SCHEDULING METHODS
The TPs defined in the APPC/MVS profile data sets to be run
in the APPC initiators are scheduled by the ASCH scheduler.
They can be of two types: standard and multi-trans.
Standard TPs are the default. They are very similar to
one-step batch jobs. The APPC/MVS ASCH scheduler initializes
them for each inbound conversation request and terminates
them at conversation end. This method of scheduling assures
a clean environment for each instance of the TP execution.
But the resources required by the TP must be allocated and
deallocated every time the TP executes.
Multi-trans TPs offer some benefits over standard TPs because
they remain in execution in the subordinate address space
between allocation requests. Frequently requested TPs are
good candidates for multi-trans scheduling because they avoid
the repeated allocation and deallocation of the programs'
resources. The multi-trans TP is composed of two parts: the
shell portion and the TP portion. When ASCH first schedules
a multi-trans TP, the shell portion allocates the general
resources, then issues a GETTRANS to ASCH to obtain the
inbound conversation request. The TP portion takes over and
satisfies the conversation request. When the conversation
terminates, the TP can either issue another GETTRANS to
receive the next inbound request or issue a RETTRANS to
return to the shell environment if clean-up actions are
required between consecutive conversations.
Both standard and multi-trans TPs run in the ASCH-managed
address spaces are reported on by SMF. In fact, unlike the
batch, TSO, and started tasks, APPC/MVS ASCH-scheduled TPs
are supported with two types of SMF records. The SMF type 30
records provide an address space perspective of the TP
execution, while the SMF type 33 APPC/MVS TP Accounting
record provides a transaction oriented perspective of TP
execution.
Figures 6-3 and 6-4 show the SMF records produced for
standard and multi-trans TP executions. A standard scheduled
TP will produce the same SMF record set as a one-step batch
job, the SMF type 30 record subtypes 1-5. A single SMF type
33 record is produced at the end of the standard TP
execution.
A multi-trans scheduled TP, while producing exactly the same
SMF type 30 record set as a standard TP, will produce
multiple type 33 records. One type 33 record is produced for
each conversation request handled by the TP portion and one
type 33 record is produced for each period spent in the shell
portion.
CA MICS SUPPORT FOR APPC/MVS
CA MICS support for APPC/MVS ASCH scheduled TPs is provided
with two batch information area files. The APPC/MVS TP
Activity file (BAT_TP) is created from the SMF type 30
records produced for a TP execution. The APPC/MVS
Transaction file (BATATP) is produced from the SMF type 33
records. These files are discussed in detail in Sections
5.2.6 and 5.2.7. The BAT_TP file provides an address space
perspective of an ASCH-scheduled TP, while the BATATP file
provides a transaction-oriented perspective. For multi-trans
TPs in particular, the BATATP file provides the only means to
examine the many individual conversations held with different
partner TPs while the ASCH-scheduled multi-trans TP remained
in execution.
The following sections describe various aspects of APPC/MVS
TP analysis and management.
1 - APPC/MVS Transaction Events and Measured Intervals
2 - APPC/MVS Transaction Response Time
3 - APPC/MVS Transaction Accounting
