2004 Newsgroup postings (01/01 - 01/28) Lynn Wheeler

2004 Newsgroup Postings (01/01 - 01/28)

comp.arch classic: the 10-bit byte
Saturation Design Point
The BASIC Variations
The BASIC Variations
TSS/370 source archive now available
The BASIC Variations
The BASIC Variations
Dyadic
virtual-machine theory
Dyadic
Dyadic
Dyadic
virtual-machine theory
Holee shit! 30 years ago!
Holee shit! 30 years ago!
Holee shit! 30 years ago!
Holee shit! 30 years ago!
Holee shit! 30 years ago!
virtual-machine theory
virtual-machine theory
BASIC Language History?
40th anniversary of IBM System/360 on 7 Apr 2004
40th anniversary of IBM System/360 on 7 Apr 2004
Holee shit! 30 years ago!
40th anniversary of IBM System/360 on 7 Apr 2004
40th anniversary of IBM System/360 on 7 Apr 2004
40th anniversary of IBM System/360 on 7 Apr 2004
dual processors: not just for breakfast anymore?
Two subjects: 64-bit OS2/eCs, Innotek Products
passwords
Threat of running a web server?
Two subjects: 64-bit OS2/eCs, Innotek Products
BASIC Language History?
passwords
Two subjects: 64-bit OS2/eCs, Innotek Products
40th anniversary of IBM System/360 on 7 Apr 2004
merged security taxonomy & glossary
When rsa vs dsa
When rsa vs dsa
AMD/Linux vs Intel/Microsoft
AMD/Linux vs Intel/Microsoft
AMD/Linux vs Intel/Microsoft
40th anniversary of IBM System/360 on 7 Apr 2004
[Fwd: Re: Mainframe not a good architecture for interactive w
OT The First Mouse
40th anniversary of IBM System/360 on 7 Apr 2004
DE-skilling was Re: ServerPak Install via QuickLoad Product
Mainframe not a good architecture for interactive workloads
AMD/Linux vs Intel/Microsoft
Mainframe not a good architecture for interactive workloads
Mainframe not a good architecture for interactive workloads
Mainframe not a good architecture for interactive workloads
AMD/Linux vs Intel/Microsoft
Mainframe not a good architecture for interactive workloads

comp.arch classic: the 10-bit byte

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: comp.arch classic: the 10-bit byte
Newsgroups: comp.arch
Date: Thu, 01 Jan 2004 14:29:57 GMT

"Stephen Fuld" writes:
Yeah, I guess so. Still tens of usec seems a long time to have interrupts disabled. But the tradeoff versus doing all the work of a full I/O was probably worth it. On the other hand, the only reason this was needed at all was due to that cardinal mistake of computer architecture, not allowing enough address bits. :-(

I was told that it was because of physical packaging ... not number of addressing bits .... it was going to have to be NUMA of some kind; aka the additional memory was going to have to be physically packaged where there was going to have to be increased latency to physically reach the additional memory. going to explicit different kind of access allowed more latitude in amount of data transferred in an access and streaming of the access ... as partial delay propagation compensation.

slight drift, there was earlier instance of 3033 which had a hack where the size of physical memory addressing (26bits) was larger than logical memory addressing (24bits) by going to more bits in page table entry.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Saturation Design Point

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Saturation Design Point
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 02 Jan 2004 14:09:01 GMT

jmfbahciv writes:
It was a way to mark and name when the event of sweeping the cache (thus updating memory) was done. Caution: I'm going to use TOPS-10 terminology here so our meanings may get jumbled.

Let's say Job 2 ran on CPU1 and wrote some stuff to a memory buffer assigned to a disk output file buffer ring. The job goes into I/O wait so CPU1 puts the job on a queue and picks another job to run. Meanwhile, CPU0 runs out of things to do, finds that Job 2 needs attention (CPU0 has a hard wire to the channel/disk that Job 2 needs. So it picks Job 2 to run. Job 2's output buffer in memory may not have the newly written data because CPU0 picked Job 2 to run before CPU1 flushed its cache. CPU0 believes that memory is good and had no way to know if CPU1 had done its business or not. It was also a design of SMP (the S in symmetric) that one CPU cannot be put in wait for another CPU. <shudder> Deadlocks and deadly embraces would be just the icing on that cake of worms.

Byte pointers were a common word of memory that could be incorrect. One of the words in the buffer headers was the byte pointer to the current buffer to be filled/emptied.

370s & later had store-thru caches.

rios had store-in cache and no provision for cache coherency .... and was perceived to not be multiprocessor system; it was one of the reasons we did ha/cmp for scale-up although we had worked on smp in the past (and were particpating in some sci standards stuff).

there was a sort of 4-way smp rios using rios.9 chips ... which had the convention that a segment table could be flagged where it wouldn't cache the data.

it wasn't until power/pc that there was provisions made for cache cohenency and real multprocessor operation.

random hacmp stuff:
https://www.garlic.com/~lynn/subtopic.html#hacmp

random smp stuff:
https://www.garlic.com/~lynn/subtopic.html#smp

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

The BASIC Variations

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The BASIC Variations
Newsgroups: alt.folklore.computers
Date: Sat, 03 Jan 2004 18:32:20 GMT

"J.Clarke" writes:
I dunno--you got me puzzled now--I'm sure you're remembering _something_ right but I don't recall what. Perhaps you're thinking of when they brought in McNamara (the uber-PHB) and his "whiz kids" (mini-PHBs) and started running the DoD on the basis of "cost effectiveness", with the results being painfully obvious to the soldiers on the ground in Vietnam. The appalling part of it was that he was kept in office for 8 years instead of having his butt fired when it became clear that his approach was costing lives and gaining nothing. FWIW, McNamara apologized for this a few years ago--the countless men who lost friends, health, or just years of their lives in Vietnam however do not seem to be in any hurry to forgive him. I would be interested in knowing what General Giap thought of his book and his apology. Unfortunately I lost touch with my Viet Cong friend (4'2, so smart she's almost scary, stunningly beautiful even in her late '40s, sweetest person you'd ever care to meet, bakes a mean cookie, happily married alas, but _do__not__mess__with__her_) before McNamara's book came out, so can't get her opinion, and have no idea how to contact Giap.

slightly related:
https://www.garlic.com/~lynn/99.html#120 atomic History

and
https://www.garlic.com/~lynn/subboyd.html#boyd

one of the biographies has a chapter on the year he spent running one of the largest datacenters around ... and definitly the largest in the far east.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

The BASIC Variations

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The BASIC Variations
Newsgroups: comp.lang.basic.misc,alt.lang.basic,alt.folklore.computers
Date: Sun, 04 Jan 2004 18:41:07 GMT

erewhon@nowhere.com (J French) writes:
That sort of fault tolerance sounds pretty impressive - I did not realize it was present in the early(ish) DECs - Tandem comes to mind .. as does the early RAID stuff

TL brought up an interesting point - hardware failure can bring down the whole house of cards

- OTOH the 'house of cards' would probably not exist without computerization

I sometimes wonder how long people would last if the water supply was shut off - technology increases vulnerability (?)

technology frequently tends to reduce redundancy ... fewer spare resources needed for the general case because of things like delivery optimization (more and more just in time stuff). the other aspect is the ability to support higher level of service w/o increasing the resources needed to provide the service. this in turn, reduces the cost of providing the service ... since higher level of activity is provided w/o increasing the amount of resources.

however, highly leveraged systems can be prone to severe degradation with only minior disruption; one example might be the chicago airport example discussed recently.
https://www.garlic.com/~lynn/2003o.html#27 When nerds were nerds
https://www.garlic.com/~lynn/2003o.html#33 When nerds were nerds
https://www.garlic.com/~lynn/2003o.html#38 When nerds were nerds
https://www.garlic.com/~lynn/2003o.html#41 When nerds were nerds

complex infrastructure of any kind (not necessarily technology) frequently increases vulnerability ... in part because the complexity itself can lend to failures occurring in unanticipated ways.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

TSS/370 source archive now available

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSS/370 source archive now available
Newsgroups: bit.listserv.ibm-main
Date: Mon, 05 Jan 2004 03:21:32 GMT

mainframedave@ibm-main.sbcglobal.net (David Alcock) writes:
I've always wondered what VSPC looked like. I see that a college has this definition for VSPC:

Virtual Storage Personal Computing - A general purpose, interactive time-sharing system formerly used on UNM's mainframe computers and superceded by MUSIC.

I used MUSIC in college.

vspc ... was originally named pco ... personal computing option (possibly chosen as a variation on tso?) but it turned out that "pco" was already in use in europe ... so it was decided that a name change was needed. misc past pco/vspc refs:
https://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
https://www.garlic.com/~lynn/2002h.html#51 Why did OSI fail compared with TCP-IP?
https://www.garlic.com/~lynn/2002q.html#26 LISTSERV Discussion List For USS Questions?
https://www.garlic.com/~lynn/2003k.html#0 VSPC

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

The BASIC Variations

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The BASIC Variations
Newsgroups: comp.lang.basic.misc,alt.folklore.computers
Date: Mon, 05 Jan 2004 03:45:48 GMT

"Bill Leary" writes:
It was actually sort of n odd thing to go to the VAX, open it up and install a new microcode disk (or diskette) in the PDP. I'd gotten so fixed on the idea the 8" and 5.25" floppies were PC-only things.

references to shugart inventing the diskette for distributing/loading microcode .... 1971 microcode load for system/370s and for 3830 disk controllers (i.e. 3830 controller for 3330/merlin disk drives).

random shugart/diskette refs from search engine:
http://www.cnn.com/TECH/computing/9907/08/1971.idg/index.html
http://www.accurite.com/FloppyPrimer.html
http://inventors.about.com/library/weekly/aa110198.htm
http://www.oldcomputers.net/trs80ii.html
http://www.newton.mec.edu/brown/TE/HOT/STUDENTS/BARGAR/timeline.html
http://www.miami.com/mld/miamiherald/5387554.htm
http://history.acusd.edu/gen/recording/mag/p44.html
http://www.canoe.ca/TechNews0009/27_gazin.html
http://www.feb-patrimoine.com/Histoire/english/information_technology/information_technology_4.htm
http://www.sal.ksu.edu/faculty/gregs/hist231/portfolios/comphistory/components.htm

this mentions shugart having done the 2321 ... and several other projects including the diskette
http://www.columbia.edu/cu/computinghistory/datacell.html

random 360/370 microcode refs::
https://www.garlic.com/~lynn/submain.html#360mcode

random past merlin refs:
https://www.garlic.com/~lynn/2001l.html#53 mainframe question
https://www.garlic.com/~lynn/2001l.html#63 MVS History (all parts)
https://www.garlic.com/~lynn/2002.html#17 index searching
https://www.garlic.com/~lynn/2002o.html#3 PLX
https://www.garlic.com/~lynn/2003b.html#7 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003c.html#54 "average" DASD Blocksize

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

The BASIC Variations

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The BASIC Variations
Newsgroups: comp.lang.basic.misc,alt.folklore.computers
Date: Mon, 05 Jan 2004 19:04:38 GMT

Keith R. Williams writes:
In IBM these (and there may have been four heads per track) were known as "fixed head disks" or perhaps "drums", even though they were disks. These were normally used for paging store.

there was 2303 and 2301 fixed-head "drums" for the 360 (small spinning barrel with tracks on the outside). The 2301 read/wrote four heads in parallel for four times the data transfer rate of the 2303.

later in the 370 time-frame there was 2305-1 & 2305-2 fixed head disk. one of them had half the capacity because half the heads were off-set 180 degrees on paired tracks. there were half as many tracks but the same number of heads. avg. latency was based on rotation only needing to make half revolution maximum to get a record under a head.

one of the reasons/justifications for the term DASD (direct access storage device) was because there were a number of technologies in the 60s, some things like the 2321 datacell. drums predated disks by quite a bit (and a number of vendors eventually had them).

early post in part of this thread has pointer to 2321 reference, somewhat in conjunction with diskette history:
https://www.garlic.com/~lynn/2004.html#5 The BASIC variations
another 2321 reference:
http://members.optushome.com.au/intaretro/2321DCD.htm

misc. dasd/drum search engine ref
http://www.computerworld.com/hardwaretopics/storage/story/0,10801,75215,00.html

the following
http://www.beagle-ears.com/lars/engineer/comphist/ibm_nos.htm
mentions that main memory for 650 computer was rotating drum (1953) and the 733 was 8192 word magnetic drum

other 650 references:
http://www-1.ibm.com/ibm/history/exhibits/650/650_ph09.html
http://www.mta.ca/~amiller/ibm650/ibm650.htm
http://www.columbia.edu/cu/computinghistory/650.html
http://www.cedmagic.com/history/ibm-650-drum.html
http://portal.acm.org/citation.cfm?doid=320764.320768

a couple 733 references
http://www-1.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP704.html
http://www-1.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP709.html

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Dyadic

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dyadic
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 05 Jan 2004 19:39:49 GMT

Kees.Vernooy@ibm-main.klm.com (Vernooy, C.P. - SPLXM) writes:
The 3081 was explained to us as a two-headed monster, hence dyadic, with two equal, full functional heads (processors) on one body. The former machines (303x series) had 1 full function head and could have added an extra one (a so called Attached Processor), but with limited funtionality, no I/O etc.

Its power was explained by comparing it to a hammer: if you want to hammer nails more quickly, you could beat faster, use a heavier hammer etc, until the 308x period. Then you head a hammer with 2 (3081) of 4 (3084) heads, so you could nail 2 or 4 times as much nails than before, with the same action.

360/65 had full duplex smp. it was two completely independent processor complexes that could be either both operate totally independently or combined to share memory and operate as a two processer symmetric multiprocessor. however, the channel configurations weren't integrated so both processors continued to have (only) their locally attached I/O configuration. to allow both processers access to a common set of devices, the device I/O controllers were typically configured with twin tails; each one connected to a channel attached to each processor.

the 360/67 was more sophisticated design and had a channel controller that allowed integration of all channels available to all processors. 360/67 had provisions for reading the setting of the channel controller switches in control registers (which also provided for configuring memory banks). the 360/67 was originally designed to support up to four processor configurations but except for one triplex, i believe only two-processor configurations were actually built. The triplex was somewhat unique in that not only could the settings of the channel controller switches be read with the control registers ... but it was also possible to modify the channel controller switches by changing bits in the control registers. note also that the 360/67 support both 24-bit and 32-bit virtual addressing (32-bit not 31-bit).

a lot of work on 360/67 smp at cambridge science center
https://www.garlic.com/~lynn/subtopic.html#545tech
resulted in the smp compare and swap instruction that shows up on 370 (CAS are the initials of the person at cambridge responsible for the compare and swap instruction invention). lots of past smp references
https://www.garlic.com/~lynn/subtopic.html#smp

as special, custom hardware there were also the 9020 machines for the FAA air traffic control system (modified 360/50s).

the 370/158 & 370/168 implementation regressed to the 360/65 smp implementation ... two independent hardware configurations that could have their memory combined ... but retained their private, independent, non-integrated channel connections (and could be divided and run as two completely independent uniprocessor). none of the advance features found in the 360/67 multiprocessor made it into 370 (as well as only 24bit virtual addressing).

370/158 and 370/168 were also available in multiprocessor configurations where only a single processor had attached I/O channels. This was what was referred to as attached processor configuration.

The 3081 was designed as a fully functional two processor configuration but w/o the additional hardware necessary to operate as two completely independent uniprocessors (power supplies, connectors, etc). It also started to show some of the more advanced features that had been implemented in the 360/67 like having more than 24-bit virtual addressing and allowing all processors to access all channels. However, it didn't have the extended ras and configurability capability that was implemented in the 360/67 triplex channel controller. There was never orignally intended to be a 3083 ... but I believe it was finally produced for the TPF/ACP market place (at the time, TPF/ACP didn't yet have support for multiprocessor operation).

following has some of the control register bit definitions from the 360/67 blue card:
https://www.garlic.com/~lynn/2001.html#69 what is interrupt mask register?
https://www.garlic.com/~lynn/2001.html#71 what is interrupt mask register?
https://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)
https://www.garlic.com/~lynn/2001l.html#24 mainframe question

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

virtual-machine theory

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: virtual-machine theory
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 07 Jan 2004 14:49:26 GMT

glen herrmannsfeldt writes:
Well, I think it is usual to exclude timing related tests, though the Principles of Operations doesn't guarantee timing, anyway.

from POP standpoint, timing issues would have been model dependent as well as execution of diagnose instruction. pop specified conformance across wide range of hardware implementations and performance (microcoded and hardwired).

even within same model ... things like integrated channels and/or controllers would have some amount of variance because of various cycle stealing issues i.e. the same hardware engine was shared between microcode that implemented "mainframe" insturctions and microcode that implemented channels and/or controller functions.

simple example is that 3031 is effectively identical hardware as 158. however for the 303x processors, a 158 hardware engine was split off and dedicated to channel director ... implementing just the channel function.

a 370/158 was a single hardware engine that was shared between executing 370 microcode program and channel microcode program. A 3031 had a dedicated (158) engine for just the 370 microcode and a second (158) engine for executing the channel microcode.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Dyadic

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dyadic
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 07 Jan 2004 15:00:48 GMT

IBM-MAIN@ibm-main.isham-research.com (Phil Payne) writes:
The 3033 was not in any way a stopgap system. An awful lot of design went into it. The 3032 was never a major success, and by the end of the 303x era IBM had announced the 3033N and 3033S in their respective spaces. The 3033S was a silly machine - it was the physical size of a 3033 but only had a 512B (there's no K missing) cache. If you wrote a synthetic instruction loop that would fit in 512 bytes, it was as fast as a 3033U. I lost a benchmark at the Finanzamt Charlottenburg that way and now have a life-long hatred of synthetic kernels. IBM upped the buffer to 1KB at one point.

303x had 158 engine dedicated as channel director.

3031 was effectively a 158 repackaged with 158 engine dedicated to 370 microcode and a second 158 engine dedicated to channel microcode (370/158 shared the same 158 engine for both 370 microcode and channel microcode).

3032 was effecitvely a 168 repackaged to use 303x channel director

3033 started out as 168 wiring design remapped to faster chip technology that was something like 20 percent faster than the 168 chip technology (which would have made 3033 about 20 percent faster than 168). late in the 3033 design, there was some competitive pressure to make it close to 50 percent faster than 168. the 168 chip technology had four circuits per chip ... the 3033 chip technology in addition to being about 20 percent faster also had something like 40 circuits per chip ... but initially was only going to utilize the 168 wiring design using four circuits per chip. The late, aggresive performance upgrade looked at redesigning critical portions of the processor, including leveraging more circuits per chip and additional performance of intra-chip operation.

there was comments that after 370 there were two parallel efforts ... offset in time ... the 3033 being effort of the 168 group, the 3081 being effort of the 158 group, and the 3090 being effort of the 168 group

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Dyadic

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dyadic
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 07 Jan 2004 16:48:52 GMT

dba@ibm-main.lists.duda.com (David Andrews) writes:
Perhaps we're at odds with the characterization: "repackaged" is different from "recycled". My interpretation is that the directors were new equipment, but not new designs.

Someone told me once that the service processor on the 3081 was a reworked 8100 -- but I never dreamed it was an actual returned 8100. As I mentioned earlier, American tax law at the time would have made this problematic.

I had heard that the 8100 used a uc.5 microprocessor and the service processor in the 3081 was a uc.5 microprocessor (i.e. the 3081 wasn't an 8100 ... but the service processing in the 3081 used the same hardware engine as was used in the 8100).

303x channel directors were 158 engines with just the integrated channel microcode and the 370 microcode stripped out. a 3031 was a pair of 158 engines ... one engine dedicated to 370 microcode and one engine (channel director) dedicated to integrated channel microcode (while a 370/158 engine had the same engine sharing the two sets of microcode, 370 microcode and integrated channel microcode).

i was once told that the incremental manufacturing cost of each additional 158 engine was similar to highly automated car manufacturing (i.e. not including NRE, up-front design, plant construction, line construction & setup, etc).

the 3090 started out having a service processor that was a 4331 running a customized version of vm/370 release 6 ... with all the service panels implemented in cms ... and evolved into a pair of 4361s running customized version of vm/370 release 6)

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Dyadic

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dyadic
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 08 Jan 2004 14:35:47 GMT

Keith R. Williams writes:
The ES9000 used a PS/2 running OS/2 as its service processor. I believe the 'z' systems use a ThinkPad.

note that the service processor has lots of probes/connectors into all parts of the machine to run the diagnostics necessary to do service. the service processor also interfaced to a lot of other parts of the machine; aka it wasn't just the keyboard/display interface.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

virtual-machine theory

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: virtual-machine theory
Newsgroups: alt.folklore.computers
Date: Tue, 13 Jan 2004 21:29:42 GMT

dpeschel@eskimo.com (Derek Peschel) writes:
So the 68000 allows any program to tell whether it's in supervisor mode or not. And presumably the supervisor/user mode is related to the virtual/real mode, so you have a program that can tell if it's running virtually, which is bad.

But is that the whole answer? I can imagine a VM executive running in supervisor mode running a guest also in supervisor mode. So the relation between the two modes could be weak, _if_ you make sure that the host always controls all aspects of the guest CPU. Do the 68010 and later promise that? For example, do they trap attempts to read the SR and let the executive determine the guest's SR?

we had a guest (370) operating system
running under a vm executive providing 370 virtual machines running under a vm executive providing 370 virtual machines running under a vm executive providing 360/67 virtual machines running on a microcded 360/67

the issue was that the generalized vm executive provided public access time-sharing at same time doing a joint project with endicott on 370 operating systems before 370 virtual memory was announced.

the "2nd level" vm executive believe it was running on 360/67 architecture but provided 370 virtual machines (which had some number of architecture differences from 360/67 virtual machines).

the "3rd level" vm executive believed it was running on 370 architecture and provied 370 virtual machines.

the top level was a guest operating system that believe it was running (on unannounced) 370 real machine.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Holee shit! 30 years ago!

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Holee shit!  30 years ago!
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Tue, 13 Jan 2004 23:24:16 GMT

cstacy@news.dtpq.com (Christopher C. Stacy) writes:
When the page goes from memory to disk, the page is "swapped out". Are you trying to ask what's it called when you "remove" a page from core (because it's no longer part of the working set, and you want that core for the free list or something), but it's not dirty? I don't think there's a special name for that -- one would just say we are "invalidating the page map entry" or "freeing a page".

i actually had big argument with the original VS2/SVS on the dirty page issue. basically the idea was to implement an approximation to LRU; however the performance modeling group in POK came up with a hack on LRU approximation that would select non-changed pages before changed pages .... because there was much less work stealing non-changed pages (which didn't have to be written out before they were scavenaged). they continued this page replacement strategy well into MVS before they came to the conclusion that "stealing" high-use, shared-program (linkpack) pages before they were stealing low-use, private, modified data pages ... wasn't all that good an idea.

that later changed with the big page strategy introduced with 3380s ... since when a big page was brought into memory ... all the disk records were de-allocated. With no saved copy of a page on disk, *all* stolen (replaced) pages had to be (re)written ... whether or not they had been changed during the most recent stay in memory (when there was no previously saved image of a page on disk, removing it from memory, forced a write).

misc. discussion on page replacement, working set, etc:
https://www.garlic.com/~lynn/subtopic.html#wsclock

rather recent discussion of big pages (comp.arch) ... along with lots of references to past big page discussions:
https://www.garlic.com/~lynn/2003o.html#61 1teraflops cell processor possible?

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Holee shit! 30 years ago!

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Holee shit!  30 years ago!
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Thu, 15 Jan 2004 01:04:07 GMT

Brian Inglis writes:
Instead, like Java, the program goes away and garbage collects at random intervals, when its filled the whole address space with junk. The users really love unpredictable response time: it was bad enough when systems were slower but programs had small address spaces (like 64KB). IMHO one reason why languages with garbage collection were never widely used for user programs. This generation has just jumped on the bandwagon and is going to learn the hard way why it never became popular. Whatever happened to all the research and implementations of nice incremental garbage collector algorithms developed in the 1970s to replace the nasty bulk mark and sweep (pronounced Markt und Sveep!) algorithms that trash virtual memory?

that was done as part of porting apl\360 to cms\apl in the early 70s (30 plus years ago) i.e. instead of swapping 16k workspaces that you might get with apl\360 ... cms\apl had available the virtual address space.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Holee shit! 30 years ago!

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Holee shit!  30 years ago!
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Thu, 15 Jan 2004 01:21:29 GMT

"Shmuel (Seymour J.) Metz" writes:
Motorola had a separate MMU chip for the 68000 line; I don't recall whether it was for the 68010 or the 68020. At some point the functionality became part of the processor chip. I don't recall wher National Semiconductor or Zylog had an MMU. IBM's RS/6000 and POWER chip had paging. I believe that the Intel and Motorola RISC chips also supported paging.

rs/6000 was rios ... precursor to rios was romp that showed up in pc/rt (although it was originally going to be used for displaywriter follow-on); misc. 801, romp, rios, etc refs:
https://www.garlic.com/~lynn/subtopic.html#801

great microprocessors of the past and present:
http://www3.sk.sympatico.ca/jbayko/cpu.html

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Holee shit! 30 years ago!

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Holee shit!  30 years ago!
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Thu, 15 Jan 2004 01:26:14 GMT

glen herrmannsfeldt writes:
MVT had ROLLIN/ROLLOUT. As there was no DAT, once a program was loaded it was fixed in memory. If a program needed to expand, it was possible for MVT to ROLLOUT whatever was in the needed addresses, and later ROLLIN again.

nasa huntsville and brown(?) did modified MVT (os/360 release 13) with DAT support on 360/67 (over 35 years ago). it didn't do paging thougth; it used the DAT to address severe memory fragmentation problem with long running 2250 interactive jobs.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Holee shit! 30 years ago!

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Holee shit!  30 years ago!
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Thu, 15 Jan 2004 01:38:31 GMT

Peter Flass writes:
There are three possibilities here. 1) Large virtual address space mapped to possibly smaller physical memory. This is the current standard, e.g. IA32 in 32-bit mode, IBM z/Architecture, etc. 2. Address space = physical memory. Example - IBM OS/360 where multiple "jobs" shared a common "address space", although it wasn't called that. This is the usual case on a system without relocation hardware, but with memory protection. 3. Address space smaller than physical memory. This is the usual case on systems with relocation hardware but no paging.

the 360/67 had both 24bit and 32bit virtual addressing options.

move to 370 ... resulted in only 24bits virtual and logical being supported (31bit virtual addressing didn't re-appear to ten years later with 3081/XA).

the 3033 had something of a blip tho. virtual and logical was still 24bits ... but large systems were becoming real storage constrained. 3033 had a hack where they were able to take two unused bits in the page table entry and "address" 14bits worth of 4k real pages. The standard 370 architecture had 16bit page table entry, 12bits for page numbers (12bit page numbers times 4k/12bit pages ... 24bits real addressing), 2 additional defined bits, and 2 undefined bits.

the hack with the 2 undefined page table bits allowed for addressing 14bits worth of 4k real pages (64mbytes). fortunately, I/O architecture CCWs already had IDALs which allowed for more than 24bit real address for I/O.

instructions couldn't generate more than 24bit addresses, but IDALs allowed for specifying greater than 24bit real storage addresses for doing I/O .... and the PTE entry stuff allowed for translating 24bit virtual address into a 26bit real storage address.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

virtual-machine theory

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: virtual-machine theory
Newsgroups: alt.folklore.computers
Date: Thu, 15 Jan 2004 01:51:03 GMT

ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
This is extremely perverted. Some people actually have fun when they go to work. PHBs do not approve.

So, was the "guest" MVS? IIRC, MVS could gaze at its navel and determine if it was running under VM or was in charge of the machine.

wasn't mvs .... this was joint project between cambridge and endicott ... and was running "production" a year before the first engineering 370 hardware was running with virtual memory support.

when they finally got the first 370 engineering machine in endicott (this was a full year after all the software stuff mentioned previously had been done and completed) with virtual memory (this machine had a knife switch for an ipl/boot button) ... they used the modified cp/67 (to run on real 370) for a test.

It almost immediately failed. It turned out the engineers had incorrectly reversed the implementation of two of the B2 opcodes. the cp/67 kernel was quickly patched to correspond to the incorrect hardware implementation and from then on it ran fine.

mvs for a while was vs2/mvs .... which was a follow-on to vs2/svs (aka SVS -> single virtual storage; MVS -> multiple virtual storage). basically vs2/svs was somewhat modified MVT that thot it was running in 16mbyte real address space ... and there was underlying kernel stuff to do the paging and virtual memory management. the initial prototype work involved hacking a MVT kernel with the paging stuff running on a 360/67 (before 370 machines with virtual memory was available) ... along with a borrowed copy of CP/67 CCWTRANS module hacked into the MVT kernel. CCWTRANS handled the copying of virtual CCW chains, translating virtual to real address for real I/O, and making sure that the related virtual pages were fixed in real storage for the duration of the i/o operation.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

virtual-machine theory

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: virtual-machine theory
Newsgroups: alt.folklore.computers
Date: Thu, 15 Jan 2004 01:53:03 GMT

Brian Inglis writes:
Nah, MVS always assumed it was the master of any machine it ran on. DOS/VSE and OS/VS1 later versions disabled paging if they were running under a virtual machine (machine serial number model byte x'FF' IIRC).

and VS1 also had handshaking support ... which allowed a psuedo page fault interrupt to be reflected to VS1 when the virtual machine hypervisor took a page fault in the VS1 address space. This allowed VS1 to do task switching and overlap execution while VM was handling the lower level page fault & page-in operation.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

BASIC Language History?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: BASIC Language History?
Newsgroups: alt.folklore.computers
Date: Sat, 17 Jan 2004 16:04:35 GMT

Andrew McLaren <amclar@optusnet.n0$pam.com.au> writes:
The reference Sammet cites ("[KM66]")is the BASIC manual by Kemeny and Kurtz[2]. So it's probably correct :)

I suspect the Sippls just made a small error in expanding the acronym; corrected in a later edition.

BTW the most recent IEEE Annals in the History of Computing had as its theme Women and Computing; and included a reminiscence by Jean Sammet about the early days when she was working with Dr Grace Hopper. Fascinating stuff!

sammet was in the boston programming center on 3rd floor 545 tech sq ... when it was absorbed by the science center & the vm/370 group. boston programming center had done cps (conversational programming system) which included an interactive/conversational pli.

most of the BPC staff were absorbed into the vm/370 group and moved out to burlington mall (old sbc bldg ... before sbc was transferred to cdc) when the vm/370 group outgrew space in tech sq. a few stayed with the science center in tech. sq.

random past 545 tech sq posts
https://www.garlic.com/~lynn/subtopic.html#545tech

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

40th anniversary of IBM System/360 on 7 Apr 2004

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 40th anniversary of IBM System/360 on 7 Apr 2004
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 17 Jan 2004 16:41:35 GMT

WmHBlair@ibm-main.houston.rr.com (William H. Blair) writes:
Actually, they were slower. A 370/195 was about 3.7 MIPS, whereas a 360/91 or 360/95 were neck and neck at 5.0 MIPS. The 95's faster thin-film memory turned out to have no significant effect on the actual processor thruput, a fact noticed by IBM, which contributed to the decision to go back to even slower core memory in the next big machine, the 370/165. The 370/195 was just a 360/91 with the System/370 instruction set (well, most of it, but not all of it); it was the only "/370" that was not completely a 370. It used the slower core memory, as well, mainly because, at $2,000,000 per MB, the fast stuff was just so damn expensive that nobody, even NASA, could afford it. 360/65 and 360/75 core storage was still eye- openingly expensive ($1,000,000 per MB), but few machines existed that had even 512KB. At one point, I worked on a 360/75 that had 1MB (4 2365 boxes) of the fast core storage (four way interleaved to achieve an effective cycle time of less than 200 ns) and 2MB of slow core storage (LCS or Large Capacity Storage), for a total of 3MB. At that time, IBM told us that there were only seven such boxes in the world (with that much memory), and none of them were even in the hands of IBM. NASA Houston had five for the Apollo moon program, TUCC had one, and I think UCLA had the other (at that time).

SJR (bldg. 28) had 370/195 ... and for highly optimized codes that fit in the pipeline it could peak around 10mips. some amount of the air bearing 3380 (floating head) head simulation was being done on that machine .... but with large batch queue there were sometime really extended turn-arounds.

palo alto science center had job that was experiencing 3 month turn arounds (on the sjr 370/195) .... and tried setting it up to run in the background on their 370/145 ... they could get complete run in something like two months instead of the three months it took waiting on the 195. the 370/145 was used for cms interactive work ... but that machine was also where the apl microcode work was done (as well as some amount of other microcode stuff). misc mcode refs:
https://www.garlic.com/~lynn/submain.html#360mcode
and some number of hone &/or apl refs:
https://www.garlic.com/~lynn/subtopic.html#hone
in the late '70s the consolidated US hone center had moved to bldg across the back parking lot from the palo alto science center.

with regard to the air bearing simulation work, we were doing also doing this work to get operating system running on the machines in the disk enginneering (bldg 14) and disk product test (bldg 15, across the street from bldg. 28). at the time, MVS had something like MTBF of 15 minutes when run on a machine with a single testcell in operation (so their standard mode was to schedule stand alone test time for each of the dozen or so testcells). we finally got the rewrite of IOS done so the operating system was rock solid even with multiple testcells operating concurrently.

now the engineering & product test labs tended to get early enginneering processors to validate disk operation (i.e. early 370s, 303x, etc). bldg. 15 got one of the earliest internal 3033s. now one of the characteristics of the testcell operation was that in stand-alone operation it was using much less than one percent of the processor. when we got operating system up and running ... even with half dozen testcells running concurrently, there was only a couple percent cpu utilization. as a result, all of a sudden we had large amounts of cpu sort of unaccounted for and available. so one of the things we thot would be a good idea was to move all the air bearing simulation work off the terribly overloaded 195 (in bldg. 28) to the (effectively) totally idle 3033 (in bldg. 15). misc. disk engineering refs:
https://www.garlic.com/~lynn/subtopic.html#disk

in the early to mid 70s ... there was a project looking at doing a two processor 370/195 ... actually it was much more akin to the dual i-stream hyperthreading stuff currently going on in microprocessors; keep the same pipeline and execution elements ... but have two sets of registers, PSWs, etc. ... and one bit instruction tag for everything in the pipeline ... to identify which instruction stream it belonged to. the issue was there was no speculative execution past a branch instruction (on the 195) ... so branches tended to drain the pipeline (unless they were loop within the pipeline).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

40th anniversary of IBM System/360 on 7 Apr 2004

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 40th anniversary of IBM System/360 on 7 Apr 2004
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 18 Jan 2004 05:14:53 GMT

a quicky use of search engine on 370/195 ... some minor references

references sample program that ran 120 seconds on 360/91 and 20 seconds on 370/195 (and seconds on 1108)
http://www.nea.fr/abs/html/ccc-0179.html

lots of IBM, 360, 370 as well as non-ibm dates, 1964-1974
http://perso.club-internet.fr/febcm/english/information_technology/information_technology_3.htm

list of manuals at charles babbage insitute ... it would be interesting if any ever get scanned and put online
http://www.cbi.umn.edu/collections/inv/cbi00060.html

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Holee shit! 30 years ago!

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Holee shit! 30 years ago!
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Tue, 20 Jan 2004 00:19:05 GMT

"John W. Kennedy" writes:
There's at least one SQL server that does the same with its databases.

An advantage to this is that code can avail itself of knowledge about the disk geometry.

some number of RDBMS had both raw device as well as filesystem options. the issue on unixes wasn't just the disk geometry ... but the whole general issue of things like concurrent & asynchronous i/o (before any such features were generally available on unix platforms). in some scenarios ... unix was used to load the (rdbms) application ... and then it took over the machine and did most of its own management. later posix asynchronous i/o and lightweight threads were supposedly available for being able to accomplish similar results, but using standard system facilities.

this (raw device support) carried over into being able to do concurrent shared disk access for rdbms with ha/cmp .... i.e. unix platforms not having filesystems that supported "loosely-coupled" (aka mainframe for different machines having concurrent/common access to the same set of shared disks).

minor reference
https://www.garlic.com/~lynn/95.html#13
more ha/cmp stuff:
https://www.garlic.com/~lynn/subtopic.html#hacmp

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

40th anniversary of IBM System/360 on 7 Apr 2004

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 40th anniversary of IBM System/360 on 7 Apr 2004
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 20 Jan 2004 00:36:52 GMT

b19141@ibm-main.achilles.ctd.anl.gov (Barry Finkel) writes:
IIRC, Delta (Atlanta) and United (Denver) also had 195's (I am not sure if they were upgraded to 370 from 360). I do not know how many each had. I was told that there were only 24 195's built. Argonne had serial number 17.

the lore is that one of the nails in FS coffin was analysis by the houston science center ... that if ACP was ported from 370/195 to high-end FS machine (built from same 370/195 level technology/performance) it would have the thru-put of 370/145 (aka the FS machine architecture would introduce 10-30 to one performance degradation).

a couple recent posts mentioning FS:
https://www.garlic.com/~lynn/2003p.html#24 Mainframe Training
https://www.garlic.com/~lynn/2003p.html#30 Not A Survey Question

and a whole FS collection:
https://www.garlic.com/~lynn/submain.html#futuresys

and then some number of the FS crowd went off to rochester and implemented FS as the S/38 ... which later morphed into the as/400.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

40th anniversary of IBM System/360 on 7 Apr 2004

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 40th anniversary of IBM System/360 on 7 Apr 2004
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 20 Jan 2004 19:03:23 GMT

broidoj@ibm-main.gti.net (Jeffrey R. Broido) writes:
Yes. The external (to the CPU) memory bus, among other things, was enclosed in a black, partially ribbed structure across the back of the system out of the front of which sprouted the CPU (or DAT box and CPU for the model 67) and out of the rear of which sprouted one to four quarter-meg core boxes, each of which contained four small 64Kb three-dimensional core arrays, potted and heated to 90 degrees F. My only quibbles are that the memory boxes supplied with the models 65 and 67 were 2365s, not 2361s, and the nominal memory access speed as quoted by IBM (and measured crudely by us) was .7 microseconds, not 1.0 microseconds. At Rutgers, we referred to the structure containing the memory bus (and main power supply) as "The Subway Car". We discovered that one or two people could actually hide in there as long as the left side (as viewed from the front), which contained enough enormous electrolytic capacitors to add-up to over one farad (which is an large capacity, indeed), was avoided.

note that the 65, multiprocessor 65, and the 67 were pretty common ... with single ported memory and bus contention between processor and I/O.

running in virtual memory mode ... the dat box added 150 microseconds to the cycle ... making it .9 microseconds (instead of .750 microseconds) to allow the dat box to do its thing.

the multiprocessor 67 was something of a different beast entirely. it had a channel director and tri-ported memory. this introduced soemthing like .1 (mumble ) additional cycle overhead. a half-duplex 67 on processor intensive workload with little or no I/O was slower than a simple 67 (half-duplex 67 running in 65-mode possibly with os/mvt was slower on cpu intensive workload than simplex 67 or 65).

however, on heavy cpu intensive workload with heavy i/o (say cp/67 with one hundred percent cpu utilization, heavy interactive, and heavy paging) ... a half-duplex 67 (single processor) outperformed a simplex 67 because of the reduction in bus contention between the cpu and I/O

the 67 channel controller also provide the capability for all processors to access all channels. the 360/65 (and later 370) duplex strategy was that processors continued to have dedicated channels and integrated i/o configurations came by configuring all controllers with twin-tail channel connectors (one to each processor). The channel controller had panel configuration switches that controlled whether operating as duplex or partitioned as two half-duplexes, how the memory banks were routed and the channels connected. These configuration switches were "sensed" thru defined bits in the control registers ... and in at least one model ... it was possible to change the switch settings by changing the bits in the control registes.

the work on cp/67 multiprocessor support at the cambridge science center resulted in the compare and swap instruction (original mnemonic the initials of the person in cambridge that invented it) ... misc. cambridge posts:
https://www.garlic.com/~lynn/subtopic.html#545tech
misc. multiprocessor posts:
https://www.garlic.com/~lynn/subtopic.html#smp

I had heavily optimized the cp/67 page i/o pathlength and completely redesigned and rewrote the scheduling controls, page replacement algorithm, etc .... so it was possibly to have concurrent one hundred percent cpu intensive workload while at the same time running interactive instensive and heavy paging. my page thrashing control inventions were different from the working set stuff that had been published in the literature about the same time. some 15 years later, there was significant resistance to a stanford Phd thesis (wsclock) that proposed something similar to what I had done on cp/67. Helping to overcome the resistance was that the grenoble science center had published an ACM paper on modifying cp/67 for a traditional working-set dispatcher with some published numbers. With essentially the same hardware, grenoble had approximately the same thuput and interactive response with 35-40 users on 1mbyte 360/67 (154 pageable pages after fixed storage requirements) that I had with 70-80 users on 768k 360/67 (104 pageable pages). lots of past stuff on scheduling and paging:
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

misc. past threads on the global versis local replacement stuff:
https://www.garlic.com/~lynn/94.html#01 Big I/O or Kicking the Mainframe out the Door
https://www.garlic.com/~lynn/94.html#1 Multitasking question
https://www.garlic.com/~lynn/94.html#2 Schedulers
https://www.garlic.com/~lynn/94.html#4 Schedulers
https://www.garlic.com/~lynn/96.html#0a Cache
https://www.garlic.com/~lynn/2002o.html#30 Computer History Exhibition, Grenoble France
https://www.garlic.com/~lynn/2003j.html#3 A few Z990 Gee-Wiz stats

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

40th anniversary of IBM System/360 on 7 Apr 2004

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 40th anniversary of IBM System/360 on 7 Apr 2004
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 20 Jan 2004 19:10:08 GMT

tjpo@ibm-main.AIRBORNE.COM (Patrick O'Keefe) writes:
In the late 60's I was an operator at the IBM Datacenter in downtown Seattle. 2 stories of glass curtain windows showing off a range of IBM machines - up through S/360 Mod 50. The eventual "security" feature added was a mostly transparent cloth curtain that was closed at night.

now somebody has offices in that space and big sign (... all i can remember is that name starts with J?). i remember getting some 3rd shift testing in that datacenter in the late '60s (i was undergraduate at the time) ... and during the day killing some time wandering around some of the ibm offices upstairs. i remember sitting in on an mvt debugging class ... and after about 30 minutes starting to correct the instructor ... who then asked me to leave.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

dual processors: not just for breakfast anymore?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: dual processors: not just for breakfast anymore?
Newsgroups: comp.arch
Date: Tue, 20 Jan 2004 18:30:03 GMT

Christian Bau writes:
Hyperthreading doesn't give you any more resources, it only tries to help you using a bigger percentage of available resources. So it won't help if you are bandwidth limited, it also won't help if your code is written so well that it reaches limits of instructions per cycle, floating point instructions per cycle etc.

Hyperthreading should work quite well if you have long chains of dependent floating point operations: Huge latency, so your code eats only a small percentage of the available resources, and hyperthreading might double that. Of course, that is the kind of code you would want to avoid in the first place.

the hack for the 370/195 (30 some years ago) was because it didn't have speculative execution and branches would drain the (64 instruction) pipeline (unless it was loop within the pipeline). the majority of codes ran the 195 at less that half its peak thruput ... because of the branch stalls.

the dual processor had duplicate set of registers and dual i-streams ... and work in the pipeline got a red/black flag to indicate which i-stream the work was in, the idea was that stalls in one i-stream might be overlapped with work from the other i-stream. one might claim that the tera ... oops cray ... carries the stall/latency compensation to extream ... previous thread reference
https://www.garlic.com/~lynn/2003p.html#5 Hyperthreading vs. SMP
... aka up to 128 hardware threads

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Two subjects: 64-bit OS2/eCs, Innotek Products

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Two subjects: 64-bit OS2/eCs, Innotek Products
Newsgroups: alt.os.development,comp.arch,comp.os.os2.apps,comp.os.os2.misc,comp.os.os2.programmer.misc
Date: Tue, 20 Jan 2004 18:20:23 GMT

Tim Olson writes:
The PowerPC processors were jointly designed and manufactured by both Motorola and IBM (well, 601 was IBM-only), and Apple used both suppliers for various PowerMac designs. Another group at IBM was continuing the design of the POWER series.

RIOS was power series (I have a clear grean plastic paper weight here with six chips and says 150 million ops, 60 million flops and 7 million transistors). power/pc was done at somerset, joint project between ibm and motorola ... the executive we reported to when we were doing ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp

went over to head up somerset (he had previously been at motorola before coming to work on rios). he then went on to become president of mips and then later returned to austin.

one big point about RIOS was that it didn't have any provisions for cache consistency. the only SMP that had been done with RIOS chips was 4-way using RIOS.9 .... which had a hack that you could flag segment as being cacheable or non-cacheable (aka if you needed consistent memory ... it was consolidated in a segment flagged as non-cacheable). one big point about power/pc was to be able to support cache-consistency (there are references to power/pc being power with 88k bus ... but you need more than the 88k bus to have cache consistency).

RISC formalised: IBM 801
http://www3.sk.sympatico.ca/jbayko/cpuAppendA.html#801

IBMS RS/6000 POWER
http://www3.sk.sympatico.ca/jbayko/cpu5.html

27 yars of ibm risc
http://www.rootvg.net/column_risc.htm
note in the above ... refers to RSC as RISC Single Chip ... but, in fact, it was called RIOS Single Chip.

misc. past 801, romp, rios, power/pc postings
https://www.garlic.com/~lynn/subtopic.html#801

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

passwords

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: passwords
Newsgroups: alt.computer.security
Date: Tue, 20 Jan 2004 20:19:22 GMT

Colonel Flagg writes:
3-6 months ago, either in here or on slashdot, someone posted the URL to an article written about password strengths and statistics attempting to show that passwords above a certain number of characters was no more "secure" than a password of lesser characters.... anyone remember the URL or have it bookmarked?

the number of characters in theory are analogous to the number of bits in crypto key ... and therefor can be viewed from the stand-point of how long will a brute-force attack take. however, if the infrastructure supports limit on consecutive bad passwords or other defensive methods ... then brute-force attacks can be thwarted (and it is no longer necessary to have ever increasing key sizes to make repetitive trying of all possible values impractical).

there is a second order problem .... the whole issue of

frequently changing shared-secrets
shared-secret paradigm propagated into scores of environments
requirement that unque shared-secret be used for every different security domain

overloads typical human memory capability leading to people having to write the scores of passwords down. long, complex passwords can aggravate the human memory limitations. many/most of the password articles seem to address the issue from purely myopic position that an individual never will be in position of dealing with more than a single security domain (and never having to remember more than a single password that may never change).

what in fact happens, the threat model can be against the aid used for remembering scores of passwords ... not the actual password themselves (trojan horses looking to harvest password files).

an alternative is to go to a two-factor authentication based on non-shared-secret (something you have and something you know) .... aka

1) a hardware token that does a digital signature and can be validated by a public key (that has been registered in lieu of a shared-secret password). having access to list of registered public keys in one security domain wouldn't compromise the use of the same public keys in a different security domain ... aka a shared-secret can be used to both originate as well as validate an authentication ... while a public key can't be used to originate an authentication ... but can only be used to validate an authentication

2) a PIN that controls the operation of the hardware token. both shared-secret and hardware token PIN represent something you know authentication. However, if a shared-secret something you know, is divulged, it possibly enables others to fraudulently use the shared-secret to impersonate (the security requirement for unique shared-secret for every security domain). A hardware token PIN is also a form of something you know ... but since it never has to be divulged, it can drastically simplify the human memory issues. Instead of having scores of shared-secrets ... the person has a single hardware token, controlled by a single PIN ... that is never divulged and is not a shared-secret.

It is in the non-shared-secret, hardware token PIN paradigm ... that you can start talking about a threat model being against the PIN itself, the length of the PIN, etc ... since the human memory issues with large numbers of security domains and scores of shared-secrets are significantly mitigated.

Note, a trojan horse that harvests a person's password file ... can lead to being able to impersonate that person in large number of different situations. Any sort of virus or trojan horse that harvests a hardware token PIN still isn't able impersonate w/o also having access to the hardware token. From a fraud return-on-investment ... the costs for harvesting a hardware token PIN and gaining access to the hardware token itself is significantly higher than the cost of harvesting password files (or in the electronic commerce scenario, the merchant master transaction file). Such hardware token related acquisition costs might even be larger than any expected fraud return ... making it more attractive for the criminals to go elsewhere.

and even more topic drift about security proportional to risk:
https://www.garlic.com/~lynn/2001h.html#61

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Threat of running a web server?

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Threat of running a web server?
Newsgroups: alt.comp.anti-virus,comp.security.firewalls,alt.computer.security
Date: Tue, 20 Jan 2004 20:25:56 GMT

"David Norris" writes:
majority of intrusions via webservers occur via scripts (CGI and so on). If you are careful about use of scripts, your risk is much lessened. DN

i had heard some number about fraud ... that about

1/3rd from buffer overflows and other implementation flaws,
1/3rd from viruses and trojan horses involving scripts/executables arriving from the net and being executed, and
1/3rd from social engineering

some of the network originating scripts/executables also involve social engineering as to the inducement it takes to have a person click on the executable (as opposed to exploiting a flaw where the secript/executable is automatically executed).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Two subjects: 64-bit OS2/eCs, Innotek Products

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Two subjects: 64-bit OS2/eCs, Innotek Products
Newsgroups: alt.os.development,comp.arch,comp.os.os2.programmer.misc
Date: Wed, 21 Jan 2004 05:31:58 GMT

Peter Flass writes:
I believe the 604 uses a segment table in memory vs. segment registers in earlier versions. It's able to directly address *lots* more memory.

ROMP had 16 segment registers with 256mbyte segments ... with 32 bit addresses ... that was 4bits to index the segment register and 28bits to address address within the segment. it used inverted tables ... and "tagged" segment identifiers in TLB. ROMP used 12bit segment identifiers in the TLB (i.e. the segment registers didn't contain a pointer to virtual memory tables ... just a 12bit segment identifier).

lots of virtual memory infrastructures use tables in memory and the TLB use some part of the table pointer to distinguish addresses in different virtual memories. 370 (mainframe) had STO-associative TLB .... i.e. the segment table origin address was used to tag entries in the TLB.

The 801/ROMP flavor effectively had segment-associative tagging, using an explicit id number. One of the side-effects is that virtual addresses in the same "shared segment" could share the same TLB entries .... while something like STO-associative TLB entries might have different entries (even for identical shared code).

RIOS continued with the 801/ROMP 16segment registers and 32 bit addressing ... but extended the size of the tag field to 24bits. The size of the tag field ... plus the 28bit virtual address ... gave rise to the claim that 801/ROMP was 40 bit addressing (i.e. 28bit segment address plus 12bit segment-id tag) and 801/RIOS claim of 52bit addressing (i.e. 28bit segment address plut 24bit segment-id tag).

Note that the limited number of distinct segments was originally designed for a closed operating system and execution environment. THere was justification for the limited number of distinct segments as hardware/software trade-off ... where the application environment would have all its privileges/integrity check before execution and inline application code would be able to change segment registers as easily as general purpose registers (for addressing purposes). There was no separate security domain, authorization checking, and/or kernel calls required.

In retargeting ROMP to unix environment .... security domain and authorization checking (with kernel calls) had to be implemented for changing memory mapping. Compared to some other unix environments that might have dozens of unique shared memory objects/segments simultaneously defined in the same virtual address space ... the 16 total segments was a limitation. This led to packaging multiple different executable objects into shared library which could be mapped into a single (shared) segment.

misc. past posts discussing original rios has having 52-bit addressing.
https://www.garlic.com/~lynn/2000b.html#54 Multics dual-page-size scheme
https://www.garlic.com/~lynn/2001c.html#84 database (or b-tree) page sizes
https://www.garlic.com/~lynn/2002c.html#40 using >=4GB of memory on a 32-bit processor
https://www.garlic.com/~lynn/2002g.html#17 Black magic in POWER5
https://www.garlic.com/~lynn/2002l.html#60 Handling variable page sizes?
https://www.garlic.com/~lynn/2002m.html#33 simple architecture machine instruction set
https://www.garlic.com/~lynn/2003e.html#0 Resolved: There Are No Programs With >32 Bits of Text
https://www.garlic.com/~lynn/2003h.html#37 Does PowerPC 970 has Tagged TLBs (Address Space Identifiers)

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

BASIC Language History?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: BASIC Language History?
Newsgroups: alt.folklore.computers
Date: Wed, 21 Jan 2004 16:14:44 GMT

et472@FreeNet.Carleton.CA (Michael Black) writes:
That's got to be wrong. I thought the whole point of BASIC was that it was an interpreter, so it was good for beginners. It ran on the Dartmouth timesharing system originally. You could type something in, and immediately see a response. You didn't have to worry about that technical stuff, like compiling, so it made inroads in non-computer science circles.

And certainly Microsoft did not have the first interpreter, even if BASIC had originally been a compiler.

David Ahl's computer games book predates the home computer, and his work at DEC was precisely based on BASIC being available. As I already mentioned, Bob Albrecht was using BASIC to introduce computers to people, and that was in the early seventies. Creative Computing was mostly about BASIC, and it predates 1975. BASIC was something sought early on with home computers because many were familiar with it, and so we saw those tiny BASICs being written early on. What would be Microsoft wrote a BASIC for the Altair because it was familiar.

CPS was conversational programming system done by the boston programming system. They also had ROS RPQ for the 360/50 for new instructions that improved the performance of CPS operation. It supported conversational/interactive PLI and BASIC.

The Boston Programming Center was on the 3rd floor of 545 tech. sq, (the cambridge science center was on the 4th floor, the CSC machine room with 360/67 was on the 2nd floor ... and of course, Project MAC & Multics was on the 5th floor). In the early '70s, the boston programming center was somewhat divided and most was absorbed by the growning VM/370 development group (which had split off from the cambridge science center) and took over the 3rd floor. Misc. people from the boston programming center did go to the science center.

The rapidly growing VM/370 development group quickly outgrew the 3rd floor and moved out to the old SBS building in burlington mall.

search engines turn up a few CPS references ...
http://www.okstate.edu/cis_info/cis_newsletter/jan-feb95/jan-feb95.html where 1995 newsleter mentions CPS in section about "25 years ago (1970)".

a 1971 newsletter mentions call/360, CPS, basic, pli:
http://ukcc.uky.edu/~ukccinfo.491/kr197107.html

cps manual is mentioned as being in this archive:
http://www.cbi.umn.edu/collections/inv/cbi00060.html

the following from:
http://home.uchicago.edu/~rthielen/cps.html
Conversational Programming System

CPS was what was called a Type III program, one that was written by an IBM employee in the field and was unsupported. The quote below is from the Program Contribution Form for IBM program 360D-03.4.016 dated August 7, 1969. This document can be found in my office along with the CPS Terminal User's Manual, Installation and Administration Guide, and System Programmer's Guide.

"Conversational Programming System is a time-sharing system that runs in a partition of OS/360 Release 17 MFT II or MVT. The CPS language is a conversational dialect of PL/I and includes a modified subset of the BASIC language of IBM CALL/360. The system also provides Remote Job Entry to batch processing and Remote Job Output to a designated terminal from a dataset designated by any batch job." (This was hot stuff!)

"Prior to installation of Conversational Programming System, minor changes must be made to OS/360 and a new system generated. The system supports Models 40, 50, 65, 75, and 67 Model 1 in 65 mode, and Model 91, along with terminal types 2741 and 1052 as well as Teletype ASR Models 33 and 35." (That's what we used. Stored the programs on punch tape.)

"Minimum core requirements are for an H memory to support two terminals and a 64K background. Additional core (which may be 2361) of 18K bytes per active terminal is required for more than two terminals."

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

passwords

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: passwords
Newsgroups: alt.computer.security
Date: Wed, 21 Jan 2004 18:00:33 GMT

"Alan P" <alan@(nojunkplease)alancode.net> writes:
Ding-a-ling-ling, Feeding time

oh well ... a couple candidates?
http://www.plasticbag.org/archives/2003/08/a_question_about_password_length.shtml
http://seclists.org/lists/security-basics/2003/Nov/0383.html

password strength meter
http://www.securitystats.com/tools/password.php

might also do google group search for past 18 months on something like password strength
http://groups.google.com/advanced_search?hl=en

some what older
http://www.securityfocus.com/infocus/1554
older still
http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-500.pdf

and some more topic drift ... old password selection advisery:
https://www.garlic.com/~lynn/2001d.html#51 OT Re: A beautiful morning in AFM.
https://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM.
https://www.garlic.com/~lynn/2001d.html#53 April Fools Day

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Two subjects: 64-bit OS2/eCs, Innotek Products

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Two subjects: 64-bit OS2/eCs, Innotek Products
Newsgroups: alt.os.development,comp.arch,comp.os.os2.misc,comp.os.os2.programmer.misc
Date: Wed, 21 Jan 2004 22:44:34 GMT

glen herrmannsfeldt writes:
I could be wrong, but I don't know that they sold non-PS/2 with OS/2 preloaded on them. They didn't try very hard to discourage people from believing it, either. No full page ads, "Yes, OS/2 really will run on your AT clone."

three news clips from spring '88.

note that there was an enormous amount of SAA that was targeted at compatibility ... but behind the scenes there was some effort to get PC-based applications ported to the mainframe ... so that the data & execution was back in the glasshouse and PC become a really fancy, glorified GUI delivery vehicle. The t/r and saa really got upset with my wife and I when we came up with 3-tier architecture in the '80s and started presenting it to customers. The GUI delivery vehicle strategy could be seen in the late '80s where salesmen and reports were strongly recommending (to commercial customers) that they could have a single 16mbyte t/r bandwidth shared with 300 or more PCs (aka the severe network bandwidth limitation was in line with using the PCs are glorified GUI presentation platforms). misc. past saa & 3tier related postings:
https://www.garlic.com/~lynn/subnetwork.html#3tier

... and three news clips from spring '88 ..


Apple sues Microsoft, H-P over Mac-like software,

San Jose Mercury News, 18 Mar 88, page 12D

Apple sent shock waves thru the computer industry Thursday by filing
a lawsuit that could frustrate IBM plans to make its personal
computers as easy to use as Apple's.

- Filed in US District Court in San Jose
- raises some basic questions about who owns what when it comes to
look and feel of PC's
- Apple has argued that "user friendly" features of Mac are copyright
  protected.
- IBM has staked the future of PS/2 line on Mac-like features
- Apple seeks to stop sale of Microsoft and H-P software that contain
features that distinguish Mac computers

- Apple is attacking an ally as well as a competitor (Microsoft)
- Microsoft sells the most popular software that runs on Mac
- Microsoft is also developing Presentation Manager to run on OS/2
- Presentation Manager is based on Microsoft Windows
- Earlier versions of  Windows received a "limited license" from Apple
- Apple has not approved the latest release of Windows version 2.03
(Infringes Apple's copyrighted "audio visual display")
- Apple is saying between-the-lines:
"watch out IBM"
- Apple suing H-P over the New Wave program (works on IBM compatibles)

- Microsoft:  "We don't believe we've infringed any copyrights"

- 1987 landmark ruling in Atlanta: Softklone infringed Digital
Communications Associates copyright of screen display
- Apple sued Digital Research (for GEM), and DR changed it to meet
Apple's demands

Local commentary:
 - Russo, lawyer in software copyright:
. Look and feel of Mac is certainly legally protected
   . Doesn't mean similar products will be found to violate copyright
. Apple has a copyright on display; question is to what degree
- Winer, software engineer with Symantec
. Relationship between IBM and Apple has always been strained
   . Apple views Microsoft as a bigger competitor than IBM

====================================================


AT&T's Dark Horse in the User-Friendly Derby (Business Week 2May88)

Unix's Open Look looks like a serious challenger to Apple/IBM

Graphical user interface:
- a mouthful of computerese
- has allowed millions to master their computer w/o intimidating commands
- "it's fundamental -- like the wheel." -Fred Gibbons, Software Publishing
- trend toward simpler relationship, human to computer
. getting there is anything but <simple>
- OS/2 Presentation Manager
. based on MS Windows (sued by Apple)

Unix:
- favored by engineers and professional programmers
- known as ANYTHING BUG "user-friendly"
- hopelessly complex, even compared to MS Dos

Open Look
- Joint project by AT&T, Xerox, and Sun
- Unix' arcane commands buried under a Mac-like graphical user interface

First IBM-compatible to mimic the Mac won't be PS/2 using OS/2 with PM
- AT&T plans to ship 6386 computer in September
  . 1 month before Presentation Manager
. Will start selling 6386 with Unix and Open Look
- "Open Look makes it more of a horse race" -Paul Cubbage, Dataquest
. Unix could capture 15-20% of commercial applications
. Without Open Look ... Unix would get 5%, MAX
- Unix will now compete with OS/2  -Vittorio Cassoni

OS/2 improvements over MS-DOS are already built into Unix
- capacity to handle large, complex programs
- ability to multi-task
- Unix takes full advantage of 80386 chip
. OS/2 won't for another year
- REAL advantage is in communications
. "interoperability"
  . Workstations can tap into programs running on other machines
. Unix adapted to run on a network
. Simpler to write programs that run on all these machines
. Unix adoption as a standard could vastly simplify networking
  . "It has the best networking software, and after 20 years,
it's reliable."  -Gibbons, Software Publishing
- Unix software tools are an order of magnitude better than
anything for OS/2

Only Ashton-Tate has endorsed the Open Look concept
- Lotus has plans for 1-2-3, needed for government contracts
. but reserving judgment on Open Look
- Software developers go where the volume is
. technical strengths mean little without market momentum
- First OS/2 application prototypes expected at a trade show in May
- Software developers won't have Open Look tools to develop
  applications until next year
. In the meantime, developers concentrate on OS/2

Time may be on Unix' side
- OS/2 and PM need large internal memories
. 10 times the average PC
  . current chip shortages makes it difficult to get the machines
. May take a year or more for memory prices to drop
  . delay gives Unix and Open Look a chance

=======================================================


'The Trends Spotter' - Guardian 26 May 1988

Interview with William F. Zachmann, senior VP, International Data Corp.

"Every year Zachmann makes 13 predictions about the next 18 months in
the business computer industry, and his track record is excellent."

- IBM is "heading deeper into the mire"
- Recession in US -> companies more economical in purchasing
- Era of mainframe at an end
  - "Just about any alternative for obtaining information processing
capabilities is less expensive than a mainframe ... as even the
    most habit bound users ... cannot fail to notice"
- "Personal computers, local area networks, servers, and the like
... are a completely inadequate diet for a US$60 billion
behemoth accustomed to huge profit margins on big expensive
    mainframe computers subject only to very limited competition."
- IBM's incompatible hardware offerings and "often zigzagging
   announcements of direction and strategy" lead it to "inadvertently
punish the very customers that are most loyal"
- Example - 8100 - loyal customers bought "dead-end box"
- Example - minicomputer line - incompatible S/36, S/38, 9370
  - "PS/2 line is poised to repeat the horrors of the 8100 on an even
larger scale."
    - Models 25 & 30 "will never run OS/2"
- Intel 286-based PS/2 models 50 & 60 - will not be sufficiently
powerful to provide adequate OS/2 performance
- Model 50 "probably won't run" OS/2 EE 1.1 "at all"
      >>> "serious disillusionment" for loyal IBM customers

- OS/2 problems -> "another good year for industry-standard personal
computers" ie IBM-PC compatible
- PS/2 clones will "prove elusive"
- "I am predicting that IBM will not let others build them any time soon"
  - "The whole point of the PS/2 and" MCA "was to create an architecture
that would not become a de facto standard the way the PC, XT and AT
    did."
- If PS/2 clones become necessary in order to create acceptance:
- "IBM will, in effect, license only the halt and the lame or impose
conditions that will ensure that even the healthy will be
       effectively halt and lame by the time they meet those conditions."
- Microsoft Windows (basis of Presentation Manager) will benefit.
  - "Windows 2.0 and 386 offer the vast majority of users far more
practical value at a significantly lower cost and in a far simpler
form than what OS/2 will offer even after" PM "is available."
- Accepts:
    - hardly any Windows software available
- difficult to write for (more so than the more popular GEM)
  - But:
- major firms like Lotus and Microsoft working on it
- sees Mac software houses expanding into Windows

- Microsoft's MS LAN "will capture the high ground"

- Network file-servers will be the "hottest hardware category" of the next
year
- Will generally come to run Unix* or OS/2 (more likely OS/2)
- SQL will be the base level standard for distributed resources
  - But since SQL "unfriendly and inadequate", still alot of competition
between SQL compatibles

- Unix* will continue to grow as users leave behind proprietary OS
- AIX and the "so far lackluster" RT will "prove to be much more
successful" than IBM's "mainstream products"
  - dependent on "more powerful and more aggressively priced versions
of the RT "appearing "soon"
- SAA will cross over to DEC's VAX VMS and to Unix*
- anything wide enough to cover such major hardware incompatibilities as
PS/2, S/3x and S/370 is wide enough to cover virtually anything.
- "This offers a tremendous opportunity for innovative software vendors
   who will, in effect, help IBM fulfil the promise of SAA well beyond
the point that IBM intended"
 - Threatens IBM with "possibility of a major stampede to Unix* via the
opening that SAA will create"

- C's "intimate relationship" with Unix*, DOS and OS/2 will make it the
  "hot programming language of 1988/89 as well as the dominant one of
the 1990s"
 - "Cobol, Fortran and Basic are ready to be pushed into the grave along
with Sanskrit and ancient Greek."
- "Even firms lumbered with dinosaurs" (mainframes) "will need C to take
advantage of microprocessors and the irresistable economies of the
   small."

- Clearly all Zachmann's predictions are based on 2 complementary trends:
- movement to microprocessors ("downsizing") and towards standard OS
- movement away from minis/mainframes with proprietary OS

- New standards will be:
- Intel and Motorola processors
 - Unix*, DOS and OS/2 operating systems
- Ethernet, Netbios and Microsoft's OS/2 LAN for networking

Notes:
- Interview by Jack Schofield (editor, Computer Guardian)
- *: Unix is, of course, a trade mark of AT&T Bell Labs

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

40th anniversary of IBM System/360 on 7 Apr 2004

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 40th anniversary of IBM System/360 on 7 Apr 2004
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 23 Jan 2004 16:31:34 GMT

IBM-MAIN@ibm-main.isham-research.com (Phil Payne) writes:
ST/370 used to annoy me. Within ten seconds it knew _EXACTLY_ what hardware was present, how it was attached, what features it had, etc.

I think it was a mindset .... that specification should be in sysgens.

CP/67 had automatic terminal detect (no sysgen required) ... at least for 1052, and the two types of 2741. When I was an undergradudate, I added TTY support to CP/67 ... and attempted to integrate it consistently with the automatic terminal detect philosophy ... making liberal use of 2702 SAD command to switch line-scanners. Then the local CE pointed out that they had taken a short-cut in the 2702 implementation ... while the SAD command could switch the line-scanner, the oscillators had been hardwired, fixing the line-speed (my testing had worked just barely within spec, running a tty on a 2741/1052 port).

this sort of resulted in launching a clone controller project at the university ... where four of us, sort of get blamed for originating the plug compatible controller market
https://www.garlic.com/~lynn/submain.html#360pcm

we reverse engineered the channel interface and built a channel board for an interdata/3. the line-scanner in the interdata/3 was in software .... and included sequence to strobe signal raise/lower at very high rate to detect baud rate. this was later enhanced to be an interdata/4 with multiple interdata/3s packaged as dedicated line-scanners.

Later, in the 370 time-frame, E4 (extended sense) was supposedly introduced to help assist, at least in dynamic controller determiniation ... and supposedly minimize the need for the hardware sysgen configuration paradigm.

When I was doing the resource manager .... the operating system still had a code tabled of cpu models ... that controlled various things. STCPID was used to look up the cpu model in the coded table and set various of parameters. This severely restricted having a kernel built at one point and migrating to later processor models w/o source and kernel rebuild. Turns out the table entries were primarily there for things related to processor performance issues. Anyway, in very early code that eventually shipped in the resource manager ... I attempted to dynamically determine processor performance characteristics at boot and set all the related parametes w/o having to resort to any processor model table.
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

An early version of this code/kernel leaked out to AT&T long lines ... a couple years before it shipped in any product. Nearly ten years later, the national account manager for long lines tracked me down ... looking for help in getting long lines off that specific kernel. Apparently as new models came out ... they just moved it to newer machines ... and it had apparently propagated thru-out long lines.

slightly related is the disk engineering scenario ... where bldg 14 (disk engineering) and bldg 15 (product test) were running stand-alone ... because operating single engineering device (in testcell) had characteristic of causing MTBF of 15 minutes for MVS. They used FRIEND and some number of other stand-alone utilizes for testing hardware. The machine rooms were setup with channel switches and scheduled dedicated test time for each testcell. In any case, we did a redesign and rewrite of IOS so that multiple testcells could be tested concurrently w/o operating system hang or failure.
https://www.garlic.com/~lynn/subtopic.html#disk

I believe the term testcell originated for two purposes:

1) the requirement for stand-alone scheduling ... and which testcell was going to have test time, when

2) a security requirement for technology under development. the plant site and perimeter fence and guards. The bldgs. had door badge system to get into the building. The machine rooms had door badge system to get into the machine room (inside the bldg). Each development device was housed inside its own a heavy steel mesh cage with 4-number, high-security combination lock securing the cage door. Each cage was large enuf to accommodate something like a 3880 controller, and maybe two engineers in cramped space (3880 doors didn't swing, they were removed).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

merged security taxonomy & glossary

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: merged security taxonomy & glossary
Newsgroups: alt.computer.security,comp.security.misc
Date: Fri, 23 Jan 2004 17:25:13 GMT

over the past week, i've merged three more glossaries:

• definitions from FFIEC examination handbook • definitions from vulnerability testing glossary • definitions from recently release NIST 800-61

for more information & original URLs see:
https://www.garlic.com/~lynn/index.html#glosnote

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

When rsa vs dsa

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When rsa vs dsa
Newsgroups: comp.security.ssh
Date: Fri, 23 Jan 2004 20:36:41 GMT

Gary Armstrong <garyarm_remThis_at_testedgeinc.com> writes:
Yep brand new and no clue about the issue.

I'm setting up openssh and know zip about cryptology (hope this is the correct word). I've read that I can generate both types of keys. Is there some reason, I'd want to use one over the other?

one of the issues used to have to do with hardware tokens. dsa includes generation of a random number as part of the signing process, poor random number generation can allow the private key to be recovered. for quite awhile, the crop of availabile hardware tokens had really bad random number generation ... which resulted in dsa private keys being extremely vulnerable (with dsa implemented in those environments).

rsa didn't have the same vulnerability ... although there is frequently a requirement for a random number NONCE in rsa-signed messages.

RSA signature of a 20-byte SHA-1 is 20 bytes ... plus the size of the message plus frequently a 20byte random number NONCE contained in the body of the message ... effectively message length plus 40 bytes (20 byte signature plus 20 byte nonce).

DSA signature of 20-byte SHA-1 is 40 bytes ... plus the size of the message ... which is message length plus 40 byte DSA signature.

in any case, infrastructures that wanted to be agnostic with respect to hardware token and software implementations might have tended to go with RSA (eliminating the private key vulnerability dependent on hardware token quality random number generation as part of the signing process).

more recent crop of hardware tokens tend to have hgiher quality random number generators ... sufficent for doing both on-chip key generation as well as DSA (and/or ECDSA) signing.

DSA .. FIPS186-2 reference:
http://csrc.nist.gov/cryptval/dss.htm

SHA ... fips180 reference:
http://csrc.nist.gov/cryptval/shs.html

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

When rsa vs dsa

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When rsa vs dsa
Newsgroups: comp.security.ssh
Date: Sat, 24 Jan 2004 17:10:43 GMT

Simon Tatham writes:
On the contrary. An RSA signature is about the same size as the modulus of the RSA key. So for a 1024-bit key, that's _128_ bytes.

yep, severe brain check there ...

minor additional information as to key strengths ... following from internet-draft on key lengths:
http://www.ietf.org/internet-drafts/draft-orman-public-key-lengths-07.txt


System
requirement  Symmetric  RSA or DH     DSA subgroup
for attack   key size   modulus size  size
resistance   (bits)     (bits)        (bits)
(bits)

    70           70          947          129
80           80         1228          148
90           90         1553          167
100          100         1926          186
   150          150         4575          284
200          200         8719          383
   250          250        14596          482

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

AMD/Linux vs Intel/Microsoft

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: AMD/Linux vs Intel/Microsoft
Newsgroups: comp.arch
Date: Sun, 25 Jan 2004 05:08:07 GMT

"del cecchi" writes:
OK, so what's a handle? Unix and windows have them. Is it like a dd statement? You know, DD DSNAME=MYFILE,DISP=NEW,PASS LRECL=80 (I forget the rest, mercifully)

move than you ever wanted to remember (DSCB, JFCB, DCB) ... following description from:
http://gsbwww.uchicago.edu/computing/research/SASManual/os390/z1main.htm#zstmt-sf
http://www.msb.edu/training/statistics/sas/books/os390/zilename.htm#zdcbover
Data Set Control Block (DSCB) is the description found in the VTOC of the disk device that the physical file resides on. These are the permanent characteristics of the data set. For tape devices, the data set label in the header of SL tapes contains this information.

Job File Control Block (JFCB) maps a physical file on a device to a logical name (DDname). Contains information from a JCL DD statement, TSO ALLOCATE command, SAS FILENAME statement, or SAS FILENAME function. These attributes are either temporary (for the duration of the allocation) or new (to be made permanent).

Data Control Block (DCB) describes the current state of an open data set. OS/390 and its access methods (BSAM for the SAS System) use the DCB to control how data is read or written. These attributes are temporary for input, but they become permanent for output.

..

then slightly related stuff from os emulation on cms:
http://www.vm.ibm.com/pubs/cms440/FCBSECT.HTML
random other cms stuff
http://www.vm.ibm.com/pubs/cms440/ADTDSECT.HTML
http://www.vm.ibm.com/pubs/cms440/AFTSECT.HTML
http://www.vm.ibm.com/pubs/cms440/FVSECT.HTML

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

AMD/Linux vs Intel/Microsoft

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: AMD/Linux vs Intel/Microsoft
Newsgroups: comp.arch
Date: Sun, 25 Jan 2004 17:55:11 GMT

Robert Myers writes:
You must have missed the discussion on comp.arch in which Lynn Wheeler talked about the importance of operator error. I thought the software aspect of mainframes has fared pretty well here recently. I think Del has probably occasionally had to throw something across the room over the discussions of running IBM software on Unix emulators.

my diatribe that systems which evolved for interactive use with implicit assumptions about human interactions .... then to have totally different characteristics from systems that evolved for batch use where there may also be assumptions about program running repeatedly and reliably every time ... time after time (with no human interaction what-so-ever). One issue is the ambiquity of web environments that evolved on platforms of the interactive paradigm, the client part of web is well suited for interactive platform ... but a lot of the webservers are much more oriented towards lights-out, hands-off environment ... and are much more suited for batch paradigm platforms. Another might be the backends that support large number of ATM machines (there may some argument about what should be in the ATM machine themselves ... but the backends tend to have some very strong business continuity issues). Note however, the large population of people when encountering the poor interactive charactistics of many of these batch platforms ... may extrapolate about usefullness of the platforms as a whole.

in any case, a past example was from guy responsible for one of the high-end financial networks ... claiming that 100 percent availability over a number of years was attributable to

1) IMS hot standby (three physically replicated locations) 2) automated operator

aka as overall system reliability and integrity has improved over the years .... a remaining source of errors has been humans. the batch environments tended to still have a small amount of human interactions with human operators and they were becoming the major source of glitches.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

AMD/Linux vs Intel/Microsoft

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: AMD/Linux vs Intel/Microsoft
Newsgroups: comp.arch
Date: Sun, 25 Jan 2004 21:15:07 GMT

"Dean Kent" writes:
The issue you speak of seems to imply that human intervention in the actual operation is the major problem. What I was referring to with Mr. Myers is that JCL allows a shop to customize names/devices for their own environment, which would then presumably be test and then submitted automatically by a job scheduler, and the output examined automatically as well, if that were the process in that shop.

Vendor naming conventions tend to irritate me. As one small example, on my PC I have a financial application installed that uses the .asc extension for their proprietary file format. This creates some problems when I try to double-click on an ascii file created from, let's say, SPEC. My preference would have been to have the ability to name files/extensions to whatever *I* want (or allow them to default if I want). JCL lets me do this - one time customization, automated operations after that.

systems need a method to map from application space to operational space ... especially when applications are developed for wide distribution in environments that there is no control over. various kinds of abstractions are useful for providing such level(s) of indirection.

stdin/stdout with humans (or possibly scripts) providing the mapping is another kind of solution. one might even make the case for applications with embedded filenames from either being ported from another environment (which did support the indirection abstration) and/or the development programmers getting orientation from such an environment.

JCL is another such solution. JCL also has the chracteristic that it is very batch oriented and not very interactive/human oriented. one of the early abstraction scenarios from at least the mid-60s was heavy sequential file processing and abstracting whether the device was tape or DASD (and DASD was in turm an abstraction for direct access storage devices, in part because at the start ... disks weren't even necessarily the dominant DASD type).

however, almost by definition, JCL is part of a paradigm where it was assumed (by default) that the person running the application wasn't anywhere around when the application ran. lots of the niggling details that would be assumed (in an interactive paradigm) to be handled by the person running the application would not be true. The operator was there to make sure the cards got in the reader, the tapes were correctly mounted and the printer fed. By the '90s, even that little bit of human involvement was becoming one of the few remaining sources of errors and failures.

CMS has been somewhat in both camps ... it could be considered to have somewhat similar/copmmon interactive heritage back to CTSS (but also needing to support much of the mainstream os/360 operations). If no predefined indirection has been specified by the user (aka sort of psuedo JCL) at the time the application ran ... the system would default to a filename that was some variation of a psuedo DDNAME ... aka when running fortran ... if user defined a filename indirection for FT03F001 ... it would use the filename indirection. If there was no indirection specificed ... then it would default to FT03F001.

you can somewhat pick that out from the CMS URL references from earlier post in another part of this thread (& lookup cms filedef command):
https://www.garlic.com/~lynn/2004.html#39

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

40th anniversary of IBM System/360 on 7 Apr 2004

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 40th anniversary of IBM System/360 on 7 Apr 2004
Newsgroups: bit.listserv.ibm-main
Date: Sun, 25 Jan 2004 21:29:48 GMT

shmuel+ibm-main@ibm-main.Patriot.net (Shmuel Metz , Seymour J.) writes:
I don't mean swapping the addresses of 2 3330 drives or of 2 2324 drives, I mean, e.g., swapping the address of a 2311 with the address of a 1443.

in the cp/67 scenario for determining 1052 and 2741 ... you looked for (non-distructive) CCW sequences that would work on one kind of device ... but not another ... say like seek operation, and then seek operations to specific cylinders and/or heads. even doing (non-dstructive) invalid operations for certain kinds of devices could give back hints in different kinds of sense patterns returned by the device.

one of the harder problems ... which possibly wouldn't show up so much in stand alone operations ... were things like trying to figure out whether (some) UCWs on 370s had been put in as shared or non-shared ... you could make guesses based kind of device. there are also little issues about having a pair of controllers generated as 8-devices each ... but within the same 32-device subchannel range. are you dealing with 327x devices on a pair of 16-device controllers or a single 32-device controller? It also made a difference when a controller goes into contingent connection because of a unit check & waiting for a sense opertaion. Long ago and far away ... an operating system could go into an endless short-busy loop because it had the span of the controllers misgen'ed and didn't realize it had to first clear contingent connection.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

[Fwd: Re: Mainframe not a good architecture for interactive w

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: [Fwd: Re: Mainframe not a good architecture for interactive w
as Re: What is the  future of COBOL? Answer: Irrelevant???]
Newsgroups: bit.listserv.ibm-main
Date: Sun, 25 Jan 2004 21:37:27 GMT

Chris_Craddock@ibm-main.bmc.com (Craddock, Chris) writes:
It looks like there is plenty of ignorance to go around. Hardware is hardware. There is nothing that makes a "mainframe" inherently good or bad for interactive processing. The same holds for Wintel and *IX boxes. When configured for the applications that they typically run, they each do well enough to satisfy large numbers of paying customers. Is any one absolutely better than any other? No. There are significant differences of course and some of them may be more important than others to you personally, but clearly there is room for all to play.

It would be a big mistake for the non-mainframe crowd to underestimate the power of the big iron. But its an equally big (and IMO more common) mistake for the mainframe crowd to underestimate the non-mainframe systems. There are some amazingly powerful systems out there. At least as much compute power and I/O throughput as the biggest mainframes. About all that can be categorically compared is their price. And on that measure the "other" bunch still are "cheaper" FSVO cheap. Not necessarily better, faster or more cost effective, but certainly cheaper.

and you are totally missing out on the thread over in comp.arch (which is nominally purely hardware architecture) and discussions about support for abstraction for file indirection handling ... and differences between systems oriented towards interactive vis-a-vis batch paradigm.
https://www.garlic.com/~lynn/2004.html#39 AMD/Linux vs Intel/Microsoft
https://www.garlic.com/~lynn/2004.html#40 AMD/Linux vs Intel/Microsoft
https://www.garlic.com/~lynn/2004.html#41 AMD/Linux vs Intel/Microsoft

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

OT The First Mouse

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT The First Mouse
Newsgroups: bit.listserv.ibm-main
Date: Sun, 25 Jan 2004 22:10:27 GMT

ibm-main@ibm-main.tpg.com.au (ibm-main) writes:
But if anyone wants to argue that the modern PC started and ended with Apple, try the following timeline.
http://cse.stanford.edu/class/sophomore-college/projects-01/human-computer-interaction/origins.htm

some slightly related drift ... note that word processing comes from early to mid 60s (just not wysiwyg) ... and then on CP/67 and Multics. CP67/CMS had script document processing with the dot formating commands in the late 60s. GML was invented by "G", "M", & "L" in 69 at the science center and script was enhanced with GML tag capabiilty (gml later morphed into sgml, html, xml and a whole host of other markup languages) misc science center references:
https://www.garlic.com/~lynn/subtopic.html#545tech
specific GML/SGML history
https://web.archive.org/web/20231001185033/http://www.sgmlsource.com/history/roots.htm
http://www.sil.org/sgml/sgmlhist0.html

the internal network also originated in science center. one of the early projects was joint development project between Cambridge and Endicott to modify CP/67 to run on 370 (virtual memory architecture) rather than 360/67. the "cp/67-i" system was (in some sense) running production a year before there were actual hardware 370 models to run it on. Later there was the "cp67-sj" system ... which was the "i" system with 3330 and 2305 device drivers added by some people in san jose.

In any case most of that period up thru about mid-85, the internal network was larger (had more nodes) than the arpanet/internet. One of the big change-overs for the arpanet was the switch to IP protocol on 1/1/83 and the introduction of internetworking and gateways ... allowing heterogeneous networks to interoperate. In effect, the internal network support had a form of gateway support from the beginning in each node ... allowing a form of heterogeneous interoperation ... and therefor was one less impediment to interconnected network growth.

A big difference in the period between 1/1/83 and mid-85 was the explosion in the number of workstations and PCs as internet nodes. During this period ... internally, there continued to be a battle to restrict PCs to terminal emulation connectivity and not allow full-blown, peer-to-peer networking capability. This sort of goes along with the claim that SNA was primarily a terminal controller infrastructure ... and 1) not a System, 2) not a Network, and 3) not an Architecture.

