IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU> wrote on 10/18/2007 
07:32:53 AM:


> I have never delved into I/O prevention, so I don't know what it does, 
how,
> or why, but I believe it is used in preventing an I/O's being executed 
rather
> than positioning the request in the queue. 

  I/O Prevention was introduced in SP2.1.6 in support of HARP a.k.a XRF
(it was a hot standby thing).  It was used for stopping I/O on the
dying system which was being switched to the hot standby.  It could 
be considered to be a software ancestor to what we now do via 
Fencing (a.k.a Channel Subsystem Iosolation) in the machine when
XCF/SFM partitions a system out of a sysplex. 
 
  I think I/O prevention is currently used to implement the 
IOACTION STOP  command. 


> The purpose of the UCB Capture service is to allow anciently compiled
> programs using ancient access methods that require the DCB, DEB, 
> IOB, etc., to  be
> in storage below the ancient 16MB line to do I/O with a thoroughly 
modern UCB
> that is above the line.  The big problem was that the DEB has room only 
for  a
> 3-byte address of the UCB.  Rather than redesign the ancient access 
methods
> that were based on EXCP, IBM provided a way for old access methods to 
get to
> new UCBs above the line with the system service IOSCAPU.   IOSCAPU 
creates a
> copy (called "capturing" the UCB) of an  above-the-line UCB in the 
user's
> private storage and puts that copy below the  line.  The various 
> ancient control
> blocks that need to point to a UCB will  point to the private 
> storage copy with
> a 24-bit address. 

 The captured UCB isn't a copy of the UCB - it is simply another
virtual view of the UCB created via the IARVSERV page level sharing
services.

> Leading edge  access methods are continually updated by IBM
> to support every new wrinkle that  the IOS developers apply to UCBs in 
order
> to support system growth.  Many  of the original constraints in the 
software
> and hardware architecture of S/360  have been relaxed, with occasional 
seismic
> jolts to the appearance of the UCB;  e.g., UCBs can now be above the 
16MB
> line, devices can have five hexadecimal  digits in the device 
number(formerly
> known as "device address"), there can be  more than 65536 devices onone 
LPAR,
> UCBs can be dynamically created in order to  support dynamically 
installed new
> I/O hardware, and more than one I/O can be  simultaneously active 
> with the same
> device.

  Technically, a device number is still only 4 hex digits, but the same
device number can exist in more than one subchannel set.  For convenience
in things like GTF and System Trace, we concatenate the subchannel set
id to the device number, and sometimes loosely think of that as a 5 digit 
device number. 
 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

----------------------------------------------------------------------
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

Reply via email to