IUCV
| Company type | Framework |
|---|---|
| Industry | Computer software |
| Founded | 1980 |
| Headquarters | United States |
| Products | Data exchange framework for IBM VM systems |
Inter User Communication Vehicle (IUCV) is a data exchange framework within IBM VM systems, first introduced in VM/SP Release 1 in 1980.
IUCV allows the creation of direct communication links either between virtual machines or between a virtual machine and hypervisor services. It supports message-oriented interactions, laying groundwork for client/server communication models found in later distributed computing environments.
The CP component (the VM hypervisor) implements IUCV, overseeing session setup, message delivery, and flow regulation.
Setting up IUCV
Prior to utilizing IUCV, a virtual machine must designate a buffer area where CP can store status or pending data by issuing the DECLARE BUFFER command.
The IUCV connection
A communication session linking two endpoints is referred to as a PATH, which is identified locally by a unique Path ID. These paths are always connection-oriented; connectionless communication is not supported.
Path creation
To initiate a path, the requesting VM uses the CONNECT method, specifying the target endpoint—either another VM’s name or a CP system service (indicated by names beginning with '*'). The target endpoint, if configured for IUCV, receives notification and may respond with ACCEPT to establish the connection or SEVER to reject or terminate it.
After the path is successfully created, endpoints can exchange messages.
IUCV messaging
Messages have clearly defined start and end points; multiple messages queued on a path remain distinct from one another.
Sending messages is performed with SEND, receiving with RECEIVE, and replies are sent using REPLY when requested.
Managing flow
The limit for outstanding messages on a single path is determined during path setup, with an upper bound of 65,535. Attempts to send messages beyond this threshold result in an error condition.
Pausing and resuming
Data transmission can be momentarily halted by invoking the QUIESCE method. While paused, no messages are transferred until the virtual machine that initiated the pause calls RESUME to continue operations.
Notification polling
Virtual machines check for IUCV events via the TEST MESSAGE and TEST COMPLETION commands. If no notifications exist, the VM waits until new information arrives.
Deliberate path closure
When one endpoint issues the SEVER command, the path enters a severed state and the counterpart is informed. No new messages can be sent afterward; however, any remaining messages may still be retrieved. The path is fully dismantled once both sides issue SEVER.
Automatic path closure
A path will also close automatically if
- A virtual machine logs off
- A virtual machine undergoes reset
- A virtual machine ends IUCV activity through
RETRIEVE BUFFER
This automatic closure mimics explicit termination behavior from the perspective of the other endpoint.
The B2F0 instruction
IUCV functions are triggered via execution of the 'B2F0'x instruction, which requires running in virtual supervisor mode (such as guest supervisor). Failure to meet this condition causes an Operation Exception interrupt. CP interprets this instruction as an IUCV service request.
IPARML
IPARML (Iucv PARaMeter List) serves as a control structure that specifies the method being called along with its associated parameters. After the execution of the B2F0 instruction, the CP updates certain fields within this block to reflect the operation’s outcome.
Notifications
To alert a virtual machine about incoming messages or changes in status, CP issues an external interrupt with the code X'4000'. The details regarding this notification can be found at the location indicated by the DECLARE BUFFER directive.
CP Macros
CP offers an IUCV macro designed to produce code incorporating the B2F0 instruction while initializing IPARML parameters. This macro streamlines both method invocation and conflict detection processes.
CMS Macros
CMS provides its own set of macros, known as CMSIUCV, which facilitate IUCV application requests. These macros enable multiple applications within a single virtual machine to share IUCV capabilities efficiently.
Authorization
Control over access to IUCV functions is managed through CP Directory statements that specify permission levels for virtual machines.
A virtual machine may permit communications from all other machines by using IUCV ALLOW, or establish connections with any machine via IUCV ANY. Specific authorization for individual connections is granted through statements such as IUCV TARGETVM. By default, a user always has permission to connect to itself.
These CP-level directives enforce access control policies, while virtual machines themselves may implement additional restrictions by rejecting connection attempts as needed.
CP System services
CP system services act as IUCV endpoints, allowing virtual machines to perform hypervisor-related tasks asynchronously or gain access to particular hypervisor features without being full virtual machines.
Notable examples include:
- *MSG*: The Message System Service enables a virtual machine to receive console output through IUCV, including results from 'CP MESSAGE' commands or Console I/O operations. This capability supports VM subsystems such as PROP (The PRogrammable OPerator) and Fullscreen CMS.
- *SPL*: Provides asynchronous access to spool files. The Remote Spool Communication Subsystem (RSCS) is an application that utilizes this service.
GCS
The Group Control System (GCS) employs IUCV to administer shared memory segments among virtual machines. Its recovery process uses implicit path termination to ensure that locks held by virtual machines that have unexpectedly left the group are properly freed.
VM TCP/IP
VM TCP/IP, the TCP/IP protocol stack for VM environments, uses IUCV to allow virtual machines to execute socket operations or serve as network interfaces. It facilitates frame or datagram exchange between virtual machines and the TCP/IP stack. Linux implementations on S/390 and z/Architecture platforms utilize this mechanism to interact with the VM TCP/IP stack.
See also
- VMCF – Virtual Machine Communication Facility
- Channel-to-channel adapter