Re: Newbie question on table design.

On Sun, 06 May 2007 15:59:14 -0600 in alt.folklore.computers, Anne & Lynn Wheeler <lynn_at_garlic.com> wrote:

>
>Anne & Lynn Wheeler <lynn_at_garlic.com> writes:
>> one of the things that started to show up with interactive computing
>> was games. in the 70s, tymshare had ported the adventure dec fortran
>> source to vm/cms and i obtained a copy for internal corporate
>> distribution. at one point, the executives in STL complained that they
>> thot nearly everybody was spending their days playing adventure on
>> vm/cms (instead of doing dbms development). recent post mentioning
>> adventure:
>> http://www.garlic.com/~lynn/2007g.html#0 10 worst PCs
>
>re:
>http://www.garlic.com/~lynn/2007j.html#17 Newbie question on table design
>
>STL (south san jose, dbms and language development, subseqently renamed
>the silicon valley lab) and Hursley (UK, communication and cics
>development) looked at off-shift dataprocessing offloading in 1980. The
>dominant development platform at both locations was vm/cms interactive
>computing. like in the reference to palo alto vm/cms this sort of
>interactive workload tends to be running at full capacity during first
>shift with much lower off-shift use.
>http://www.garlic.com/~lynn/2007j.html#13 Interrupts
>
>the strategy was to get a "high-bandwidth" double-hop satellite link
>between STL and Hursley (i.e. from west coast up to the geo-sync
>satellite over the US, down to the east coast, up again to geo-sync
>satellite over the atlantic and down to Hursley). Since there was 8hr
>time-difference ... some of the 1st shift Hursley workload could be run
>on the STL machines (being 3rd shift in california) and some of the 1st
>shift STL workload could be run on Hursley machines (being 2nd shift in
>UK).
>
>This was going to be showcase operation ... so some of the strategy
>people stepped in to "force" the link to operate with MVS JES2/SNA (even
>tho the dominate operation was vm/cms which didn't use SNA for network
>links).
>
>They tried to bring up JES2/SNA on the link ... and nothing happened.
>Somebody then suggested to try it with VM link just to check things out
>... and it came up with no errors. They immediately switched back to
>JES2/SNA on the link and nothing happened. The "official" conclusion was
>that there was significant transmission errors on the double-hop
>satellite link and VM link error handling was too primitive to recognize
>the problems. The actual situation was that the JES2/SNA had built in
>round-trip timeout ... which the round-trip double-hop satellite
>propogation delay was exceeding (and which they couldn't "fix") ... but
>the VM link support did adjust for the round-trip (double-hop satellite)
>propogation delay.

PPoE wanted cheaper MVS rates than major US corporate datacentres offered, negotiated same with UK corporate datacentre, but also wanted similar VMS connectivity for some reason, and had problems with thruput and various bandwidth sharing methods, so setup trunked dual 128Kbps TCP/IP links between datacentres, and tunnelled SNA over TCP/IP, getting over 90% SNA bandwidth after some consultation down south, patching TCP/IP and tweaking TCP/IP and SNA link parameters.

-- 
Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada

Brian.Inglis_at_CSi.com 	(Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
    fake address		use address above to reply