The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main as well.
[EMAIL PROTECTED] (, IBM Mainframe Discussion List) writes:
> The way z/OS itself attaches a device to a particular channel is with the
> Modify Subchannel (MSCH) instruction. This instruction causes a real link
> to
> be built between a device-unique control block in the Hardware Storage Area
> (HSA) and a channel path-unique control block in the HSA. However, this
> requires that both the device and channel path be real.
>
> Gerhard's answer reminded me of what VM does. It controls real devices and
> real channel paths. It intercepts all privileged instructions. When a
> guest
> machine is IPLed under control of VM, VM intercepts all the instructions
> that the guest machine is doing to initialize its use of devices and
> channels.
> VM simulates the way the MSCH instruction works. VM also intercepts all
> SSCHs that occur after the virtual IPL, and knows which real device
> corresponds
> to the virtual (guest) machine's virtual device.
starting with cp40 circa 1966 (custom modified 360/40 with virtual
memory, which morphed into cp67 when standard 360/67 with virtual memory
became available ... and then morphed into vm370 when virtual memory
became available on all 370s). takes interrupts by owning the real page
zero ... and the virtual machines run in a virtual address space
... where they have a virtual machine, virtual page zero (that isn't
real page zero). it runs the virtual machine in problem mode so it
intercepted all supervisor instructions ... including start i/o (x'9c').
hasp intercepted excp entry in order to take over all requests to
("psuedo") unit record devices.
nsc/hyperchannel did something similar for MVS in the 80s ... for
"channel" connected devices ... that were actually connected to (remote)
hyperchannel device adapter. the devices appeared to be a local channel
attached controller/device. there was a hyperchannel a22x adapter
connected to real mainframe channel. at the remote end there was a51x
device adapter that simulated the real mainframe channel ... (that
controllers attached to). the intercept would make a "shadow" of the
real channel program which is downloaded to the memory of the a51x
device adapter (simulating mainframe channel).
the device i/o actually went thru the channel attached a22x ... to the
simulated channel a51x adapter to the controller (to the device). the
interrupt came back as a22x which had to be fielded and then generated a
simulated interrupt for the psuedo device (actually connected remotely
to a51x).
in the HASP scenario ... the psuedo unit record device was simulated
with disk spooled operations. in the nsc/hyperchannel scenario, the i/o
was actually executed on a a51x adapter simulating mainframe channel.
I had originally done support in 1980 for the STL lab ... as source
changes to VM370 ... as part of STL lab filling up and needing to move
300 people from the IMS group to offsite bldg. They had looked at remote
3270s but the performance & human factors was totally unacceptable. The
alternative was to remote 300 "local" 3270s at the remote site via
nsc/hyperchannel over T1 link. while T1 is only about 150kbytes and 3274
is 600kbytes ... it was close enuf that there wasn't noticable
slow-down. In fact, because of certain other issues, overall performance
actually improved.
it was vetoed allowing me to directly release the software as a product
... so nsc had to redo it from scratch ... including a mvs flavor w/o
requiring source changes.
there was a glitch, i had chosen to simulate channel check when i got an
unrecoverable error on T1 link. This would push the recovery/retry up
into operating system error recovery. i got a call from 3090 product
manager after 3090 had been in customer shops for a year. They found
that unexpected number of channel checks had been recorded for 3090
product line ... which was traced back to a some customers running
nsc/hyperchannel remote device support (both vm & mvs). I did some
analysis and decided that IFCC (interface control check) simulation
would result in effectively the some retry sequence ... and then asked
nsc if they would change the implementation to simulate "ifcc" instead
of "cc".
another recent post discussing the implementation for STL:
http://www.garlic.com/~lynn/2008m.html#20 IBM-MAIN longevity
including screen shot of the logo screen for the ims group
3270 screen:
http://www.garlic.com/~lynn/vmhyper.jpg
the STL lab implementation was duplicated in boulder for the ims field
support group there ... when they were moved to bldg. on the other side
of busy road. for the boulder implementation, T1 infrared modems mounted
on the roofs of the two bldgs was used. there was concern that fog,
and/or rain/snow storms might interfer with the infrared signal. Turns
out, there were some signal degradation recorded during a white-out snow
storm when nobody was able to get into work.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