misc collected posts on internet & internal network archeology
https://www.garlic.com/~lynn/internet.htm

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

40th anniversary of IBM System/360 on 7 Apr 2004

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 40th anniversary of IBM System/360 on 7 Apr 2004
Newsgroups: bit.listserv.ibm-main
Date: Mon, 26 Jan 2004 00:20:38 GMT

IBM-MAIN@ibm-main.isham-research.com (Phil Payne) writes:
The 1052 was usually 009 - if you had a second, it was 008. Common on /65s.

The 3215 - used on smaller and more modern systems - was usually 01F.

Disks were, if memory serves, 19x for 2311 and 14x for 2314.

default CMS virtual machine configuration definition .... somewhat carried forward from when cp/40 was done on 360/40 ... and CMS testing was periodically done on real machine .... in parallel development with cp/40.

from pg. 5, GH20-0859, CP-67/CMS User's Guide
device virt. symbolic device number addr name type ---- --- ---- ------- 1052 009 CON1 console 2540 00C RDR1 card reader 2540 00D PUN1 card punch 1403 00E PRN1 line printer 231x 190 DSK1 s-disk (system files) 231x 191 DSK2 p-disk (user files) 231x 192 DKS3 t-disk (workspace) 231x --- DSK4 a-disk (user files) 231x --- DSK5 b-disk (user files) 231x 19C DSK6 c-disk 2400 180 TAP1 tape drive 2400 181 TAP2 tape drive

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

