0000000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) writes: > I have not used IEBUPDTE extensively. When I contributed to > Charlotte, I made more use of CMS UPDATE, which is similar to > IEBUPDTE, but with further features useful for source code control. > XEDIT can generate CMS UPDATE control files, but they contain some > noise which I filtered out with a final pass through SuperC. > > There are more powerful tools than IEBUPDTE. Embrace them. > > Examples include diff3 and various GUI merge utilities.
original CMS UPDATE was single level (mid-60s) ... much more akin to IEBUPDATE. As undergraduate in the 60s, I did preprocessor to CMS UPDATE that support "$" which would do the sequence numbering on the inserted source cards ... eliminating having to manually add them to each one. Later at the science center there was joint project with Endicott for modifications to CP/67 to support 370 virtual memory virtual machines (in addition to 360/67 virtual memory virtual machines) ... aka simulating 370 virtual memory architecture on real 360/67. This was originally implemented all in EXEC ... repeatedly processing CNTRL files and multiple levels of update files. Originally had three levels ... "L" updates to CP/67 (my enhancements to base product CP/67), "H" udpates to CP/67 to provide 370 virtual machines. The combination of "L" & "H" updated CP/67 then ran regularly on production 360/67. Lots of 370 operating system softwarre started development in "H" 370 virtual machines. Then the "I" updates to CP/67 to change from running 360/67 architecture to running 370 architecture ... build typically required applying "L", "H", & "I". This was running regularly in "H" 370 virtual machines a year before the first 370/145 engineering machine supporting virtual memory was operational (and long before 370 virtual memory was announced). In fact, the first 370/145 engineering machine used an "I" level system as early software to test operation of the machine. trivia: initial "I" system IPL failed. It turned out that they had reversed the B2 op-codes for RRB & PTLB ... quickly diagnosed the problem and zap'ed the kernel to correspond with the "incorrect" implementation (they eventually corrected the hardware). trivia: the person responsible for Internet DNS system had been MIT student at the time working at the science center and did some of the original CMS multi-level source update implementation. past posts mentioning science center http://www.garlic.com/~lynn/subtopic.html#545tech Later some San Jose engineers added support for 3330s & 2305s device for CP/67-SJ. This ran production internally on most of the 370 systems for quite some time. Later the multi-level update support was added to both standard UPDATE and eventually XEDIT. I had kept archives of much of the science center files on tapes. In mid-80s, when Melinda Varian was doing her VM History ... she contacted me about getting copies of the original multi-level source update implementation in EXEC. It was fortunate timing ... IBM Almaden Research was starting to have datacenter operational problem (operators were mounting random tapes as scratch), and even tho I had replicated the archives on three different tapes ... they were all in the IBM Almaden Research tape library ... and operators managed to mount all three archive tapes (and several of my other tapes) as scratch. They never got around to notifying users until long after the damage was done. some old email exchange with Melinda (some repeat and not all about multi-level update http://www.garlic.com/~lynn/2011c.html#email850820 http://www.garlic.com/~lynn/2006w.html#email850906 http://www.garlic.com/~lynn/2006w.html#email850906b http://www.garlic.com/~lynn/2006w.html#email850908 http://www.garlic.com/~lynn/2011c.html#email850908 http://www.garlic.com/~lynn/2014e.html#email850908 http://www.garlic.com/~lynn/2007b.html#email860111 http://www.garlic.com/~lynn/2011c.html#email860111 http://www.garlic.com/~lynn/2011b.html#email860217 http://www.garlic.com/~lynn/2011b.html#email860217b http://www.garlic.com/~lynn/2011c.html#email860407 other trivia: much of internal software development was then being done using CMS and CMS multi-level update ... including MVS components like JES2 ... then when came time for release ... they had to port to standard MVS source distribution process. One of the VM/370 issues was even though (originally CP/67) maintenance distribution was all done using the CMS multi-level source ... every new release ... they would permanently apply all maintenance & development updates and resequence each module. Lots of internal sites and customers had developed extensive source updates (some claim there was more source updates on the VM/370 SHARE Waterloo tape than in the base system). The release-to-release resequencing became something of hassle ... so in the late 70s, I wrote a couple programs ... one would take a previous release with all maintenance applied and the new resequenced release and generate an update that represented the change (mostly development) from the old release to the new release, but using the previous release sequence numbers. It was then became a simpler issue to resolve conflicts with local updates and an update that converted to the latest release. Then another program would resequence the resolved local updates from the previous release sequence numbers to the current release sequence numbers. -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
