Guardian Application Conversion Guide

Conversion Strategy
Introduction
096047 Tandem Computers Incorporated 1–5
Converting Single-Process
Applications
Interprocess communication and process management might need a moderate to large
amount of conversion effort. Single-process applications need the least effort to
convert because they communicate with few, if any, other processes. They also do not
keep track of what processes open them. They do not create other processes because if
they did, they would not be single-process applications.
Word processors and calculators are typical examples of single-process applications.
They are also applications that are executed by a large number of users. Since each
execution of these processes requires a separate PIN a lot of low PINs can be freed by
converting such processes to run at high PINs.
Converting Multiple-
Process Applications
The amount of effort needed to convert multiple-process applications ranges from
small to extensive. As the amount of interprocess communication and management
increases, so does the conversion effort needed. The following list of applications that
contain multiple processes appears in order of the amount of effort, from low to high,
it would take to convert these applications:
COBOL85 program with no ENTER TAL statements
Most requester processes
Server processes that do not track processes that open them
Server processes that care about their creator’s identity
Server processes that do track processes that open them
Monitor process pairs that create and track other processes
The following paragraphs outline the conversion effort required for each of these
application types.
COBOL85 Program With No ENTER TAL Statements
If a COBOL85 program contains no ENTER TAL statements, you do not have to
convert C-series procedure calls to D-series procedure calls. You do need to use the
Common Run-Time Environment (CRE), however, to run a COBOL85 program at a
high PIN.
Most Requester Processes
A requester process opens a server, makes a request, and gets a reply. If the server is
named, then the requester does not have to understand the server’s CPU and PIN; the
system takes care of the interprocess communication.
If the server is not named, some changes are necessary. It is probably easier to run the
server named than to change the requester.
Server Processes That Do Not Track Processes That Open Them
A server process that does not read system messages from its $RECEIVE file probably
does not need to process the CPU and PIN of the requester, because it does not keep a
table of processes that open it.