DE-skilling was Re: ServerPak Install via QuickLoad Product

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DE-skilling was Re: ServerPak Install via QuickLoad Product
Newsgroups: bit.listserv.ibm-main
Date: Mon, 26 Jan 2004 03:12:57 GMT

cfmtech@ibm-main.istar.ca (Clark F. Morris, Jr.) writes:
Actually, I think that having the system take care of the technogrunge is the only way to preserve the platform. As someone who has only been in small MVS shops, I know how hard it is to be knowledgeable in a vast variety of areas. A small shop has a hard time justifying big dollars for separate experts in the varying areas. In addition, there are a number of things that I just want to work decently and not have to spend much time on them. There always will be enough work figuring out what we should be doing (which things get priority, what are the security policies, what is our maintenance strategy, etc.) that any help in implementation and catching unexpected side effects will be appreciated.

I think I first noticed this in the 370 138/148 over 25 years ago ... where a combination of improved systems and better hardware price/performance ... was opening up new market opportunities

1) number of potential new installations greatly exceeded the skill base to support them

2) cost/benefit of many of the emerging entry level market opportunities couldn't afford the existing skill support cost structure.

this was enormously aggravated with the explosion in numbers of 4341 ... both in terms of number of installations exceeded the available skill base to support them ... and the existing skill cost structure.

