Return to
SNA Crossroad 8 Feb 1995
APPC allows user written programs to perform transactions in a Client-Server network. It has been available for many years, but has not been widely accepted. It should seriously be considered when communication with mainframe programs is required.
APPC is a technically attractive alternative that is often misunderstood and has developed a reputation as Politically Incorrect. The purpose of this document is not to advocate its use, but rather to clear up the misunderstandings.
IBM designed SNA (Systems Network Architecture) to support all types of commercial data communications. However, as IBM is careful to point out, an Architecture is not a product. DEC made DECNET available on its machines. Apple provided Appletalk. But IBM only implemented the subsets of SNA that seemed to be profitable.
SNA came out before the microprocessor revolution. Early SNA devices were fairly limited. SNA rules were designed to protect a dumb device. For example, printers receive but do not send data. Printers take some time to perform their task and are subject to paper jams and other delay. A 3270 display can both receive and send data. It's operation is instantaneous and it has nothing like a "paper jam" to slow it down. So IBM defined subsets of the SNA parameters and gave them nicknames. LU 1 and LU 3 reflect types of printers. LU 2 is the package of parameters for the 3270 display. The SNA rules protected dumb devices from being asked to perform operations they did not understand.
Today, all devices contain some kind of computer chip. Since the device is controlled by an internal computer, all communication with the device is actually a conversation between two computer programs. The IBM family of AS/400 minicomputers and their associated terminals and printers were the first IBM products to seriously exploit this development.
IBM always had a view of Program to Program communications. In the early days of SNA, it was not very important. Over time it was refined as "LU type 6" and after several revisions became commonly known as LU 6.2. Originally it had been viewed as a method for CICS transaction programs to communicate with each other through a network. However, it became the native form of communication between AS/400 computers and their associated devices.
The future of SNA is now centered on LU 6.2. There are millions of 3270 displays, and they will continue to be supported. However, new development will be based on a model of program to program transactions.
In common use, people often confuse terms that apply to different aspects of the same thing. For example, the 3270 display family includes SNA devices and also channel attached displays used as operator consoles. LU 2 is the package of SNA parameters adopted by 3270 terminals. HLLAPI is a programming interface used by programs that want to logon to the host and run transactions. In this same spirit:
There are two kinds of Server programs. For file I/O, printing, and database, it is common for the server program to be constantly running. New client requests are routed to the running program, are processed, and a reply is sent back. This is an efficient arrangement to process a large volume of very similar requests.
However, when the client may request any service from a large library of transaction programs, then it is easier to load a server program in response to a new request. On the IBM mainframe, this is the design of CICS. In UNIX, this type of service is performed by the "INET" monitor.
APPC can support both arrangements. A program can be loaded in advance and identify itself to the APPC subsystem. When a request arrives, it is placed on a queue to be processed by the program. Alternately, a new request can be processed by the Attach Manager. It starts the program needed to service the request. That program inherits the conversation with the client and can receive and send data.
The Attach Manager function implies a "job management" function. When the server program is started, it must be assigned accounting, priority, and data access privileges. In some cases, the server program runs with the userid and privileges supplied by the network client. Otherwise, it may run with system privileges or those of the programmer who wrote the program. The Attach Manager must duplicate some the functions of the subsystems that start new jobs or that logon remote terminal users.
In other forms of communication, a session is established between the client program and the server program. When the request is complete, the session is terminated. However, the process of setting up a session involves some work and delay. It is necessary to locate the server program name somewhere in the network. A route between the client and server must be found. The server node must be contacted to make sure that the target program is running or can be started. The client and server must negotiate basic rules for the session (what is the largest packet, how much data can be sent before waiting for a reply, should the server confirm each operation or simply report errors when they occur).
If this document is being displayed across the network using a PC World Wide Web browser, notice the status messages at the bottom of the screen as requests are made. After selecting a new document, there may be a substantial delay associated with operations to "Resolve name" or "Connect to Server." These are steps in the Internet session establishment. Internet protocols (Web, Gopher, FTP, WAIS) use the traditional model and establish a new session with the server for every request. The user can easily notice the delay.
APPC makes the assumption that most requests will go to a small pool of frequently used servers. In particular, corporate database requests will all go to the big mainframe computer. Instead of establishing a new session for every request, APPC communication is managed through a subsystem. The subsystem maintains a pool of long running sessions between the user machine and subsystems on the server machines. When a new request is generated, it will in most cases be sent through an existing session. There is some overhead as programs communicate to the subsystem, but it is much less than the cost of constantly creating and ending new sessions.
Since the term "session" is reserved for a long running connection between subsystems, the temporary exchange of data between the application programs is called a conversation. A conversation borrows the use of a session for some period of time. When the conversation ends, the session goes back into the pool.
A client generates a request. It is passed to the subsystem on the client node and is sent through the network to the subsystem on the server node. A subsystem component called the Attach Manager then either queues the request to a running program or starts a new server program.
Each request has a Transaction Program Name (TPNAME) field. The TPNAME is up to 64 characters long and does not have to be the file name of a program module. The Attach Manager looks the TPNAME up in a table and resolves it to a package of parameters (module, priority, access control userid and group, mode of execution). In this sense it is more like a mainframe PROC or a Windows PIF because it describes not just the program but also how it is supposed to run. The Attach Manger handles issues that are peculiar to the local operating system.
Transaction Programs can be written in most compiled languages. They can also be written in REXX. Simple transactions on AIX can be written as shell scripts.
The smallest APPC conversation consists of two operations:
Allocate
Deallocate
Allocate acquires temporary ownership of one of the sessions to the server node. Allocate is resolved in one of three ways:
Deallocate frees the session and ends the conversation. The smallest APPC client program executes an Allocate and a Deallocate. Such a transaction requests that a program be run on the server node, but it provides no data and doesn't wait for a response.
The term "conversation" implies interaction. In this particular case, however, there is no exchange. The effect of these two statements is to send a packet of data (called "Attach" data) from the client to the server. The client program may end before the packet arrives.
APPC has several programming interfaces, and the notation is somewhat vague. Stylistic differences may add additional housekeeping statements. For example, the CPIC subroutines would require a starting Initialize_Conversation operation, while other subroutine packages might have a Start_TP call.
IBM tends to bundle operations in convenient packages. This tends to simplify the usual case, but it makes any logical presentation of the interface more difficult. On some systems, the default behavior of the Deallocate statement is to wait until the server program runs and completes its operation. On such a system, it would be necessary to add an extra statement for Deallocate to complete immediately without waiting.
There is a loose mapping of Allocate into verbs like OPEN, CONNECT, and CALL, while Deallocate is similar to CLOSE, ENDFILE, or HANGUP. The problem with this analogy is that other programming interfaces operate immediately. The OPEN statement will fail if the file does not exist or if the user does not have access rights to the data. However, APPC statements are lazy and wait till the last possible moment to act. In the Allocate-Deallocate case, the Attach data is not sent from the client node until the Deallocate is processed, and the server program runs after the client program ends. If something goes wrong (because the server program cannot be found, or cannot be loaded, or if the client lacks permission to perform the operation) the failure will not, in this example, be reported back to anyone.
Most transactions, of course, involve an exchange of data. APPC programs use two statements to send and receive data:
Send_Data
Receive_and_Wait
The Send_Data operation moves a record of data from the application memory to buffers controlled by the subsystem. Generally, the subsystem will queue small records up. Data is transmitted on the network only when a subsystem buffer fills or when the application explicitly or implicitly flushes the queue. But it is not just data that is queue. The TPNAME and other Attach data are queued in the same way.
In normal use, the Attach data will not be sent and the server program will not be loaded until enough data has been sent to fill up the buffers. Should something go wrong (bad program name, inadequate authority), the failure will be reflected not in the return code from the Allocate statement, but later on in, say, the return code from the eleventh Send_Data request.
This will create a problem for programmers who try to treat Allocate, Send_Data, and Deallocate as though they were OPEN, WRITE, and CLOSE. Because APPC is lazy, the return code from any statement can reflect a problem with any previous statement. The logical solution is found in the definition of a "transaction."
In database, a transaction is a set of updates to several files that must all happen simultaneously. Should something go wrong, then the entire transaction must be backed out so that no changes were made. In APPC, a transaction is a set of operations that either succeed or fail together. Rather than thinking of individual records, design the APPC program to send an entire:
SQL query
script of commands to execute
dataset to archive
file to
print
Z39.50 request or reply
compound document
customer order for
widgets
memo to distribute
new specifications for the photon torpedo
launcher
fax image of the new advertising brochure
A user sends a request to print a file. After 500 successful Send_Data requests, a bad return code on the 501st request indicates that the request has been aborted. It may be that the spool filled up. It could be that the operator canceled the request while it was still being spooled. The request may have required an unsupported operation (perhaps 11x17 tabloid size paper). It might even be true that a PostScript error was detected in the file as it was being pre-scanned.
The client will certainly want to know what the problem was. However, there is no particular advantage in knowing precisely how many records were sent through the network. All of the data for this request has been discarded.
The traditional I/O interface (OPEN, READ,WRITE,CLOSE) was developed in the 1960's on machines much smaller than any modern computer. Some users may still remember the IBM and DEC editors that operated on small sections of a dataset, because the entire file could not be read into memory. Modern systems read a file into virtual memory. However, the COBOL or C view of file I/O was standardized in the days where programs operated record by record.
At any time the server can detect problems in the request or the data. There could be resource limitations, security restrictions, or the request could be improperly formed. There is no sense waiting for the client to send more data. The server logically interrupts the client by issuing the APPC verb:
Send_Error
Send_Error breaks the logical chain of incoming records. APPC is responsible for flushing any pending data (from the server node, the network, or the client node). As soon as possible, the client is notified of the problem with a characteristic return code on the next APPC operation.
Flushing the buffers discards an unknown amount of data. Within the spirit of "transactions," Send_Error aborts the transmission of some larger multi-record object (a file, a table, an image, etc.).
The lazy operation of APPC is more efficient when the server is a mainframe or when the client and server are separated by a wide area network (such as a corporate SNA backbone). However, at various points in the transaction it may be useful to pause, flush out any pending data, and force the other program to either accept or reject everything sent up to this point.
The verb to accomplish this is
Confirm
Any pending data is sent, and after the other program receives the data it gets an indication that Confirm is pending. If everything is acceptable, then the correct response is to call the Confirmed verb. Otherwise, call Send_Error.
The overall logic of an APPC program is difficult to understand because of the lazy execution and deferred return codes. The Send_Data operation on a record is a low-level component of a larger transaction. In the modern world of virtual memory and Object Oriented programming, there are probably better operations that could be defined:
Send file (disk to network)
Send SQL table (DBMS to network)
Send stack
(REXX)
Send hiperspace (MVS)
Send clipboard (Windows)
While such a higher level set of routines would not be tied to any specific application, they would be specific to a particular type of data, programming language, or operating system. They would have to be written by someone with a knowledge of the current APPC programming interface and the ability to handle those states and return codes correctly. However, a "Send_Object" is easier to understand because the entire operation generates one return code that represents the success or failure of the entire operation. Current lower level APPC operations like Send_Data have to use "states" and more complicated error handling in order to achieve the same logical effect.
There has been a lot of loose talk about dumping all the mainframes. As long as an organization holds to this dream, they are unlikely to give APPC serious consideration.
To pull them back to reality, suggest the parable of the PowerMac. Apple needed to deliver a working product with the least delay. It was not possible to convert the entire MacOS environment. So they tested to determine which components are most heavily used, and rewrote the most heavily used routines to use the native PowerPC instructions. The rest of the code runs in 68000 emulation. This is the 80-20% rule.
Any realistic planning for Information System evolution will determine that there are many programs that should continue to run on a mainframe. The challenge, then, is to make the mainframe a participant and player in the new Client-Server environment. APPC then becomes an efficient tool that can be used to achieve this objective.
It is unlikely, however, that any large body of new application code will be developed by users directly to any of the APPC programming interfaces. If that was going to happen, it would have already taken place. The current trend favors other styles of development. Microsoft proposes OLE 2 as implemented in then Office product suite. IBM and Apple propose OpenDoc, SOM, and CORBA tools for distributed object oriented development.
APPC is well suited to provide communications (the "transport layer") for any of these initiatives. However, the APPC programming interface, states, and return codes are not directly applicable. For it to be useful, IBM or some third party developers must write a middle layer that converts the operations on distributed compound documents, database tables, and other objects transparently into a set of APPC calls.
In the shorter term, APPC is a useful tool to achieve some efficient connectivity with CICS, MVS "batch" (through APPC/MVS), and AS/400s.
Further References:
Self-study courses from SRA (1-800-SRA-1277)
A CD-ROM from IBM
Additional PCLT material on OS/2 Communication Manager configuration available under license.
Copyright 1995 PCLT -- Introduction to APPC -- H. Gilbert