colI col 9 I I V V
userid text
The userid portion of the data identifies the sender. If the data is not received by
means of a MSG, WNG, SMSG, or using SCIF, then the userid is that of the recip­
ient.
If a virtual machine has both a valid path to the *IvISG system service and a sec­
ondary user specified in the CONSOLE directory control statement (enabling that
virtual machine to use SCIF), then incoming messages (except for SMSGs, which
are not console messages) are directed to the secondary user instead of the lUCY *MSG system service. If the secondary user is not available, the message is queued
on the *MSG system service path.
Note: The following types of data are not placed in the console spool file for the
indicated conditions: • CP command output --if this is being received in a buffer via DIAGNOSE X'08'.
Messages and Warnings --if they are being trapped via the lUCY and *MSG System Service. The Message System Service 193

DASD Block I/O System Service
The DASD Block I/O System Service is a CP system service. It provides a virtual
machine with device-independent access to its virtual DASD devices. Device types
supported are the Count Key Data (CKD) devices: 2314,2319,3330,3333,
3340, 3344, 3350, 3375, and 3380, and the Fixed Block Architecture (FBA)
devices: 3310 and 3370. (Device 2319 is formatted as a 2314, device 3333 is
formatted as a 3330, and device 3344 is formatted as a 3340.) This service sup­
ports logical block sizes of 512, 1024,2048, and 4096 bytes.
Note: The CMS 4K block structure on the first track of a 3340 disk is formatted
differently than the other tracks of a 3340 CMS disk. The first track of the
mini-disk contains three blocks. The first block has a length of 80 bytes, the sec­
ond, 4096 bytes, and the third, 80 bytes. The remainder of the mini-disk is format­
ted as usual, two 4096-byte blocks on each track.
Establishing Communications with DASD Block I/O Service
The CMS RESERVE command and the CMS DISKID function should be issued
before using the DASD Block I/O System Service. These two facilities enable you
to create a uniquely organized CMS file on a DASD and obtain information about
the file needed to use the DASD Block I/O System Service. For further informa­
tion, see "Using the DASD Block I/O System Service from CMS" in Part 2 of this
manual, or see the VM/SP CMS Command and Macro Reference.
DASD Block I/O uses IUCV to set up communication between itself and a virtual
machine. The IUCV macro checks the validity of all the IUCV parameters. Any lUCY errors are handled according to lUCY specifications. The DASD Block I/O System Service checks the validity of all the parameters it requires. Any errors
resulting from this check are handled as described in the following sections. lUCY requires that the virtual machine issues a DECLARE BUFFER command to
initialize the virtual machine for IUCV communication. This command also speci­
fies a buffer where IUCV can store external interrupt information. After commu­
nications is established with lUCY, the virtual machine must issue a CONNECT. command to establish a path between itself and the target communicator. The tar­
get communicator, in this case, is the DASD Block I/O System Service. Only one CONNECT may be issued to userid *;BLOCKIO for each virtual device that is
intended to receive I/O requests.
No special authorization is required for a virtual machine to use DASD Block I/O. The MAXCONN (maximum connection) limit in the directory can be enlarged to
satisfy the user's requirements. The DASD Block I/O System Service allows con­
nections from any user. IUCV CONNECT to the DASD Block I/O System Service
An lUCY CONNECT is issued by the virtual machine with USERID= *BLOCKIO and PRMDATA=YESspecified in the IUCV CONNECT parameter list. In this
case, IPUSER, the user data field in the IUCV parameter list, must have the follow­
ing format. These values are obtained by the CMS DISKID function.
194 VM/SP System Programmer's Guide