Talk:Execute Channel Program

Duplicate info

I have been doing some work on this article and noticed that this article overlaps Channel I/O and, to some extent Count key data. The latter is strictly DASD, while it seems like the former should be less IBM-centric. On the other hand the topic of this article is the EXCP macro, and perhaps not the internals of CCWs. There seems to be no place where the CCW information fits well, but perhaps Channel I/O and Count key data have too much detail. I think we need another article to consolidate System/360 (and later) I/O processing and strip the excess out of these three articles. I don't know what such an article should be called. Peter Flass (talk) 16:18, 6 December 2019 (UTC)

General information on S/360 channel command words should either be in a separate article or in in expanded section of Channel I/O. It's reasonable for that article to have a simple DASD channel program to illustrate the handling of Status Modifier, but any further examples of DASD channel programs should be in DASD-related articles. Likewise, information on the CAW, CCW and IDA list formats belongs in Channel I/O and IBM System/360 architecture, not in Execute Channel Program, Execute Channel Program in Real Storage or Start Input/Output. If anybody writes a S/370 architecture, S/390 architecture or IBM Z architecture article then that is where the new CCW and IDAL formats belong, possibly in addition to Channel I/O.

The existing Channel I/O article is highly IBM Centric and doesn't even adequately cover older IBM systems. Perhaps it should be split into a generic article and an article specific to the S/360 family. I'd love to see someone add material on, e.g., CDC 1604, GE-600 series, UNIVAC 1107 Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:33, 6 December 2019 (UTC)

Agreed the Channel I/O article should be less IBM centric and would prefer expanding the article to add other "channels" to this article making the IBM Channel a specific instance. One problem might be finding an RS to combine the various "channels" in one article. A quick look at Patterson and Hennessy, "Computer Organization and Design' and Blaauw and Brooks, "Computer Architecture wasn't to helpful. Apparently today channel is a mainframe term and other than perhaps IBM it isn't much used these days.

Shouldn't this talk be moved to the Channel I/O article and not here? Tom94022 (talk) 00:30, 9 December 2019 (UTC)

There is no the IBM channel; not only did channels differ among families, but even within families (except for the 7030) there were distinct architectures for 6-bit and 8-bit channels, e.g., 7607 versus 7909 on the 7094. The reason that the discussion started here is that Execute Channel Program contains information that belongs elsewhere, e.g., Channel I/O#Too IBM Specific?. Shmuel (Seymour J.) Metz Username:Chatul (talk).

Too specific

The title of the article is generic, but EXCP exists in DOS/360 and successors and many of the details are quite different from those for OS/360 and successors. I've added some DOS reference, split the existing references depending on whether they are generic, OS-specific or DOS-specific, and added a warning to the lead. If there is an editor with DOS experience, please consider writing DOS-specific sections. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:55, 18 December 2019 (UTC)

quota

As well as I understand it, from reading Mythical Man Month some years ago, the way OS/360 came out, and specifically the I/O subsystem, had to do with the way quotas were used for the people writing it. There were limits in how much supervisor memory space could be used, resulting in as much as possible being moved into user space. Least obvious might be the DCB. In any case, the whole idea behind EXCP is that the access methods do much of their work in user space and problem state, and build the appropriate channel program. Then EXCP where the OS verifies that the channel program doesn't do things it isn't supposed to do, like read/write the wrong data set, or wrong part of memory. As well as I know, Unix and related systems do much more in system space and supervisor state. Enough that Unix reports time used by programs as both user and system time. I don't know that all needs to be in the article, but access methods writing channel programs for user programs should be, and probably the indication that it is done in user space and problem state. A side effect of writing the OS that way, is that user programs can avoid access methods, write their own channel programs, and EXCP them. Then there are self-modifying channel programs, and never-ending channel programs, that might be discussed somewhere. Gah4 (talk) 19:36, 26 May 2020 (UTC)

The OS doesn't need to verify the channel program, althogh it does need to validate the DEB address. IOS puts an appropriate protection key in the CAW, so you can't access unathorized storage, and EXCP prefixes your DASD channel program with a Seek and Set File Mask so you can't access anything outside your dataset. Ignoring a few integrity holes in OS/360 (plugged in MVS), the things that need to be protected are in key zero and the user can't muck with them. It would, IMHO, have been a serious design error to put the DCB and IOB in protected storage.

Self modifying channel programs and never ending channel programs? You might see those in, e.g., Fetch, ISAM, paging; I hope to never see them in user code. But it's not my dog.

While the CS notion of kernel doesn't really apply to OS/360, SRB mode has some parallels; MVS does track CPU time separately for TCB mode and SRB mode. It's probably best to relegate any discussion of the role of SRBs in I/O to STARTIO.

I believe that the trend in Linux has been to move things out of the kernel and into user space; I don't know about (free|net|open)bsd. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:19, 26 May 2020 (UTC)