VMCF Applicatiolls
Multitasking Pro!,rramming Resource Sharing
Virtual Extensions to VM/ SP Program Testing
The VM/SP system with VMCF provides the user with the potential to apply new
and different techniques to current applications.
The VMCF functions may be used to multitask virtual machines. Each virtual
machine can become a subtask (parallel or otherwise) of another virtual machine.
A virtual machine task can be a simple program or a large processor. The VMCF
functions provide the WAIT/POST, serialization and communication facilities to
control such an environment. The existing VM/SP functions provide efficient
scheduling, dispatching and basic resource controls. The advantage of such an
environment is that a user is less restricted by operating system (software) limita­
tions and gains the flexibility of machine languages and hardware.
VMCF provides a clear and concise method for sharing and serializing resources
between virtual machines. The resources can range from multi-write minidisks to
entire processors. The control functions for resource sharing (such as, resource
management, serialization) can be contained in a virtual machine.
It is conceivable that functions could be added to VM/SP without altering the con­
trol program (CP). A special privilege class virtual machine could be used to pro­
vide additional functions to non-privilege class users using the VMCF interface.
Similarly, CMS capabilities could be expanded (or at least appear to be expanded)
by linking CMS with other virtual machines.
The program testing capabilities offered by VMCF can range from device simu­
lation to teleprocessing network simulation. In particular, VMCF can be used to
provide external interactions from one virtual machine to another. A simulated
teleprocessing network could be constructed with virtual machines. Each virtual
machine would effectively become a node within the network. The network struc­
ture could range from a simple tree type structure to a complicated mUlti-path mesh
type structure. The program logic within each node virtual machine would be the
same logic as required for a real teleprocessing node. In theory, a reasonably com­
plicated structure could be simulated without requiring the physical hardware.
The significant testing capability provided by VMCF is the ability to link the test
system with test/simulation routines in another virtual machine.
INTRA Virtual Machine Communication
Virtual Multiprocessing
Although the VMCF interface is intended for communication from one virtual
machine to another it can also be used to communicate within a single virtual
machine (wrap connection). The VMCF interface could conceivably be used to
link one or more operating system tasks that are logically separated by the
software. This would allow task to task communication rather than virtual machine
to virtual machine communication.
The VMCF interface could possibly be used to simulate a virtual multiprocessing
environment.
The Virtual Machine Communication Facility 85

Security and Data Integrity
Performance Considerations
The VMCF interface provides the following security aids:
The user doubleword in the external interrupt message header can be used to
contain a security code to prevent unwarranted users from accessing a shared
data base or other confidential information.
The AUTHORIZE SPECIFIC option allows a user to restrict messages sent to
his virtual machine. This option is useful when slave machines are to commu­
nicate only with a host machine. The slave machines can AUTHORIZE SPE­ CIFIC with the host and prevent unwarranted users from clogging their
message queues.
The design of VMCF prevents malicious users from intercepting transactions
in process for other users (for example, user D cannot execute a RECEIVE, REPLY, REJECT or CANCEL to a message sent to user B from user A).
The VMCF support module is designed such that a user is always informed of con­
ditions that could threaten the integrity of his own data. The user is notified either
with a DIAGNOSE X'68' return code or data transfer error code. There is no
internal buffering of user data within the control program (CP), a·message is
always retained by either the SOURCE or SINK virtual machine. If a SEND type
request fails, the SOURCE still has a copy of the original message. If a SINK REPLY fails, the SINK user still has a copy of the REPLY data. The Diagnose
return code or data transfer error code can indicate to a user that a transaction
failed. It is up to the user to preserve the associated transaction data. The follow­
ing are considerations which should be noted by a VMCF user:
1. The buffer used for SOURCE data in a SEND, SENDX or SEND/RECV
request should not be freed or reused until the final response external interrupt
is received by the SOURCE. 2. The buffer used for SINK data in a REPLY function can be reused by the
SINK after the DIAGNOSE instruction (REPLY) has successfully completed.
3. The user parameter list (VMCPARM) may be re-used upon completion of the
Diagnose instruction. At that point the VMCP ARM data has been copied to a
VMCF control block (VMCBLOK) by the control program. A user should,
however, maintain queues of VMCPARM data in order to associate an
external interrupt message header (VMCMHDR) with a particular request.
4. A user should always interrogate the DIAGNOSE return code or data transfer
error code for possible error conditions. It is the user's responsibility to deter­
mine the types and extent of error recovery. The DIAGNOSE return code 19
for a SOURCE SEND, SEND/RECV or SENDX request indicates that an
error was associated with the SINK user and for a SINK RECEIVE or REPLY request indicates that an error was associated with the SOURCE user. The
user who, receives this return code does not have to invoke error recovery for
himself but only be aware that the transaction did not complete successfully
because of an error associated with the other user.
There are several factors that can effect the performance of VMCF:
86 VM/SP System Programmer's Guide