the requirement became for de-skilling the whole system support infrastructure ... both because the skills weren't available for that exploding market ... as well as the costs of the skill intensive operations that were prohibitive for large segments of the emerging markets.

there were some jokes at share during this period that ibm didn't really have to worry about the Amdahl clones in its mainstream mvs market place ... because nowhere else but with a real ibm mainframe was a customer going to get the 20 IBM SEs necessary for the MVS care & feeding to keep such systems operational (and that Amdahl was going to be stuck with the fringe univeristy market running MTS or VM).

because of a lot of reasons ... that mid-range (both 4341 and vax) market then bled off into the emerging workstations and high-end PCs; there was some past questions about why wasn't there at least as many 4381s sold as 4341s (if nothing else ... upgrading every 4341).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Mainframe not a good architecture for interactive workloads

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe not a good architecture for interactive workloads
Newsgroups: bit.listserv.ibm-main
Date: Tue, 27 Jan 2004 14:30:56 GMT

IBM-MAIN@ibm-main.isham-research.com (Phil Payne) writes:
The System/360 architecture was very poor at interrupt handling (e.g., no vectored I/O interrupts) and task switching compared with the "mini" architectures of its day. But that wasn't a market it was in - IBM's solutions in that space were Series/1, the 8100, etc.

some of it was the operating system architecture ... not necessarily the hardware architecture. cp-67/cms as well as MTS got reasonably good reputation for interactive ... using virtual memory on 360/67.

