TRQBLOK I/O REQUESTS VM/VCNA clears the input area, updates the status field, and redisplays the
line using the same VTAM SEND. CCS Redisplay Timer
VM/VCNA passes a timer variable to SNA CCS when it invokes the IUCV CONNECT function. This value indicates to SNA CCS how long it should
wait for a command to complete before SNA CCS issues an IUCV SEND to
the VT AM service machine to request input line redisplay. SNA CCS sets a timer to tell it how long to wait before requesting redisplay of
the line. This is necessary since some commands do not produce any output,
and CP or CMS might require a significant amount of time to finish the com­
mand processing. If the timer expires before CP has output to write to that
terminal, SNA CCS issues an IUCV SEND to VM/VCNA requesting a write
for the redisplay.
In non-SNA processing, DMKGRF builds a Timer Request Block (TRQBLOK) that it uses (1) for its status flags (2) for an interrupt return address after an I/O operation (3) after a timer expires and (4) as a header to chain CONT ASKS when
in FSS mode.
In SNA processing, SNA CCS does not use TRQBLOK for the above functions
because: (1) status fields are kept by the VCNA for each SNA terminal user, (2) IUCV mechanisms are used to return control after SEND requests to the
VM/VCNA, (3) the timer support for the alarm, MORE/HOLDING state, and NOT ACCEPTED has been moved to VM/VCNA, and (4) SNA CCS has its own
control block structure to associate a user with its related CONT ASKS, IUCV con­
trol blocks, and the work element block. Since the processing of CONT ASKs has
been streamlined to help performance, the TRQBLOK is no longer needed for
queueing CONT ASKs. However, in SNA processing, a TRQBLOK is still created, since a timer is required
for the input line redisplay processing described above.
DMKGRF, the module that manages I/O to a real 3270, performs requests for I/O from DMKQCN synchronously. When DMKQCN requests a response, DMKGRF
schedules an lOB for the I/O operation and waits for the I/O to complete before
sending the response. SNA CCS takes the virtual machine out of SIO wait state as
soon as the I/O to the real device is started. In the case of a write, SNA CCS sends the write request to VM/VCNA, takes the virtual machine out of the SIO wait state, and returns immediately to the caller with a successful completion
response as if the I/O had completed successfully.
In some situations, SNA CCS waits for a response from VM/VCNA before
responding with a return code to the CP system. This is governed by a 'pacing
value' equivalent to the number of lines for a full screen. In this way, VM/VCNA
can reach SNA CCS with a PAl key indicator to stop processing; SNA CCS does
not flood IUCV and VM/VCNA with output from some commands (for example, DISPLAY). SNA CCS always waits for a response from VM/VCNA for DIAG­ NOSE X'58' writes for CMS and full screen support modes before returning to the
caller with a response.
SNA Virtual Console Communication Services 185

VT AM I/O Reduction
MORE/HOLDING Condition
SNA Accounting
NCP and PEP Sharing User Termination SNA CCS queues a CONTASK if it is waiting for a response on either a write or a
read request. It does not split CONT ASKs for mUltiple line writes but passes the
entire write buffer to VM/VCNA, thus reducing IUCV SENDs and RECEIVEs. SNA CCS batches console function and virtual machine SIO output lines in a lK
byte buffer. The batch lines are sent to VCNA when the buffer is full, a read is ini­
tiated by a virtual machine or CP to a SNA terminal, the pace value reaches zero,
the redisplay timer expires, a Diagnose X'58' operation takes place, or the virtual
machine is dropped from the dispatch queue.
The batching technique and priority structure ensures that either a full screen of
information is presented to VM/VCNA for each CP or CMS console transaction
or the transaction is complete (for those transactions with less than a full screen of
data) prior to control being given to the VSM. To reduce the number of IUCV transactions, VM/VCNA resolves the MORE/HOLDING condition when it occurs on the screen. VM/VCNA takes
whatever action is appropriate and avoids notifying SNA CCS of the screen status
in most cases. In cases when a mode change may take place (PAl key) or an inter­
rupt must be reflected to a user's virtual machine (PAl or PA2 key), VM/VCNA
resolves the MORE/HOLDING condition, then notifies SNA CCS of which key
was pressed and the screen status at the time. VM/VCNA resolves pressing of the
clear key or enter key in MORE/HOLDING status without notifying SNA CCS. VM/VCNA records accounting data on a terminal user basis. When the SNA user
logs off, VM/VCNA passes a maximum of 62 bytes of accounting data, in the WEBLOK, to SNA CCS. SNA CCS uses the CP accounting module, DMKACO to write a VTAM accounting record (type X'07') in the CP accounting file. Nei­
ther SNA CCS nor DMKACO are aware of the contents of the VT AM accounting
record. SNA CCS accrues processor time for a terminal user while it is processing for that
user. This time is added to the time CP already accumulated for the user. The time
appears in the accounting record produced when the user logs off.
Note: Refer to VM/VCNA Installation, Operation, and Terminal Use, SC27-0502 for details of the accounting records.
Since CP supports only a back level of NCP that does not support SNA and
VTAM loads ACF/NCP, you must prevent CP from loading/reloading the back­
level NCP at initialization and at restart. Refer to VM / SP Planning Guide and
Reference for information on how to accomplish this.
When a user issues the VM/SP LOGOFF or a ACF/VTAM LOGOFF, the con­
trol blocks related to the user's virtual machine and SNA terminal are released to
free storage. When VM/VCNA issues the SEVER indicating that a user has
logged off, SNA CCS need only issue a SEVER for its path. If a SEVER reaches SNA CCS and there is a SNARBLOK that indicates the user is disconnected, the
186 VM/SP System Programmer's Guide