Environments Supported
Processing Descriptions
7. SNA CCS intercepts the I/O request and performs logical screen management.
A Work Element Block is built to inform VM/VCNA of the action to be initi­
ated on the screen and to hold the output line.
8. SNA CCS uses the IUCV SEND, RECEIVE, and REPLY protocols to com­
municate the work transaction to VM/VCNA.
9. The IUCV request from SNA CCS to VM/VCNA in the VTAM Service
Machine is intercepted by the External Interrupt Services (EIS) in the guest SCP (OS/VS1 with Basic Programming Extensions, or DOS/VSE with the lat­
est release of VSE/ AF). 10. EIS notifies VM/VCNA of the incoming message.
11. VM/VCNA receives the Work Element Block, interprets the orders, and per­
forms the physical screen management for the SNA terminal.
12. VM/VCNA causes VTAM to perform the I/O and the output once again goes
through its normal path of VTAM, the SCP, CP, and the NCP to get to the SNA user terminal. SNA CCS and the VM/VTAM Communications Network Application
(VM/VCNA) handle three 'environments' for the purposes of screen management:
console mode, CMS mode, and full screen support mode. These environments rep­
resent the interfaces that CP supports for console services to a virtual user terminal
and a guest virtual machine (G VM).
1. Console mode is communications between a display operator and either CP or
an operating system in a virtual machine (CMS or another operating system).
In this mode, the screen is divided into three areas, (input, output, and status),
and data to the output area is always directed to the next available line. Con­
sole mode I/O is generated when a guest virtual machine issues an SIO to the
3215 user console or CP generates console I/O requests internally in response
to CP commands.
2. CMS mode is DIAGNOSE X'58', CCW op code X'19' transactions. In this
mode, the CMS editor or an application program directs output to specific lines
on the screen. As with console mode, the screen is divided into three areas
(input, output, and status).
3. Full screen support mode (FSSM) is the environment where the display screen
is under control of a full screen application program. In this mode, the format
of the screen is under application program control and the application program
provides all 3270 orders. The interface to CP from a guest virtual machine is DIAGNOSE X'58', CCW op code X'29' or X'2A', for a full screen write or
read.
The following sections describe SNA CCS processing. SNA Virtual Console Communication Services 179

Screen Management
Communication Interfaces
In non-SNA processing, DMKGRF handles the console support for local 327X and 3066 devices. DMKRGA and DMKRGB contain the support for remote devices.
These modules perform both the logical and physical screen management needed
for the graphic display and printer keyboard terminals.
In SNA processing, in order to support a virtual console for a VT AM service
machine terminal user, virtual console support has been divided between the
VM/VTAM Communications Network Application (VM/VCNA) and SNA Con­
sole Communications Services (SNA CCS) SNA CCS handles this SNA environment for CP via modules DMKVCP, DMKVCR, DMKVCT, DMKVCV, and DMKVCX. VM/VCNA handles the
physical, device-dependent characteristics of the screen, setting up the I/O, and
maintaining the current state of the screen. VM/VCNA uses VTAM to perform
the I/O. SNA CCS handles the logical control of the screen, directs the
VM/VCNA actions, and serves as the interface between the VT AM machine and
the existing CP console function support. SNA CCS and VM/VCNA communi­
cate via IUCV. Modules DMKVCP, DMKVCR, DMKVCT, DMKVCV, and DMKVCX perform
the logical functions for CP that are described above. As with non-SNA
processing, DMKGRF processes the local 327X/3066 devices, and DMKRGA and
DMKRGB support the remote devices.
Note that the logical units supported by VM/VCNA are independent of CP; they
cannot be mapped to any real device defined to CP (that is, they are not defined in
the RDEVICE macro). SNA CCS provides the necessary interface to make the SNA terminal appear to be a real CP device.
To communicate, VM/VCNA and SNA CCS pass a work element block
(WEBLOK) between themselves. The WEBLOK contains the transaction orders
for the other component (SNA CCS or VM/VCNA), the environment, and the
data for the CP system or the user's terminal. See the section "Work Element Block" that follows or see VM/SP Data Areas and Control Block Logic, Volume 1
for a detailed description of the WEBLOK. SNA CCS and VM/VCNA communicate via the Inter-User Communication Vehi­
cle (IUCV). Figure 26 on page 181 illustrates the interfaces used in SNA process­
ing. DMKQCN presents requests from CP, CMS or, a guest virtual machine for
terminal writes to SNA CCS via CONT ASKS. DMKQCO presents requests from CP, CMS or, a guest virtual machine for terminal reads to SNA CCS via CONTASKS. SNA CCS passes input from the SNA terminal to CP and the virtual
machines via DMKCFM and DMKVCN. This is the same way DMKGRF handles
local terminal support.
In SNA processing, CP handles terminal input and interfaces normally with one
exception: CP must use logical unit names, instead of real addresses, to reference SNA terminals. 180 VM/SP System Programmer's Guide