The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Alan Altmark) writes: > Since we, as a group, are unable to agree that XEDIT is the Best > Mainframe Editor Ever (just bait - don't take it), I don't see how > we will agree on what constitutes Good Programming. In any > language. We can all construct programs that everyone will agree > are just fine, and others everyone will agree are horrible. > Naturally the world is filled with programs and programmers that > live in the middle. Big deal. In fact, I HOPE we don't all agree. > If we did, then how would we grow as programmers? now that you mention it ... some email exchange with the RED author when i was trying to get Endicott to release RED (in lieu of XEDIT). Later the Endicott position was that it was the RED author's fault that he had implemented RED before XEDIT and had put more features in RED than were eventually implemented in XEDIT ... and therefore it was the fault of the RED author that he had done something so bad ... it was his duty to fixup XEDIT with the additional features that he had put in RED. From: wheeler Date: 03/11/80 08:52:58 To: red author I have a feeling that I may have done you a disservice. When I was in Endicott last May I told them they ought to be putting out RED instead of XEDIT. I went into a lot of detail about how it was faster, more function, better, etc. (although other people may have also) and left them with documentation. XEDIT is now announced and is going out. Since last May they have gone over the RED documents and have added several of the items to XEDIT but it still isn't as good (except maybe in the feature of being able to use EXEC2 which would be common between edit enviornment and others). When I talked to several people from Endicott at the internal meeting and Share, they sort of acknowledged the above. My suggestion that they scrap XEDIT and put out RED was received very lightly. (ignoring the fact that they should have put out RED instead of XEDIT) thier feeling is that it is the duty of the RED author to enhance XEDIT to include all RED features. That really floored me, Endicott seems to have some perverted view of reality. It isn't thier fault they put out XEDIT instead of RED, it is your fault that you put in more features in RED than were in XEDIT. .... snip ... From: wheeler Date: 03/12/80 09:26:53 To: red author well, it is obviously your fault that RED has more function than XEDIT. Since you are responsible for the problem then you should be the one to rectify it. ... snip .. ... and then from earlier, not functional, just performance numbers *EDIT* is the old, cms standby; the first cp67/cms implementation was strictly disk-to-disk work files ... but fairly quickly was enhanced to take advantage of virtual memory for its operation. From: wheeler Date: 06/06/79 10:25:14 Those are interesting figures on editors ... but I figured that a better measure of "internal peformance" would involve something more strenuous than "bottom". So I did a "bottom" by doing a "c / / / * * " with all seven editors, with the following results: *EDIT* CMSLIB MACLIB S 2.53/2.81 *RED* CMSLIB MACLIB S (NODEF) 2.91/3.12 *ZED* CMSLIB MACLIB S 5.83/6.52 *EDGAR* CMSLIB MACLIB S 5.96/6.45 *SPF* CMSLIB MACLIB S ( WHOLE ) 6.66/7.52 *XEDIT* CMSLIB MACLIB S 14.05/14.88 *NED* CMSLIB MACLIB S 15.70/16.52 ... snip ... i use to do my own internal system release/distribution with lots of fixes and enhancements ... bldgs 14&15 refers to the disk engineering lab and disk product test lab ... misc. postings here http://www.garlic.com/~lynn/subtopic.html#disk From: wheeler Date: 04/29/80 14:03:23 To: world-wide distribution list current schedule is to ship PLC/LTR 8 CP system next Monday. All (new) bugs have been identified and fixed. System is currently running in building 14&15. It is scheduled to be brought up here either tomorrow or the next day. CP changes includes some conversion to CSL20 & a number of updates from the current STL release 6 updates. CMS will include RED 3.4 & XEDIT. It would be helpful if all locations outside of the San Jose area ship me a tape and mailing label if possible. ... snip ... and for some total different drift on the subject of *CMSBACK* http://www.garlic.com/~lynn/2006u.html#19 Why so little parallelism? http://www.garlic.com/~lynn/2006u.html#21 Why so little parallelism? ... and http://www.garlic.com/~lynn/2006t.html#24 CMSBACK which then brings up this recent thread x-posted to alt.lang.asm & comp.arch http://www.garlic.com/~lynn/2006t.html#45 To RISC or not to RISC http://www.garlic.com/~lynn/2006t.html#46 To RISC or not to RISC http://www.garlic.com/~lynn/2006t.html#47 To RISC or not to RISC http://www.garlic.com/~lynn/2006t.html#48 To RISC or not to RISC http://www.garlic.com/~lynn/2006u.html#15 To RISC or not to RISC The following is part of an exchange with the author of RED regarding creation of a RED shared module (read-only protected shared segment executable image) on "PAM" disk. To: wheeler Date: 11/03/78 13:25:59 From: red author Lynn, I got your script file (i haven't read it yet). I couldn't follow your msg about 64K blocks & what I could do with them. Please amplify. I have done nothing toward making RED sharable, as it seems to be a big job. .... snip ... I had original started on CMS paged mapped filesystem and shared segment support with cp67/cms. http://www.garlic.com/~lynn/subtopic.html#mmap A very small subset of this function was picked up and released in vm370 release 3 called DCSS. a few recent posts mentioning DCSS http://www.garlic.com/~lynn/2006.html#17 {SPAM?} DCSS as SWAP disk for z/Linux http://www.garlic.com/~lynn/2006.html#18 DCSS as SWAP disk for z/Linux http://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux http://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP disk for z/Linux http://www.garlic.com/~lynn/2006.html#28 DCSS as SWAP disk for z/Linux http://www.garlic.com/~lynn/2006m.html#53 DCSS http://www.garlic.com/~lynn/2006m.html#54 DCSS http://www.garlic.com/~lynn/2006m.html#56 DCSS http://www.garlic.com/~lynn/2006q.html#27 dcss and page mapped filesystem I had made small extension to control information generated by the cms "GENMOD" command to include shared segment specifications. This was automatically used by the cms "LOADMOD" function (when loading a cms executable image) to map any specified shared segments. Aa part of the original CMS shared segment changes, I had modified the standard cms editor and several other routines to be able to execute in read-only protected shared segment (this changes were included in some of those picked up as part of DCSS release). This particular exchange with the author of the RED editor was concerning modifying the RED executable image to reside in a read-only protected shared segment. various collected posts about modifying and/or creating code for residing in shared segments ... including issues with os/360 convention relocatable address constants creating difficulty for allowing the same shared segment image to reside concurrently at different virtual addresses in different virtual address spaces (i.e. when i was modifying code to reside in read-only protected shared segment, i also attempted to removed the execution location dependencies ... most freqently involving os/360 convention relocatable address constants) http://www.garlic.com/~lynn/subtopic.html#adcon A feature that RED editor added early was support for automatically generating sources changes as CMS update files. When I was an undergraduate starting out working on cp67/cms, i was making an large number of source code changes as CMS update files. The CMS update command convention was similar to IEBUPDATE, "./" replace, insert, delete, etc, functions ... based on sequence numbers in the original source file. However, the "new" source had to have the sequence numbers manually keyed in cols. 73-80. This became quite tedious, so i created the preprocessor convetion with "$" field on the update "./" control statements. I wrote a preprocessor to the CMS update command that preprocessed a source update, stripped off the "$" and generated a temporary update working file with all the new source statements with the sequence numbers automatically added. The "$" convention was later adopted by the multi-level source update process that was created during the l/h/i effort ... joint effort between science center and endicott to had 370 virtual machine support co cp67 kernel (running on real 360/67). recent posting about that effort: http://www.garlic.com/~lynn/2006u.html#7 The Futre of CPUs: What's After Multi-Core? eventually the "$" field support was merged into the standard CMS update command (rather than being done separately by pre-processing function) ... and still later, CMS editors provided direct support for both applying multi-level updates as part of edit invokation and generating update files from source changes. misc. past posts discussing the "$" field convention: http://www.garlic.com/~lynn/2002n.html#39 CMS update http://www.garlic.com/~lynn/2004b.html#59 A POX on you, Dennis Ritchie!!! http://www.garlic.com/~lynn/2004g.html#43 Sequence Numbbers in Location 73-80 http://www.garlic.com/~lynn/2005i.html#30 Status of Software Reuse? http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3 http://www.garlic.com/~lynn/2006n.html#45 sorting ---------------------------------------------------------------------- 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
