[email protected] (Paul Gilmartin) writes: > Was your "trivial program" made available to end customers, or were > they compelled to reinvent it? > > I've done most of these operations using SuperC with the UPDCMS8 > option in place of your program; the UPDMVS8 option is practically > worthless for this purpose. > > And once one recognizes that it's possible to rehabilitate damaged or > missing sequence numbers, it's only a short logical step tp realize > that one didn't need the sequence numbers in the first place.
re: http://www.garlic.com/~lynn/2013e.html#66 Sequence Numbrs (was 32760? http://www.garlic.com/~lynn/2013e.html#85 Sequence Numbrs (was 32760? it was like my replacement done for IPCS ... I wasn't allowed to distribute it (even tho nearly all internal datacenters and customer support PSRs used it) ... but was allowed to describe it at user group meetings ... I managed to describe it in sufficient detail that coding become a straight forward exercise and those results were made to customers. people that had a bunch of other tools that were sequence number based ... would have required all the other tools to have been changed. this was small incremental tweak. one of my hobbies was highly enhanced production operating system for internal datacenters ... originally on cp67/cms and then on vm370/cms ... periodically some of the changes might leak out to customers. old email regarding migration of cp67/cms to vm370/cms and making the new csc/vm available to internal datacenters (aka internal datacenters had been in process migrating from cp67/cms to vm370/cms): http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 later after i transferred to sjr ... the distribution became sjr/vm ... other old email (I also included reseq with sjr/vm distribution) http://www.garlic.com/~lynn/2006u.html#email800501 http://www.garlic.com/~lynn/2007c.html#email830705 http://www.garlic.com/~lynn/2007c.html#email830709 http://www.garlic.com/~lynn/2007c.html#email830711 part of the issue was that since the internal distribution was purely a hobby ... having to track standard product PLC & release distributions with large set of my own updates could get time-consuming. also contributing was the standard product groups would periodically be changed affecting code quality. when the mvs group did succeed in getting vm370 killed and all the people transferred to pok to work on mvs ... endicott finally did managed to save the vm370 product mission ... but had to reconstitute a development group from scratch ... vmshare archives have some amount of comments about code quality during that period. http://vm.marist.edu/~vmshare original virtual machine was highly efficient microkernel ... which had a totally different development culture from the traditional enormously bloated IBM operating system development methodology. It took hard work to maintain efficient microkernel paradigm ... people coming over from traditional operating system development background found it extremely easy to go wild with enhancements to the kernel ... since it was so small and compact ... but that eventually resulted in just another overly bloated piece of kernel-ware. -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
