VM/SP Use of the IBM 3850 MSS Virtual machines operating CMS, OS/VS 1, or OS/VS2 (MVS) may access mass
storage volumes containing VM/SP minidisks or entire mass storage volumes dediĀ­
cated to the virtual machine. These volumes appear to the virtual machine as 3330 volumes and are accessed using 3330 device support in the virtual machine. VM/SP controls allocation, volume mounting, and volume demounting. Virtual
machines that run OS/VS 1 or OS/VS2 (MVS) with MSS support can also access
mass storage volumes using dedicated device support. VM/SP Access to the MASS Storage Control
Whenever an MSS 3330V volume must be mounted or demounted, the VM/SP control program first selects an appropriate device address. If a volume mount is
required, the device is selected from the pool of available 3330V devices created at
system generation time. If a volume must be demounted, CP selects the address of
the device on which the volume is currently mounted. .
To pass mount and demount orders, the virtual machine must have an MSC port
dedicated to it via the ATTACH command or the DEDICATE directory statement.
An application program named DMKMSS is distributed as part of VM/SP; it acts
as an interface between CP and the MSC. After DMKMSS is started in an OS/VSl or OS/VS2 (MVS) virtual machine, it uses a special virtual I/O device
and the VM/SP DIAGNOSE interface to communicate with the VM/SP control
program.
If the MSC request was for a volume mount, the MSC ending status indicated that
the MSC was processed. If the MSC accepts the mount order, the MSC orders the
staging adapter to generate a pack change interrupt (an unsolicited device end) on
the device when that device has been mounted. CP receives the pack change interĀ­
rupt, the RDEVBLOK is set to indicate that the volume is mounted, and any VM/SP task waiting for the volume is marked dispatchable. If the mount order
was rejected, no further processing of the mount occurs. The previously allocated
RDEVBLOK is marked free and processing continues with the next MSS request.
Asynchronous MSS Mount Processing
When an MSS volume mount is required to satisfy a LINK or ATTACH command
or an MDISK or DED directory statement, CP returns control to the virtual
machine as soon as MSC accepts the mount requestJ. The virtual machine may
continue to execute before the virtual device specified on the MDISK, DED, LINK,
or ATTACH is available.
The reasons for asynchronous MSS mount processing are the relatively long time
required to complete the mount, and the chance that an error may occur in the MSS after the mount order is accepted. The virtual device to be mounted may not
be vital to the specific task to be accomplished. Also, if an error occurs in the MSS (such as a permanent read error on a cartridge) after the mount is accepted, the
error indication is passed from the MSC to the virtual machine. VM/SP cannot
3 However, the central server cannot issue these CP commands. The central server is the MSS communicator virtual machine which acts as an interface between CP and the MSC. CP comĀ­
mands issued to the central server are ignored and a message is issued. Single Console Image Facility 201
determine that an error has occurred and that the mount will not complete. If the
virtual machine were not dispatchable until the mount completed, it would be
locked out until the MSS error was corrected.
With asynchronous mount processing, the virtual machine has the flexibility to
either continue processing without the affected virtual device, or wait until the MSS mount completes. If the virtual machine issues an SIO instruction to a virtual
device that is defined on the volume being mounted, VM/SP queues the I/O request until the mount completes. The virtual machine is marked I/O wait
nondispatchable until the mount completes and the SIO is started.
VM/SP'Processing of MSS Cylinder Faults VM/SP supports 3330V cylinder fault processing in two ways: real channel proĀ­
grams directed to 3330Vs are constructed so that cylinder faults can be recognized
and the channel program restarted; and the attention interruption (indicating that
the cylinder fault has been satisfied) is recognized and any I/O for that device
restarted.
When the VM/SP processor issues a seek CCW to a 3330V device, the staging
adapter must translate the seek argument to the correct cylinder of staging space.
If the cylinder referenced in the seek is staged, then the SIO is passed to the associĀ­
ated staging DASD drive. If the referenced cylinder is not staged, the staging
adapter initiates cylinder fault processing. The staging adapter first passes a cylinĀ­
der fault indication to the MSC, requesting the cylinder of data to be staged. It
then returns a status modifier to the channel in response to the seek, which causes
the channel to skip one CCW in its CCW fetch processing. That is, the channel
does not fetch the next CCW after the seek.
As a result of the cylinder fault, the MSC allocates staging space for the requested
data and causes it to be staged. The staging adapter then generates a channel
end/ device end interruption to indicate that the cylinder has been staged .
.It is possible in error situations that the attention interruption may not be received.
Each time an I/O request is queued by VM/SP as a result of a cylinder fault, a
timer is set. If the timer expires before the interruption is received, a message (DMKSSS0741) is written to the VM/SP system operator and the request is
retried.
Backup and Recovery of MSS Volumes The process of creating backup copies of MSS volumes, and restoring from those
backup copies, can be controlled through the OS/VS access methods services COPYV command. This command can operate without system operator interĀ­
vention.
For each active volume in the MSS, there may be one or more copy volumes. At
any time, the active volume may be copied to a copy volume with the access methĀ­
od services COPYV command. All volume mounts and data transfer are controlled
by this command. If at any time it is necessary to restore the level of a volume to
that of a copy, the OS/VS access methods services RECOVERV command is used.
All the OS/VS access methods services commands can be run from either a real
processor or a VS virtual machine. If the MSS communicator virtual machine is in
operation, these commands can be run from that virtual machine while it is acting
as the communicator. 202 VM/SP System Programmer's Guide
Previous Page Next Page