some number of purely interactive oriented subsystems were developed for non-virtual memory 360 platforms also. os/360 has extremely heavy-weight task switching, very oriented towards long running batch jobs ... as a result you had loads of subsystems/monitors that appeared that did their own relatively light-weight task switching ... cics, apl\360, cps, call/360, music, etc.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

AMD/Linux vs Intel/Microsoft

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: AMD/Linux vs Intel/Microsoft
Newsgroups: comp.arch
Date: Tue, 27 Jan 2004 16:47:44 GMT

"Stephen Fuld" writes:
The point was that, at least at the time, OS/360 *Couldn't* do it without loading a program. You had to load a program, any program, in order to get the OS (which actually did all the work) to delete a file.

IEHPROGM will do it for IBM,

Yes, as will any other program.

the real bear was the job scheduler that processed the JCL and did the program loading ... it was quite a large application in its own right ... and it had to be loaded ... before any program was loaded.

in the '60s you saw quite a few monitors ... which would get loaded and stay resident ... and which would then accept commands or other things and perform operations.

when I was an undergraduate, the university moved from 709 to 360/67. the 709 had ibsys monitor that would process student fortran jobs ... tape-to-tape (with 1401 providing card to tape and tape to printer front end) ... on the order of a second elapsed time per student job.

moving to os/360, mft, release 11, running 3-step "fortran compile, link-edit, and go" on 360 took almost a minute elapsed time for the same student job (effectively all of it was job scheduler execution). The job scheduler involved a large number of different executables and other disk access that was repeated for each job step (and there was insufficient real storage to do any caching). I got on the order of a three fold speed-up in job scheduler elapsed time ... just by carefully ordering where stuff was placed on disk (optimizing arm seek operation ... compared to standard out-of-the-box system).

