Using APPC: Winning Back Control of Distributed Data Bases
By John Markworth

In the past, managing information on the computer was
straightforward. The data resided on a mainframe computer and was
accessed by only a few people whose terminals were directly wired
to it.
As corporations grew, they began operating with varying computer
systems in different divisions, spread out in several cities. Also,
individual divisions began purchasing independent computer systems
to fulfill specific software needs.
Corporate MIS directors were faced with the problem of managing
large distributed data bases containing redundant data. The two
common solutions were:
Communications Solution: using Remote Job Entry (RJE) to transfer
a file from one site to another. When this was a batch of
transactions, paperwork usually followed behind for use in
correcting errors.
Tape Solution: This involved downloading a file to tape, then
sending the tape to another site. This was a more time consuming
solution, since mail delays could occur.
These solutions worked, but each had its limitations. These
limitations created data processing problems everyone had to
contend with. Because data was processed and transferred between
systems in batches during transmitting, a systemūs response time
for the tasks was slowed down. This was because of the amount of
resources needed to handle such large amounts of data transmitted
over telephone lines.
Also, the same data was often stored in more than one data base.
This redundancy created the time consuming task of trying to keep
all data bases current and accurate. Finally, real-time access of
data was virtually impossible. The user was always looking at a
snapshot rather than up-to-the-minute data.
True to the nature of the American entrepreneur, someone perceived
the need for something better and created the product to meet that
need. In this case, the product is a protocol, or set of rules,
called Advanced Program to Program Communications (APPC). APPC was
introduced by IBM in the early 1980s as a technology that can bring
significant improvements and cost efficiencies to companies that
have multiple computer systems and distributed data bases. APPC is
underutilized as a tool to help solve the many problems of running
a large distributed network, because it is not yet widely
understood by the data processing community.
APPC is a tool that the transmitting machine uses to activate a
program on the receiving machine. Typical functions activated are
data lookups, retrievals and transfers. Under the rules of APPC,
the receiving machine reads the required data base and sends back
only the information requested by the transmitting machine. In
short, anything that can be done with a subroutine can be done on
another machine with an APPC call.
Thus, APPC allows the user to request and receive just the
information thatūs needed by the particular application. To the
user, the communication between the two machines is transparent.
The user may not even be aware that the requested data was in a
remote data base. Since the communication is between two
interactive programs, the data request may be as complex as
required, allowing any type of inquiry to be undertaken.
APPC opens new horizons for a program on one computer system to
communicate with a program on another computer system. The two
computer systems can be different machines (i.e., IBM, DEC,
Hewlett-Packard, etc.) or like machines, such as AS/400 to AS/400.
Each of the two programs can be written in any language: COBOL,
FORTRAN, RPG, C or other languages.
Examples of an APPC Application
Scenario: A multiplant operation with plants in several cities.
Each plant has its own midrange computer system that communicates
with the mainframe at corporate headquarters.
All primary financial information resides on the mainframe at
corporate headquarters. A plant accountant, however, needs access
to the corporate general ledger to look up account numbers.
Solution 1: Allow the plant accountant to sign-on to the corporate
mainframe (using an emulation package) from the plantūs midrange
computer, look up the general ledger number, jot it down on a note
pad and key it into the midrange application.
There are three disadvantages to this solution:
 The plant accountant must learn to access two very different
systems;
 Security issues may arise on the mainframe; and
 The information is not automatically transferred to the midrange
machine.
Solution 2: Download the chart of accounts from the mainframe to
the midrange as often as needed.
Disadvantages of this solution are:
 The file must be downloaded whenever a change is made on the
mainframe so that the file on the midrange is always accurate and
current;
 The number and size of files downloaded may require additional
phone lines, which is more costly; and
 The entire file must be downloaded, not just the information the
plant accountant needs.
Solution 3: Use APPC to communicate with the mainframe to look up
the desired account number. The APPC communications can occur from
within the program where the plant accountant needs the account
number. To the plant accountant, the communication is transparent
and occurs in real time.
The APPC interface could be written in two ways:
 The program on the midrange, using APPC, could initiate a program
on the mainframe that would check whether the account number
entered on the midrange was in the corporate chart of accounts. The
mainframe program, using APPC, could return a Yes or No response to
the program on the midrange.
 The program on the midrange could be written to use APPC to
