Skip Headers

Oracle Application Server InterConnect Adapter for CICS Installation and User's Guide
10g (9.0.4)

Part Number B10410-01
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Go to previous page Go to next page

4
Systems Network Architecture Definitions

This chapter describes the terms commonly used when referring to systems network architecture. This chapter discusses the following topics:

LU 6.2 CPI-C Protocol Stack and URLs

At run-time, the CICS adapter interacts with the communication framework to pass along data over the CPI-C protocol stack.

The CPI-C protocol stack (CPI-C LU 6.2 SNA protocol API) defines the transport layer used to communicate data between CICS applications and the CICS adapter. Just as the meta-data describes how to format documents, the protocol stack defines the shipping mechanism.

URLs specify routing information when describing destinations within CICS. The URL contains CPI-C transport and protocol under the form of a protocol stack identifier, as well as transport specific server identification. The following is an example using the CPI-C LU 6.2 SNA protocol API:

lu62cpic://luname/tpname

where:

A default URL must be specified on the class definition. It must contain the protocol name (logical unit name) for the CPI-C LU 6.2 SNA protocol. If the tpname (lu62cpic) is not specified, then the method name is used.

For example:

class CICS_BasicTypes(lu62cpic://S9CICS) ascii littleendian
  Method testsigned8
   return void
   in signed8 inArg
   out signed8 outArg
  end method

Concepts and Terms

This section describes the following concepts:

ABEND

In OS/390, it is an abnormal termination of a program task (thread) or an address space (process). There are two types of abends: system and user. A system abend is done by the system because a system request (this is a supervisor call, usually done by a SVC) cannot be completed; therefore, the program that issued it cannot continue to work. Examples are unconditional requests for memory or problem accessing files. A user abend is an abend generated by the application program. This occurs when issuing a SVC number 13 instruction in the executable code. A system abend is prefixed by the letter S and followed by three hexadecimal digits, for example, S80A (missing memory). A User abend is prefixed by the letter U followed by four decimal digit, for example, abend U1001.


Note:

These abends can be trapped (caught) by user written programs.


In CICS, it is an abnormal termination of a transaction. When CICS has an OS/390 abend, the entire CICS region is not available. When a CICS transaction abends, only that transaction is terminated. A CICS abend code is usually made up of 4 characters, for example, abend ASRA. This abend is usually a program exception (for example, divides by zero, invalid addressing, non decimal data in a packed decimal field, and so forth). These types of errors are "trapped" by CICS and converted in a CICS abend ASRA. If, for example, the packed decimal error is not trapped, the whole CICS region abends with a OS/390 system abend code S0C7.

Advanced Program-to-Program Communication (APPC)

Advanced Program-to-Program Communication is the general facility characterizing the LU 6.2 architecture and its various implementations in products.

APPC is sometimes used to refer to the LU 6.2 architecture and its product implementations as a whole, or to a LU 6.2 product feature in particular, such as an APPC application program interface. In this document, APPC is referred to as the API, which allows a program to communicate with another program via a LU 6.2. This API is implemented as APPC verbs. Transaction programs can directly use these verbs to communicate with the LU 6.2 or they can use another layer of API, such as CICS. CPI-C is an example of a higher layer-programming interface.

CICS

CICS is a transaction-oriented system. Basically, a transaction is entered via a terminal or programmatically. The data entered contains a transaction ID, which enables CICS to recognize the program to be executed. CICS provides this data as input to the called program. Processing includes calls to databases, to other programs, or even to other systems. Next, a reply is built and the data is sent back via CICS. The receiving program reads the data and proceeds with it. If it is a terminal, control characters may have been embedded with the data to display the data correctly.

To communicate with other terminals, programs, or both, CICS can use a large number of protocols, including TCP/IP and systems network architecture protocols. In this case, LU 6.2 is a peer-to-peer protocol used to transmit messages between programs.

CICS Region

The CICS region refers to CICS and ESA only. In MVS (or OS/390), a variable-size subdivision of virtual storage that is allocated to a job step or system task. CICS/ESA runs in an MVS/ESA region, usually referred to as the CICS region.

A named collection of resources controlled by CICS as a unit. The collection includes programs, BMS map sets, transactions, terminals, files, transient data queues, temporary storage queues, journals, products, and users. One installation of CICS can run a number of regions on the one processor. Regions are likely to be application-specific, but one clear distinction is between a production region and a test region.

CICS Transaction

A CICS transaction is a unit of application data processing, consisting of one or more application programs, initiated by a single request, often from a terminal.

Conversation

In systems network architecture, conversation describes the communication between two transaction programs. That is, when two APPC transaction programs are in communication, they are said to be holding a conversation. Conversations flow on LU-LU sessions. Each conversation is allocated a session for its own private use. When the conversation ends, the session is free to be used by another conversation. There can only be one conversation between any two transaction programs, but one transaction program could have multiple conversations with different transaction programs. LU 6.2 transaction programs may select either two-way alternate (half-duplex) or two-way simultaneous (full-duplex) conversations, if both the local and remote logical units support full-duplex conversations. In a full-duplex conversation, each transaction programs can send data simultaneously. In half-duplex, the transaction program doing the allocation is in send state at the beginning and the other transaction program is in a receive state. There are 2 types of conversation:

In CICS, the communication commands you code in your application depend on whether you intend to use basic or mapped conversations. CICS-to-CICS applications need only use mapped conversations. Basic conversations (also referred to as unmapped) are useful only when communicating with systems that do not support mapped conversations. These include some APPC devices.

The two conversation types are similar. The main difference is in the way user data is formatted for transmission:

CPI Communications (CPI-C)

CPI Communications provides a cross-system-consistent and easy-to-use programming interface for applications that require program-to-program communication. From an application's perspective, CPI-C provides the function necessary to enable this communication. The conversational model is implemented in two major communications protocols: Advanced Program-to-Program Communication (APPC) and Open Systems Interconnection Distributed Transaction Processing (OSI TP). The APPC protocol is also referred to as logical unit type 6.2 (LU 6.2). CPI-C provides access to both APPC and OSI-TP.

Logical Unit

A logical unit represents the logical destination of a communication data flow. The formal definition of an logical unit is that it is the means by which an end user gains entry into a network, and an end user is defined as the ultimate source, or destination, of data flow in a network. Systems network architecture supports several different types of logical units. These are grouped together in numbered logical unit types, such as logical unit type 2 for 3270 display terminals, and logical unit type 4 for printers. The logical unit type for CICS-to-CICS communication is logical unit type 6.2, and is frequently referred to as advanced program-to-program communication (APPC). Each logical unit is given a unique name that identifies it in the network, and this is referred to as the logical unit name. There are two types of LU 6.2 pertinent to CICS adapter:

Mode Name

A mode name is the name used by the initiator of a session to designate the characteristics desired for the session, such as traffic pacing values, message-length limits, synchronization point and cryptography options, and the class of service within the transport network.

Node

A node is any device attached to a network that transmits and receives data.

An endpoint of a link or a junction common to two or more links in a network. Nodes can be processors, communication controllers, cluster controllers, or terminals, and can vary in routing and other functional capabilities.

Node Type

A designation of a node according to the protocols it supports or the role it plays in a network. Node type was originally denoted numerically (as 1, 2.0, 2.1, 4, and 5) but is now characterized more specifically by protocol type (APPN network node, LEN node, subarea node, and interchange node, for example) because type 2.1 nodes and type 5 nodes support multiple protocol types and roles.

Physical Unit (PU)

A Physical Unit (PU) is the hardware and software components in a device that manages its network resources. Logical units reside within a physical unit, and one physical unit may hold many logical units. There are several different types of physical units: Virtual Telecommunications Access Method (VTAM) running in a mainframe host is a physical unit type 5, and Network Program Control (NCP) running in a 37x5 network controller (physical unit type 4). When workstations connect together in a peer-to-peer manner they act as physical unit type 2.1. When a workstation connects to a mainframe host in a hierarchical manner, it acts as a physical unit type 2.0. The physical unit type 2.1 is described as an independent node (because it is independent of a mainframe host), and the physical unit type 2.0 is a dependent node.

Session

Systems network architecture uses the term session to refer to various types of data flow in a network. To avoid ambiguity, it should always be qualified by a description of the type of data flow, for example CP-CP session. However, when used by CICS for APPC, it can be assumed to refer to data flow between logical units, and therefore is a LU-LU session. There are usually several sessions between any two (independent) logical units, and these are known as parallel sessions. CICS uses the term connection to refer to a group of sessions that connect two CICS systems (or a CICS with the CICS adapter logical unit).

System Management Facility (SMF)

A System Management Facility (SMF) is a standard feature of OS/390 that collects and records a variety of system and job-related information.

Systems Network Architecture (SNA)

Systems Network Architecture (SNA), in the mainframe work, are commonly used to:

Systems Network Architecture (SNA) Controllers

In this document, the systems network architecture controller represents the type 2.1 node (or physical unit) when on the CICS adapter side as well as the type 5 node, when at the mainframe site. Examples of systems network architecture controller include:

Synchronization Levels

In synchronization levels, CICS defines three levels of synchronization for conversation using the APPC protocol:

APPC provides support for the three levels of synchronization by providing synchronization verbs and resynchronization services. Synchronization level 2 services is an option for many systems network architecture communication servers.

Synchronization Services

When a failure occurs, an application transaction program may be accessing multiple resources that may be local or remote, which causes synchronization services to happen. Local resources reside on the same node as the application transaction program. Remote resources may or may not be on the same node as the application transaction program. The function of logical unit synchronization point services is to ensure that selected local and distributed resources are in consistent states at defined synchronization points even if failures occur. Resources within such a set have consistent states if all the actions affecting them since the last synchronization point persist or if none persist. If all persist, the changes are said to be committed at all resources. If none persist, the changes are said to be backed out, for example, all the resources are returned to their states at the last synchronization point. Resources that are kept consistent by using the synchronization point protocols are called protected resources. Following a transaction program, session, logical unit, or other protected resource failures, that occur during synchronization point protocols, protected resources are returned to consistent states by the LU 6.2 partners using resynchronization (resynchronization) protocols.

Full support of synchronization point services in actual implementations includes provisions for synchronizing local resources as well as distributed resources accessed through conversations. An application transaction program may use synchronization point services when it is not using protected conversations. For completeness, this section describes general synchronization point services. Details of synchronization point services, including resynchronization services, for resources other than LU 6.2 conversations are not defined in this document.

A transaction program selects the synchronization point service for a conversation by specifying the SYNCPT value of the SYNC_LEVEL parameter on the ALLOCATE verb. With other values of the SYNC_LEVEL parameter (NONE and CONFIRM), maintaining resource consistency is up to the application transaction program.

If a transaction program has conversations using a synchronization level of SYNCPT, it may use the SYNCPT and BACKOUT verbs to establish synchronization points. The BACKOUT verb undoes all changes made to protected resources since the last synchronization point. The SYNCPT verb invokes two-phase commit protocols to commit changes to local and distributed resources. Two outcomes to the SYNCPT verb are possible:

Application transaction programs execute a sequence of logical units of work (LUWs), with each unit of work consisting of some changes to the resources under the control of the transaction programs. If a synchronization level other than SYNCPT is used, a transaction consists of one logical units of work. In this case, recovery from a failure can be done by undoing the work accomplished up to the point of the failure and running the transaction again from the beginning. By using synchronization point services, a transaction can consist of multiple logical units of work that are delimited by the start-up of a transaction program and by the execution of each SYNCPT or BACKOUT verb. At the beginning of each logical units of work, all resources are in consistent states. As a result, the amount of work required to recover from a failure can be limited using synchronization point services.

The following failures are addressed by synchronization point services:

Transaction Program (TP)

Transaction program (TP), in systems network architecture, the transaction program refers to the application program in an APPC environment. The transaction program uses the LU 6.2 (APPC) to gain access to the network.

CICS provides a choice of two application programming interfaces (APIs) for coding your DTP conversations on APPC sessions:

Verb Control Block (VCB)

Verb Control Block (VCB) is a structure passed to the APPC function. All the calls done to APPC require only one parameter: a pointer to a verb control block. The verb control block is different depending on the type of the call, but the first parameter is the operation code, telling APPC which APPC verb the CICS adapter wants to perform, and, at the same time, the format of this verb control block. There are two types of APPC verbs:

Verbs

APPC Verb is the mechanism by which a program accesses APPC. Each verb supplies parameters to APPC. There are three types of APPC verbs:

Other conversation verbs (mapped or basic) include:

Mapped and basic verbs have the same function in their respective types of conversation. For example, MC_CONFIRM performs the same function in a mapped conversation that CONFIRM performs in a basic conversation.

CICS as a Transaction Program

CICS can utilize the following APIs to issue APPC verbs:

When CICS is using its CICS command interface, the CICS adapter should use the APPC verb to communicate with the CICS transaction. It is not mandatory, the idea is to try to use interface (or API) that supports all the functions the other transaction program support.


Go to previous page Go to next page
Oracle
Copyright © 2002, 2003 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index