that still wasn't enough to get 360 infrastructure back to being able to handle the student workload that the 709 had been handling. It wasn't until the university got waterloo's WATFOR ... that the 360 student job thruput got better than the 709. WATFOR was a combination monitor and fortran compile and execute environment. It would be loaded as a single step by the 360 job scheduler (ten second plusq elapsed time process) ... and then it would process a batch of student fortran jobs at one time .. typically a tray of cards ... maybe 2000-3000 card ... where a typical student job was 30-50 cards ... possibly 50-100 student fortran jobs in single load of WATFOR. What had previously been 30-45 minutes elapsed time was possibly now only 15-20 seconds.

during this period ... somebody wrote an interactive monitor (online/os) ... that loaded and stayed resident ... and would accept commands from the operator's console ... and supported the execution of some number of functions via directly kernel calls w/o having to invoke the job scheduler.

following is part of old presentation that i made at an IBM user group meeting on work that I had done while an undergraduate:
https://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14

the OS MFT14 work included careful placement of high usage files & records on disk in order to optimize arm motion.

the cp/67 work involved rewriting a lot of the pathlengths (lots of places i got a hundred fold improvement, overall the pathlengh improvement was between five and ten times) as well as redesigning and inventing new resource allocation algorithms. misc. refs:
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Mainframe not a good architecture for interactive workloads

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe not a good architecture for interactive workloads
Newsgroups: bit.listserv.ibm-main
Date: Tue, 27 Jan 2004 17:08:18 GMT

