In a message dated 7/8/2008 6:03:32 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: >If you really want to do it yourself, here are a few things to consider before you jump too far in. >1) Modify OPEN/CLOSE/EOV code to intercept the open and close >2) Intercept device allocation >3) What do you do when DASD gets full? Move data to real tape? Delete oldest? >4) If for #3 you move to tape, how about catalog maintenance? >5) The above have not even started to scratch the surface of all the problems and hurtles that you have to overcome. It is not necessarily easier, but it is more fun (in my weird opinion) to intercept the STARTIO request some time before the SSCH happens (there are several different places where you can do this by front-ending different IOS modules), steal the I/O away from IOS [1], scan the tape I/O channel program's CCWs to determine what it is doing and build a DASD channel program to do the same thing (write a block, read a block, etc.) to a DASD file somewhere, do the DASD I/O, copy its ending status into the equivalent ending status for a real tape device, and finally unsteal the I/O back into IOS [1]. This is seriously difficult stuff, and you will crash your test system many, many times before you are done. You really don't want to do this unless you have a lot of time on your hands, a fire in the belly to learn how IOS internals works, and a fat budget for education or development. There is at least one commercial product that does what you want - "redirects" the I/O to a real DASD device, and it works pretty much the same as in my footnote [1] below. OTOH, modifying O/C/EOV and device allocation is no picnic, either. There were two separate presentations on STARTIO at the August 1987 SHARE in Chicago. I distributed a sample program to read a DASD volume label using STARTIO to all those in attendance, and this document was published in the proceedings if you can find them. Bill Fairchild Rocket Software [1] This means to render the request temporarily unstartable (there are a number of different and easy ways to do this, including never letting the request be put into the queue), pass a pointer to it while POSTing another address space that analyzes the tape channel program, does the equivalent DASD I/O after validating the possibility of doing it at all (file full, etc.), analyzes the result, fills in the original IOSB's status info (you also have to reflect back the tape device's equivalent error status if things go wrong), then invokes the appropriate IOSB exit to post status back to where the original I/O requester can find out that the "tape" I/O has ended. I did all this once (not for tape, though), and it took a very long time to get it right. I had the time, the fire in the belly, and the budget. A major part of the difficulty is the large variety and complexity involved in scanning a channel program and supporting all the possible ways of chaining CCWs, all the CCW flag bits, all the types of indirect address lists, and so on. You have to write code that emulates a large fraction of five of the Principles of Operations' most incomprehensible and somnifacient chapters (13-17) in addition to a large fraction of the book that describes how a tape device's CCWs work. Oh, yeah, and the DASD book, too, so you can build the correct DASD channel program.
**************Gas prices getting you down? Search AOL Autos for fuel-efficient used cars. (http://autos.aol.com/used?ncid=aolaut00050000000007) ---------------------------------------------------------------------- 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