retrieve and display, from the mainframe, a portion of the
corporate chart of accounts. The plant accountant could select an
account from the displayed list. Just that account could then be
returned to the program on the midrange. In this manner, the plant
accountant would not have to rekey the number.
This APPC solution can be applied to several different applications
that need to access data from a data base on another machine within
a multiple machine network. Although the previous example is an
interactive exchange of data, APPC can also be used to send data
from one machine to another in a batch environment. For example,
APPC can be used to send a batch of accounts payable invoices from
a plantūs accounts payable system to a check writing system at
corporate headquarters.
The situations may be different, but the underlying criteria remain
the same. To use APPC, the user must have a multiple machine
network; the machines may be the same or different manufacturers,
the languages used may be the same or different and one machine
must have the need to access data from another machine.
Advantages of APPC
As with any data processing system, there are advantages, as well
as disadvantages, to its application. However, the benefits of APPC
far outweigh the costs.
One of the most important advantages of APPC is security. Deciding
who has access to a data base and what type of access that should
be is a constant headache for MIS. By building an APPC interface,
you have a program on one machine requesting information from a
program on another machine. This rigidly controlled,
program-to-program access eliminates the need for people to sign-on
to another machine. You are guaranteed that people see only the
information they are supposed to see.
Another advantage is traffic control. An APPC application transmits
information rather than data. If you need only one account number
from the corporate chart of accounts, then only that account number
is transmitted. The entire chart- of-accounts file does not have to
be downloaded. As a critical resource, the phone lines are used
more efficiently, and, while some users may not be able to reduce
the number of lines they have, they may be able to postpone the
installation of new lines.
Associated with the transmission of information (rather than data)
is the ability to look at another machineūs data in virtually
real-time. This gives designers the ability to design software that
is efficient for the user, regardless of where the data resides.
User productivity can be improved in several application areas.
Consider the process of editing transactions that are sent to a
central host. Typically, a batch of transactions is entered with a
limited amount of editing and then transmitted to the central host.
(Editing is limited since the master files against which the data
is verified are on the host machine, not the entry machine.) The
host edits the transactions and, if errors are found, produces an
edit report. Someone must correct the errors and resubmit the
transaction file. This process may take two to three days before
the transactions are accepted as correct.
In an APPC environment, the edit program on the entry machine can
be designed to verify the data entered against the master files on
the host machine at the time the transactions are entered. The
entry person has the ability to correct the errors immediately.
When transmitted, the batch of transactions can be error free. Time
spent correcting errors and resubmitting files is greatly reduced.
Drawbacks To Using APPC
APPC has been presented here as a cure-all for distributed data
base management problems. It does have some drawbacks, and in all
fairness, they should be mentioned.
In return for its flexibility and increases in user productivity,
APPC does extract considerable programming effort. APPC is a
difficult product to learn. Once learned, however, the code is
fairly simplistic.
The steep learning curve is the result of programmers having to
master three new concepts in writing APPC oriented programs. First,
they must learn new APPC verbs and their functions (EVOKE, DETACH,
CONFIRM, etc.). Second, they must learn how to handle APPC errors
from a different machine. The machine they communicate with will
send back error codes that must be handled in the program. Finally,
they must understand the concept of designing a called subroutine
that opens its own files and must pass all the information back.
Since APPC requires intelligent programs on both ends of the
communication link, designers and programmers from the two systems
must communicate and cooperate. Particularly during the design and
testing phases of a project, these two groups of programmers must
work together to resolve problems.
Machines that communicate via APPC become reliant on each otherūs
data bases. If one of the machines is down, the other machine is
affected. The programs that use APPC to retrieve data will not
function. This necessitates good change control and good problem
analysis by the two operations staffs. If one machine will be down
for any reason, the other machines must be notified. If a microcode
change is going to be made to one machine, the other machines must
be notified. The machines are part of a dependent network and must
be thought of in that light.
Benefits of Using APPC
In contrast, APPC offers a broad range of benefits. It:
 allows design of software that maximizes usersū productivity
regardless of where the data resides.
 reduces errors by validating data entered against centralized
master files.
 prevents duplicate transmissions by time stamping data when it is
transmitted.
 reduces training time for entry functions since all data,
regardless of its source, can be accessed through the same entry
program.
 requires intelligent programs on both ends of the communications
link to request/transmit information.
 reduces programming changes related to redefinition of data
storage.
 handles the transfer of small to medium size files interactively
and returns a completion code at the time of transfer.
 accesses multiple systems, if necessary, to fulfill a request.
 saves time and money by eliminating the shuffling of paper
between locations.
APPC is the interactive communications product of the '90s. It
performs interactive communications to support interactive data
processing. APPC is one of the few products that allows you to
combine the power of two machines. If you have a multiple machine
network and widely distributed data, APPC can help you win back
control of your distributed data bases ū effectively and
efficiently.
/*
Was this article of value to you? If so, please let us know by
circling Reader Service No. 82.