IBM-MAIN@ibm-main.isham-research.com (Phil Payne) writes:
Yes, indeed - but it was supported by a raft of RPQ hardware features such as the Airlines Control Buffer on the 2314.

It wasn'r really viable without them, and they in turn provided design and experience input into MANY things that later became mainstream.

the big thing about the disk controller RPQ was to provide fine-grain, cross-system locking in a loosely-coupled environment w/o having to resort to device reserve/release. basically system could define some number of symbolic "locks" ... basically something pertaining to disk record number or PNR (passenger name record). within a single shared-memory complex ... fine-grain serialization could be handled with in-memory data structures .... however, moving to multiple processors in non-shared memory configuration ... the only shared-disk serialization was the device-level sharing was reserve/release which was a really heavy duty sledge hammer.

this wasn't particularly a interactive issue ... it was workload distribution, scaling and availability across multiple processors. it did have the characteristics that it was fine-grain, high efficiency locking.

the IBM HONE system .... basically scaled online systems that supported all the field, sales, marketing, & branch people in the world. In the late 70s, all of the US HONE centers were consolidated at a single location in California and created possibly the largest single image operation in existance at the time. for sharing disks across large number of processors, one of the HONE support people in Uithoorne had developed a protocol used at login/logoff for disks w/o having to resort to reserve/release. Basically a cyliner bitmap was placed on cylinder zero and a CCW sequence was defined that emulated the mainframe compare&swap instruction (i.e. clever use of search commands). Compared to the ACP RPQ, it had the disadvantage of constantly moving the arm to cylinder zero (where the ACP RPQ basically did the locking & serialization using special memory in the shared disk controller).

