Real Device Simulation
machine the user is logged onto. The system must tie these blocks together
since the logical unit's 'LUNAME', which is represented by the SNARBLOK, is unique only to its own VTAM service machine. That is, it
is possible to have duplicate lunames among two or more VT AM service
machines.
After the connection is established, VM/VCNA and SNA CCS exchange
initialization information. VM/VCNA sends luname, device class, device
type, line length, pace value (for controlling the number of writes to the
screen), model number, and its IUCV path ID for this logical unit and then
waits for LOGON processing to complete. SNA CCS initializes the SNARBLOK and RDEVBLOK with the data supplied by VM/VCNA.
If the user specified a userid and password on the ACF/VTAM LOGON, the VM/370 logo is not displayed. VM/VCNA sends the logon data to SNA CCS in response to the first CP read request to enter userid. If the
user specified only the userid, CP prompts the terminal user for the pass­
word.
AUTOMATIC LOGON The installation may specify "automatic" logon to VM/VCNA for SNA terminals. This can be accomplished in two ways:
1. The installation can specify LOGAPPL= (VCNA) in the logical unit
definition. This causes ACF /VT AM to queue a logon request to
VM/VCNA when the logical unit is activated.
2. The ACF/VTAM operator may issue a VARY ACTIVATE command
for the logical unit, specifying VCNA on the LOGON = parameter.
For further information concerning ACF /VT AM LOGON refer to the IBM
ACF/VTAM System Programmer's Guide.
When VM/VCNA connects to SNA CCS for a logical unit, VM/VCNA identifies
the SNA logical unit to SNA CCS. In addition, VM/VCNA identifies any device
characteristics that CP or CMS need to perform their functions. SNA CCS simu­
lates a real device by dynamically building a Real Device Block (RDEVBLOK) and
assigning this RDEVBLOK to the SNA user's virtual machine. SNA CCS initializes the fields for the RDEVBLOK instead of DMKRIO. In addi­
tion, SNA CCS builds a control block for SNA, a SNARBLOK. The SNARBLOK contains the status and control fields for SNA CCS. See VM / SP Data Areas and Control Block Logic, Volume 1 for a detailed description of the SNARBLOK. The RDEVBLOK is chained to the VSMBLOK belonging to the VSM that issued
the IUCV connect for it, and the RDEVBLOK points to the SNARBLOK for that LU. The RDEVBLOK and SNARBLOK are, however, contiguous in storage. CP
references to the RDEVBLOK are still valid in the SNA environment.
As in non-SNA processing, the VMTERM field qf the VMBLOK and the
VDEVREAL field of the VDEVBLOK point to the RDEVBLOK. SNA Virtual Console Communication Services 183

Command Handling
Work Element Block
Work Element Indicator Block SNA I/O Processing
Redisplay of Input Line
When special SNA processing is necessary, an indicator in the RDEVBLOK (RDEVSNA) denotes that this is a SNA type RDEVBLOK. The RDEVSNA field
is an alternate definition for the current RDEV ADD field. The real device address
has no meaning for SNA logical units.
After VM/VCNA completes the initial processing for the SNA logical unit, it
passes the user's LOGON request to SNA CCS. SNA CCS edits the LOGON command and all subsequent commands and passes them to CP console services
using CP interfaces. CP processes the commands the same way it processes non-SNA commands. However, VM/VCNA, rather than CP, manages redisplay
of the input line.
The work element block serves as the interface between SNA CCS and VM/VCNA. Both SNA CCS in CP and VM/VCNA in the VTAM service
machine create work element blocks. In SNA CCS, the work element block is
known as the WEBLOK. In VM/VCNA, the work element block is known as the
DTIWEB. SNA CCS and VM/VCNA pass the WEBLOK between them and use
it as the interface for all requests for work from the other component. The data
portion of the work element block contains input or output lines to be passed and
the control portion contains transaction orders and environment data. See VM / SP Data Areas and Control Block Logic, Volume 1 for a detailed description of the WEBLOK. SNA CCS creates the work element indicator block (WEIBLOK) as a header for
the WEBLOK. Its function is to identify a unit of work that is in progress or that
has not yet been processed. The WEIBLOK points to the WEBLOK and CONT ASK associated with a given user. See VM / SP Data Areas and Control
Block Logic, Volume 1 for a detailed description of the WEIBLOK. For non-SNA processing, CP console services build channel programs, lOBs, and
use DMKIOS to perform their I/O. SNA processing moves the physical device
management to VM/VCNA. Instead of calling DMKIOS, CP then passes control
to SNA CCS. SNA CCS does not build any channel programs or lOBs. It deter­
mines what action must be taken for the console and sends the transaction to VM/VCNA instead of to DMKIOS. VM/VCNA and VTAM set up the I/O operations to the terminal and issue an SIO. CP intercepts this SIO and performs
the I/O the same way it does for non-SNA processing.
Input line redisplay for SNA terminals is handled by VM/VCNA. VM/VCNA Redisplay of input line
To reduce the number of VT AM SENDs to the terminal, VM/VCNA does not
immediately redisplay the input line. Instead, it holds the I/O operation until
SNA CCS requests more I/O to that terminal; for example, the response to the
input or a message. When VM/VCNA receives a write to the device, it sends
the input line to be redisplayed and the information from SNA CCS to be writ­
ten to the device in one VT AM send.
184 VM/SP System Programmer's Guide