In a message dated 6/11/2008 8:25:57 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: >It's my understanding that for many decades EXCP has not executed channel programs in place and as provided by the caller. Back in the days before paging systems, back when there was no virtual or real storage, back when storage was just called "storage", EXCP would execute the channel program in place and as provided by the caller, but with extra CCWs in front of the caller's first CCW. These extra CCWs were added to insure data set integrity; i.e., the caller's channel program cannot go to any track that is not in the list of allocated extents created by OPEN. I don't remember for sure, but it was probably possible for a caller to have a read command executed with a storage address that would cause data being read to overlay storage that was outside his region, partition, or whatever the big chunk of storage was called. So you could clobber the operating system as well as other users' central storage with read commands. The various DASD access methods on these systems (OS/360, DOS/360, TOS/360, and BPS/360) were QSAM, BSAM, BPAM, BDAM, ISAM, and QISAM. They all used EXCP internally to do I/O requests, except for possibly ISAM which sometimes had a naked SIO instruction (or so I was told). I don't know very much about the other access methods for devices other than DASD and tape (e.g., TCAM, QTAM, and BTAM), but I would guess that they all also used EXCP internally. With the advent of virtual and real storage, IBM chose to require that the data addresses inside CCWs be interpreted by the I/O hardware as real addresses. Thus a scheme was needed to convert from virtual addresses to real addresses in order to make the transition to the new systems transparent to customers. The MVS architects decided to create a new I/O concept called "IOS Driver" which is a new layer of software that performs I/O requests without having to use EXCP. They also invented a new "access method" called STARTIO which replaced EXCP as the lowest possible level access method. The ancient DASD access methods, QSAM etc., still use EXCP, but EXCP was redesigned to interface between the callers of EXCP (ancient access methods), which present EXCP with channel programs containing virtual addresses, and the new lower level and thus intermediate, internal "access method" called STARTIO, which assumes that the channel program is in non-pageable storage, with real addresses of data, and which was built by a trusted software component. Many new functions in MVS were designed to use STARTIO directly themselves, such as the paging supervisor, while some new MVS components were designed to use EXCP, probably in order to get the new code written most quickly. JES2, e.g., originally used EXCP (I haven't dealt with JES2 internals now for 20+ years, so it may be different now), probably because JES2 was developed from HASP, which used EXCP, and that code was already well debugged, so why rewrite it? >Rather, they are moved to protected storage so the user can not modify them on the fly Yes, unless you have EXCP appendages, but these must be loaded from an authorized library, so the customer can control their use. >they are prefixed to prevent seeks to prohibited tracks; virtual addresses are translated to real; etc. I'd further expect changes to CCW architecture to accommodate XA and later 64-bit addressing and new I/O architecture. Correct on all counts. >So the "checks to prevent it" may be a matter of IBM's resource allotment: rather than continually update EXCP code to all new hardware features, it's easier simply to prohibit use of EXCP for such purposes. I concur. Also IBM would like to "encourage" users to migrate all applications to the latest and greatest software and hardware solutions; namely, VSAM, DFSMS, ESS controllers, etc., so typically IBM adds support to "strategic" products and components first and then maybe, reluctantly and much later, to non-strategic components. They, too, have limited resources for developing new products and adding support for new products into other, older, products that must interface with the new products. >It has always struck me as bizarre that the OS supports running channel programs built by problem-state programs. This is secure only if the channel programs are in effect interpreted rather than executed directly. A more rational layering of functions should have channel programs built only by trustworthy supervisor-state code. I don't know to what you are referring here by "the OS". Problem-state programs in z/OS build channel programs which are then converted to safe, trusted equivalent channel programs by trusted software components before being started by IOS. In VM, CCWs are not interpreted as far as I know, but rather the channel program is scanned before being executed in order to determine how to let it run safely on its own. The only way I can think of to execute a channel program interpretively is to do a separate I/O request for each CCW in the channel program (of course, with the necessary CCWs in front of it for it to work correctly). Then if a CCW reads data, the data would be read somewhere that VM could trust, and then move that data into the caller's buffer. This is similar to how interpretive machine instruction is handled. But the overhead in interpreting channel programs would be prohibitive, I believe, so they are not really interpreted. They are first made safe with the proper CCWs in front of those supplied by the problem-state caller and then allowed to run on their own. Bill Fairchild Rocket Software
**************Vote for your city's best dining and nightlife. City's Best 2008. (http://citysbest.aol.com?ncid=aolacg00050000000102) ---------------------------------------------------------------------- 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