misc. HONE refs:
https://www.garlic.com/~lynn/subtopic.html#hone

one of the things specific for light-weight tasking was/is SRBs ... which I believe were driven into the MVS kernel by the IMS people.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Mainframe not a good architecture for interactive workloads

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe not a good architecture for interactive workloads
Newsgroups: bit.listserv.ibm-main
Date: Tue, 27 Jan 2004 17:41:06 GMT

for acp dasd rpq, look for things like: TR 02.859 "Limited Lock Facility in a DASD Control Unit" Behman, DeNatale, Shomer (Oct. 1979)

search engine turns up few references to the above ... one is:
http://portal.acm.org/citation.cfm?id=130305&coll=portal&dl=ACM&CFID=16234177&CFTOKEN=48510308

one of the issues in ibm strategy ... was that it required sharing at the control unit level ... since that was where the record serialization locks were kept ... and that string-switching allowed for sharing below the control unit level.

in that time-frame, my wife (she was only five years old at the time) was in pok responsible for loosely-coupled architecture and wrote/invented the Peer-Coupled Shared Data architecture document ... which got a lot of push back because there was a big attempt to force all "communication" thru vtam. except for some stuff in ims hot-standby ... it wasn't until sysplex that you started to see much results from her efforts.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Mainframe not a good architecture for interactive workloads

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe not a good architecture for interactive workloads
Newsgroups: bit.listserv.ibm-main
Date: Tue, 27 Jan 2004 20:32:54 GMT

George.Henke@ibm-main.aig.com (Henke, George) writes:
A large mainframe health insurance company (for whom I did some capacity planning last year) discovered that rhey were having trouble making their nightly batch window.

Their business was growing and it was evident that they would soon be unable to process their normal batch workload in the 24 hour window.

It was not so much a question of more MIPs, etc, but rather the design of a very inefficient batch program which no one wanted to touch; a lot of spaghetti code.

So they are remediated the code to route the batch transactions through CICS as online transactions.

They realized that there was nothing that the batch job was doing that could not be done by the online CICS system simply by rerouting the workload. The online CICS system up to that time had been primarilly inquiry only.

This raised the question, at least in my mind, why have batch anymore at all?

nearly ten years ago ... we saw an application that would take about an hour for daily processing ... running batch sequential in/out .... which would have taken two weeks elapsed time if converted to standard random using any of the RDBMS implementations (i.e. daily processing taking two weeks elapsed time) ... and monhtly processing was about 20hrs batch sequential vis-a-vis a projected two years elapsed time for interactive/random; ... aka about 20times for sequential & CPU utilization ... vis-a-vis more like 50times (two weeks to 100 weeks) for random.

the sequential in/out can approach cpu utilization as the bottleneck ... as opposed to (random) i/o. there are some number of "in-core" implementation databases that are claiming 10:1 performance over any standard RDBMS with all records totally cached (i.e. even when the standard RDBMS has all records in memory). there are some hybrid implementations that do stuff like pointer swizzling ... i.e. some sort of record lookup if not in memory ... but direct address when in memory.

a lot of batch stuff can optimize around sequential (even disk to disk ... with totally different disk arms) .... where-as interactive & random arrival just about forces you to some sort of random access database.

any batch to interactive might also imply sequential to random as well as difference between i/o requests total contained within the application vis-a-vis interacting with some sort of database manager.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

AMD/Linux vs Intel/Microsoft

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: AMD/Linux vs Intel/Microsoft
Newsgroups: comp.arch
Date: Wed, 28 Jan 2004 16:48:34 GMT

"Stephen Fuld" writes:
The point was that, at least at the time, OS/360 *Couldn't* do it without loading a program. You had to load a program, any program, in order to get the OS (which actually did all the work) to delete a file.

and therefor the infamous IEFBR14 ... started out a one instruction program that had a half-dozen bug fixes over the years (supposedly the program with the largest ratio of fixes per instructions).

standard program calling sequence was
BALR R14,R15

.. aka load entry point address into register 15 and perform branch and link ... which saved in register 14 the address following the BALR and branched to address in register 15. this convention was used for both initial program invokation as well as any sort of library and subroutine calls.

IEFBR14 then contained a single instruction:
BR R14

branch to the address in register 14; which was return to caller ... aka the system.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Mainframe not a good architecture for interactive workloads

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe not a good architecture for interactive workloads
Newsgroups: bit.listserv.ibm-main
Date: Wed, 28 Jan 2004 17:18:33 GMT

shmuel+ibm-main@ibm-main.Patriot.net (Shmuel Metz , Seymour J.) writes:
The folks at Cambridge might not agree. But you might argue that the 2067 wasn't really part of the product line.

(at least the simplex/uniprocessor) 360/67 was a 360/65 with a dat box .... (dynamic address translation) so that it could provide virtual memory. the machine acted in all respects like a 360/65 ... unless you loaded a PSW with virtual address bit on ... and then it acted like a 360/65 except the addresses were run thru virtual address translation.

channels, interrupts, i/o commands, etc ... were all the same as 360/65. some number of places ran standard os/360 and never utilized the dat hardware. boeing huntsville did a modified os/360 release 13 MVT that turned on the DAT bit in the PSW ... not to do actual paging ... but because they were had long running 2250 (large vector display) interactive jobs that eventually had memory fragmentation. DAT was used as a work around to address MVT's memory fragmentation problem with long running applications.

summer that I worked at boeing helping with initial creation of BCS ... the newly formed BCS operation installed a new 360/67 for running CP/67 (BCS charter was taking over all boeing dataprocessing operations ... at the time BCS had a 360/30 and 360/67 ... and were to take over places like renton datacenter which had couple football fields of 360s and other things and the new 747 plant had nearly as large a datacenter). That summer, the boeing huntsville 360/67 was moved up to seattle to the military/aerospace building.

in any case, interactive difficiencies with 360 mainframes weren't so much hardware issues ... but fundamental characteristics of specific operating system implementation

postings from a slightly related thread running over in comp.arch
https://www.garlic.com/~lynn/2004.html#39 AMD/Linux vs Intel/Microsoft
https://www.garlic.com/~lynn/2004.html#40 AMD/Linux vs Intel/Microsoft
https://www.garlic.com/~lynn/2004.html#41 AMD/Linux vs Intel/Microsoft
https://www.garlic.com/~lynn/2004.html#48 AMD/Linux vs Intel/Microsoft

misc. cambridge related postings:
https://www.garlic.com/~lynn/subtopic.html#545tech

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

previous, next, index - home