Glossary

Programmatic communication based on IBM's LU 6.2 architecture. APPC provides partner programs with a common set of rules for communication.

A set of subprograms, callable from inside applications, that carry out data communications tasks.

the programmatic implementation of functions and protocols in a basic conversation between transaction programs. (See mapped conversation verbs.)

A programmatic conversation in which the applications must be able to create and interpret GDS headers (see GDS header) for transmitting and receiving data.

A machine that allows multiple devices to send and receive data over the same communications link.

A device that controls network data traffic for the hosts in the network.

The conversation state from which a TP can reply to a confirmation request and enter Deallocate state.

The conversation state from which a TP can reply to a confirmation request and enter Send state.

The conversation state from which a TP can reply to a confirmation request and enter Receive state.

A request sent by a TP, asking its partner TP to confirm the receipt of data.

Information exchanged by TPs to control conversations. Examples are requests for conversation allocation and deallocation, confirmation requests, and error notifications

The conditions of programmatic conversations under which certain activities can occur. For example, if one side of a conversation is in the condition of Send state, it can send data, but it cannot receive data until it changes to the condition of Receive state.

A conversation established in such a way that confirmation requests and responses can be sent and received.

A conversation established in such a way that confirmation requests and responses cannot be sent or received.

The logical communication between two transaction programs.

An IBM application subsystem that provides file handling and data communications services for application programs.

The conversation state from which a TP can deallocate the mapped conversation locally.

An LU capable of conducting only one LU-LU session at a time. A dependent LU always functions as a secondary LU and cannot send a BIND to initiate an LU-LU session; to request a session, it must send an INIT_SELF to the host and wait for the host to send the BIND. See independent LU.

The ultimate destination of data in a communications network. An end user can be a human user, a peripheral device (like a printer or a terminal), or an application program.

A portion of an LU 6.2 data packet that contains information about the kind of data being sent or received.

The name of the LU 6.2 data stream. LU 6.2 data packets must include GDS headers (see GDS header).

An LU capable of conducting multiple, simultaneous (parallel) APPC sessions with another independent LU on a remote system. An independent LU can function as either a primary or secondary LU. See dependent LU.

A subprogram provided by Hewlett-Packard to perform common functions such as opening files, opening communications lines, performing subsystem-defined functions, or transmitting data over a communications line.

The TP running on the local processor.

The SNA entity through which application data is transmitted within an SNA network. Logical Units are the ports through which end users have access to the network (see end user).

An SNA LU type which defines the communication that can take place between two application programs on separate processors. LU 6.2 includes specifications for programmatic interfaces, document interchange, and data distribution.

A Logical Unit type, defined by SNA to perform a particular type of communication.

See session.

The programmatic implementation of functions and protocols in a mapped conversation between transaction programs. (See basic conversation verbs.)

A programmatic conversation in which the application is freed from handling the GDS headers required by LU 6.2 architecture.

the node type for a peripheral node or cluster controller. Node Type 2.0 is supported by LU 6.2 API on MPE V and MPE XL.

the node type for a peripheral node or cluster controller capable of peer-to-peer communication. Node Type 2.1 is supported by LU 6.2 API on MPE XL.

the node type for a subarea node with a communications controller.

the node type for a host node with an SSCP (System Services Control Point).

A node type defined by SNA to perform a particular type of communication. Some common SNA node types are defined as follows:

A conversation in which data is sent from only one TP.

A bit mask that must be passed in intrinsic calls in Transact on MPE V. The parameter mask tells the intrinsic which parameters are being passed and which are being omitted.

A device on the network.

An SNA term that refers to the software and hardware that controls the resources of a node.

See Node Type 2.0.

See Node Type 2.1.

See Physical Unit.

The conversation state from which a TP can receive information from the remote TP.

The TP running on the remote processor.

The conversation state from which a TP can allocate a mapped conversation.

The conversation state from which a TP can send data or request confirmation.

The logical connection between two logical devices in an SNA network.

A term that refers to the amount of synchronization information (confirmation requests and responses) that can be sent in a conversation.

IBM's comprehensive specification for data communications networks.

An application program that processes distributed transactions.

A conversation in which data is sent and received by both TPs.

User-Defined Command. An MPE feature that allows a user to create file of commands to be executed as a single program when the user types a command. UDCs are set with the MPE SETCATALOG command

The programmatic implementation of functions and protocols in a conversation between transaction programs.