John A Pershing Jr <persh...@alum.mit.edu> writes: > Lynn clearly meant to say "one of the internal networks": specifically, > VNET which mostly connected the various VM systems. There were several > other internal networks (e.g., HONE) which were all SNA-based.
re: http://www.garlic.com/~lynn/2009l.html#13 SNA: conflicting opinions http://www.garlic.com/~lynn/2009l.html#15 SNA: conflicting opinions http://www.garlic.com/~lynn/2009l.html#17 SNA: conflicting opinions or maybe the "internal network" was a reference to a "computer network" ... as opposed to "terminal network". misc. past posts mentioning "internal network". http://www.garlic.com/~lynn/subnetwork.html#internalnet there was CCDN, which was a corporate terminal front-end ... that allowed branch office (and other) terminals to interconnect to a number of internal online services. HONE had a front-end CCDN box ... but there a number of other online services that also had CCDN front-end terminal connectivity ... like RETAIN (CCDN provided the terminal networking overlaying the SNA terminal communication). HONE started out as some number of internal virtual machine cp67 datacenters that would provide the ability for SEs in the branch office to play with operating systems. This was after then 23jun69 unbundling announcement ... which included starting to charge for SE time ... which shutoff one of the major avenue for branch office skill maintenance ("hands-on" at customer location). When initial 370 was announced (before virtual memory announcement), there were a few new instructions. HONE CP67 systems got add-ons that simulated the new instructions so "370" operating systems could be run in cp67 virtual machines (on 360/67). The science center had also done port of apl\360 to cp67/cms for cms\apl. HONE started deploying some number of APL-based sales & marketing support applications. Eventually the sales & marketing support came to dominate all HONE use and the virtual machine for SEs activity withered away. One of my hobbies during the 70s and part of the 80s was providing HONE with highly customized operating system kernels (periodically dropping by and resolving problems/bugs, etc). misc. past posts mentioning HONE http://www.garlic.com/~lynn/subtopic.html#hone misc. old email mentioning HONE (also some referencing HONE on VNET computer network ... as opposed to terminal network) http://www.garlic.com/~lynn/lhwemail.html#hone in the mid-70s the US HONE datacenters were consolidated in single location ... and the HONE vm370 got a lot of enhancements for single-system-image ... a large collection of (eventually multiprocessor) machines sharing a common large disk farm. The science center had done a lot of activity on performance tuning, workload profiling, performance simulation (eventually evolving into capacity planning). One of these was made available on HONE as the "performance predictor" ... branch office could characterize customer (mainframe) configuration & workload ... and then ask what-if questions regarding changes to hardware or workload. misc. past posts mentioning science center http://www.garlic.com/~lynn/subtopic.html#545tech In any case, a modified version of the "performance predictor" was created that monitored workload & availability of individual systems and interacted with local CCDN terminal front-end ... to route incoming terminal sessions to specific system (providing workload balancing and availability). for the fun of it ... somebody in YKT had done a "virtual terminal" enhancement to vm370 ... which allowed a virtual machine process that created virtual 3270s ... that could simulated on the local machine or carried over communication lines to other machines. This was released as product called PVM. RLSS provided a gateway into CCDN. there was an internal CMS application that could make use of virtual terminal interface ... which also included a HLLAPI-like language (well before PC and PC-based terminal emulation). In any case, it was then possible to write scripts that went into RETAIN to retrieve PUT bucket info. old post with bits & pieces of PARASITE & STORY http://www.garlic.com/~lynn/2001k.html#35 old post with a RETAIN "story" (i.e. script to to connect thru various internal terminal communication systems, login in to RETAIN, retrieve information, log-off, etc http://www.garlic.com/~lynn/2001k.html#36 at the time of APPN announce ... both the person responsible for APPN and I reported directly to the same executive (this was after Andy went to AWD, prior to that I was direct report to Andy). from long ago and far away (after having moved to AWD) ... Date: Thu, 1 Sep 88 10:01:48 est From: wheeler Subject: sna networking if you are interested i can send you a overview of a system that would allow sna networks to have full-blown appn superset but back in '85 ... only it wasn't done by cpd ... but by a very good customer of ibm. after i made the presentation to the sna architecture reveiw board ... their response was to start a task-force on how to make pu5 so difficult and obtuse, that nobody would ever think of attempting such a thing again. cpd even nonconcurred with appn and refused to sign-off on the announcement. The comprimise that was reached with cpd a week before appn announcement was that there would be nothing in the announcement information that in any way associated appn with sna (it has only been relatively recently that cpd has been brought around to letting the term sna be in any way associated with appn). however, that is somewhat orthoganal. the unix industry standard is ip and we need to provide the best world class ip support in existance if we are to ship a unix product. after that, given that we also wish to satisfy customer requirements for some ibm mainframe connectivity ... we also need to have sna support (although even there, ibm mainframe offerings of ip for the technical unix market are coming on very fast). ---------- Words of wisdom from Zippy: I'm ZIPPY the PINHEAD and I'm totally committed to the festive mode. ... snip ... as mentioned in http://www.garlic.com/~lynn/2009l.html#17 SNA: conflicting opinions I had added rfc1044 support to mainframe tcpip support ... getting something like factor of thousand times improvement in the bytes moved per instruction executed ... misc. past posts mentioning 1044 support http://www.garlic.com/~lynn/subnetwork.html#1044 -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
