The following message is a courtesy copy of an article that has been posted to alt.folklore.computers as well.
[EMAIL PROTECTED] (Paul Gilmartin) writes: > I believe Cowlishaw's book reports that Rexx was developed in the VM > and MVS environments concurrently. It flourished in the former and > withered in the latter, less likely because CLIST fulfilled the need > better than EXEC2 than because less enthusiasm for innovation exists > in the MVS environment (case in point: TCP/IP). Rexx didn't resurface > under MVS until TSO/E. well, not quite: posting of old reference/quote http://www.garlic.com/~lynn/2005j.html#41 TSO replacement from Melinda's vm history paper http://www.princeton.edu/~melinda/25paper.pdf one of the quotes: Mike Cowlishaw had made the decision to write a new CMS executor on March 20, 1979. two months later, he began circulating the first implementation of the new language, which was then called ``REX''. Once Mike made REX available over VNET, users spontaneously formed the REX Language Committee, which Mike consulted before making further enhancements to the language. He was deluged with feedback from REX users, to the extent of about 350 mail files a day. By consulting with the Committee to decide which of the suggestions should be implemented, he rather quickly created a monumentally successful piece of software. ... snip ... similar comments are mentioned in rexx wiki page http://en.wikipedia.org/wiki/REXX and another old quote from this post http://www.garlic.com/~lynn/2006p.html#31 25th Anniversary of the Personal Computer" from one of the references in the above: By far the most important influence on the development of Rexx was the availability of the IBM electronic network, called VNET. In 1979, more than three hundred of IBM's mainframe computers, mostly running the Virtual Machine/370 (VM) operating system, were linked by VNET. This store-and-forward network allowed very rapid exchange of messages (chat) and e-mail, and reliable distribution of software. It made it possible to design, develop, and distribute Rexx and its first implementation from one country (the UK) even though most of its users were five to eight time zones distant, in the USA. ... snip ... and for other topic drift, this was part of the thread related to the internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet having been larger than the arpanet/internet from just about the beginning until sometime mid-85. part of the internal network issues was that while there were mvs/jes2 nodes, nearly all the nodes were vm ... and the jes2 nodes had to be carefully regulated. there were several issues around why jes2 nodes had to be carefully regulated on the internal network (some independent of the fact that the number of vm systems were significantly larger than the number of mvs systems) 1) jes2 networking started out being some HASP mods from TUCC that defined network nodes using the HASP psuedo device table ... limited to 255 entries ... 60-80 entries nominally taken up by psuedo spool devices ... leaving possibly only 170 entries for network node definitions 2) jes2 implementation would discard traffic if it didn't have either the origin or destination node in local defintion. the internal network had more nodes than jes2 could define for the majority of its lifetime ... so jes2 needed to be restricted to boundary nodes (at least not discarding traffic just passing thru). 3) jes2 implementation had a number of other deficiencies, including having confused header information as to network specific and local process handling. different versions or releases with minor variation in headers would bring down whole mvs system. even restricted to purely boundary nodes, there is infamous story of jes2 upgrade in san jose resulted in mvs system crashes in hursley. as a consequence there was special vm drivers created for talking to mvs jes2 systems ... which would convert jes2 headers to compatible format for the specific system on the other end of the line. this was somewhat the side-effect of the vm implementation having separated networking control information from other types of information ... effectively providing a kind of gateway implementation ... something not possible in the JES2 networking infrastructure (including not having a way from protecting itself from other JES2 systems, requiring intermediary vm systems to keep the JES2 systems from crashing each other). misc. past posts mentioning hasp, jes2, and/or jes2 networking http://www.garlic.com/~lynn/subtopic.html#hasp at some point ... while VM could run native protocol drivers as well as (multiple different) JES2 drivers ... JES2 could only run a specific JES2 drivers ... it was decided to start shipping VM only with JES2 drivers (even tho the native VM protocol drivers were more efficient). this was seen in the bitnet deployment http://www.garlic.com/~lynn/subnetwork.html#bitnet the vm tcp/ip product was developed in vs/pascal ... originally adapted from pascal compiler developed in the los gatos lab for developing (mostly vm/cms based) vlsi tools. there were some thruput issues with the vm implementation getting only about 44kbyte/sec thruput using nearly 3090 processor. i then did the rfc 1044 implementation and in some tuning tests at cray research between cray and 4341-clone, got 1mbyte/sec thruput (4341 channel media thruput) using only a modest amount of the 4341 processor. http:/www.garlic.com/~lynn/subnetwork.html#1044 the base vm implementation was "ported" to mvs by doing a vm diagnose implementation for mvs. later there was a vtam-based tcp/ip implementation done by a subcontractor. the folklore is that the initial implementation had tcp thruput significantly faster than lu6.2. the subcontractor was then told that everybody knows that lu6.2 is faster than tcp/ip and the only way that tcp/ip would be faster is if it was an incorrect implementation ... and only a "correct" implementation was acceptable. for some totally other drift ... early on, i wanted to show that rex(x) was not just another pretty exec. i undertook to do a replacement for the kernel dump analyser ... ipcs, which was mostly a large assembler program. i wanted to demonstrate that in half-time over three month period, i could re-implement ipcs in rex(x) with ten times the function as well as ten times faster than the assembler implementation. http://www.garlic.com/~lynn/subtopic.html#dumprx this was eventually in use at nearly all internal installations, although never released to customers. other post/references to os/vs2 picking up cp67 technology for transition from mvt to virtal memory environment: http://www.garlic.com/~lynn/2007p.html#69 GETMAIN/FREEMAIN and virtual storage backing up http://www.garlic.com/~lynn/2007p.html#70 GETMAIN/FREEMAIN and virtual storage backing up http://www.garlic.com/~lynn/2007p.html#74 GETMAIN/FREEMAIN and virtual storage backing up http://www.garlic.com/~lynn/2007q.html#8 GETMAIN/FREEMAIN and virtual storage backing up http://www.garlic.com/~lynn/2007r.html#56 CSA 'above the bar' http://www.garlic.com/~lynn/2007r.html#64 CSA 'above the bar' http://www.garlic.com/~lynn/2007r.html#65 CSA 'above the bar' http://www.garlic.com/~lynn/2007s.html#2 Real storage usage - a quick question http://www.garlic.com/~lynn/2007s.html#41 Age of IBM VM ---------------------------------------------------------------------- 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
