In a message dated 11/21/2008 6:26:45 P.M. Central Standard Time, [EMAIL PROTECTED] writes: >and after looking at the S/370 books I see the SIO x'9C' instruction which made me think about STARTIO again. On a S/370, the machine instruction SIO (x'9C') was named Start I/O. It was a single machine instruction what told the channel subsystem to start processing a given channel program (series of CCWs). Ever since S/370-XA in the early 1980s, there is no more SIO instruction. There is now the machine instruction SSCH, named Start Subchannel. It functions very similarly to SIO, namely it tells the channel subsystem to start processing a given channel program. To confuse us all even more, IBM devised a macro spelled STARTIO (rhymes exactly with "Start I/O", the name of the old SIO instruction). This macro requires as input the address of an IOSB. Look in SYS1.MODGEN (or maybe MACLIB) for IOSDIOSB or something like that for the DSECT of an IOSB. The macro makes sure the IOSB address is in general purpose register 1, then BALRs into an IOS module which builds a request control block structure that points to your IOSB, and puts this request on a queue of such I/O requests for the UCB involved. Sooner or later another IOS module is executed which removes this request from the queue and tries to start the I/O operation by using the SSCH instruction. >Now I'm reading US Patent 6,453,277 which is Virtual I/O Emulator in a Mainframe Environment. Nowhere in this patent does it mention STARTIO. It talks about FLIH hooks instead. I would speculate that the patented software simply uses the STARTIO macro to do its I/O requests rather than a higher level access method macro, such as EXCP. So trying to research STARTIO in how this software works is a red herring. I have built much software that intercepts the IOS module that STARTIO BALRs into. This allows me to look at each channel program before it is started with the SSCH instruction way down deep inside another IOS module. But if you want to simulate every possible event involving an I/O device, then you may also need to intercept I/O interrupts. But a FLIH (First Level Interrupt Handler) could also be intercepted by forcing a UCB's Subchannel ID number to be invalid. Then any I/O instruction involving that device will cause a program interrupt. The patented software would then gain control over the I/O instruction by having also overlaid the program interrupt new PSW's instruction address. The location directly pointed to by any of the six new PSWs is called the First Level Interrupt Handler for that particular class of interrupts. The code to process an interrupt is typically quite voluminous, so the FLIH typically just saves system status somewhere and then branches to the much grander piece of code called the Second Level Interrupt Handler (SLIH),where all the real work is done for that type of interrupt. There are typically many ways to intercept certain events inside z/OS. Causing a program interrupt with an invalid SCHID and front-ending the program FLIH is just one of several ways to do it. There is much less overhead in this method than if you intercept all STARTIO macros and all I/O interrupts, since only I/O events occurring on one particular device will cause the intercept to occur. Bill Fairchild Rocket Software
**************Check out smokin’ hot deals on laptops, desktops and more from Dell. Shop Deals (http://pr.atwola.com/promoclk/100000075x1213345834x1200842686/aol?redir=http://ad.doubleclick.net/clk;209513277;31396581;l) ---------------------------------------------------------------------- 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
