2006 Newsgroup postings (07/07 - 07/27) Lynn Wheeler

2006 Newsgroup Postings (07/07 - 07/27)

The System/360 Model 20 Wasn't As Bad As All That
The System/360 Model 20 Wasn't As Bad As All That
The System/360 Model 20 Wasn't As Bad As All That
Not Your Dad's Mainframe: Little Iron
The System/360 Model 20 Wasn't As Bad As All That
Not Your Dad's Mainframe: Little Iron
Not Your Dad's Mainframe: Little Iron
Linux mainframe game machine
Not Your Dad's Mainframe: Little Iron
Not Your Dad's Mainframe: Little Iron
Not Your Dad's Mainframe: Little Iron
Not Your Dad's Mainframe: Little Iron
Google Architecture
Not Your Dad's Mainframe: Little Iron
RCA Spectra 70/25: Another Mystery Computer?
Old IBM protocol IBM 1006
On the 370/165 and the 360/85
The System/360 Model 20 Wasn't As Bad As All That
The System/360 Model 20 Wasn't As Bad As All That
Improving 360 Addressing
The System/360 Model 20 Wasn't As Bad As All That
The System/360 Model 20 Wasn't As Bad As All That
sorting was: The System/360 Model 20 Wasn't As Bad As All That
sorting was: The System/360 Model 20 Wasn't As Bad As All That
sorting was: The System/360 Model 20 Wasn't As Bad As All That
sorting was: The System/360 Model 20 Wasn't As Bad As All That
sorting was: The System/360 Model 20 Wasn't As Bad As All That
sorting was: The System/360 Model 20 Wasn't As Bad As All That
Key exchange
CRAM, DataCell, and 3850
CRAM, DataCell, and 3850
CRAM, DataCell, and 3850
The System/360 Model 20 Wasn't As Bad As All That
CRAM, DataCell, and 3850
Not Your Dad's Mainframe: Little Iron
The very first text editor
The very first text editor
History: How did Forth get its stacks?
Linux - Our Saving Grace?
sorting
Identity Management Best Practices
Tek 4010, info and prices
Why is zSeries so CPU poor?
MTS, Emacs, and... WYLBUR?
Any resources on VLIW?
sorting
Why is z series so CPU poor?
Any resources on VLIW?
Any resources on VLIW?
Not Your Dad's Mainframe: Little Iron
stacks: sorting
stacks: sorting
the more things change, the more things stay the same
the more things change, the more things stay the same
MD5 for z/OS?
The very first text editor
AT&T Labs vs. Google Labs - R&D History
The very first text editor
Copy protection
System/360 Prototype
How Many 360/195s and 370/195s were shipped?

The System/360 Model 20 Wasn't As Bad As All That

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Fri, 07 Jul 2006 13:33:54 -0600

eugene@cse.ucsc.edu (Eugene Miya) writes:
I don't know about you guys but the 1403 printer I used barely had the ability to print lower case (TN train). I did see a 3800 later.

1403 was from 1401 comptuer and adopted for 360. there were several 1403 models. 3211 printer followed the 1403 ... before the 3800 came along in the mid-70s. part of the issue was that datacenters sometimes only loaded TN train for special print jobs ... since the non-lower-case chain would print much faster (i.e. the characters were repeated more often ... so the latency for specific character slug to come under hammer was less).

following from old posting mentioning 3800
https://www.garlic.com/~lynn/2005f.html#48 1403 pirnters

note that this was much more "personal" laser printer. from the mid-70s, there had been the 3800 datacenter laser printer ... which had paper feed rates measured in feet per second. some datacenters bypassed the boxed paper feed ... and had huge paper rolls feeding directly into 3800 (4-5 ft in diameter). this shouldn't be confused with the later 3820 laser printer ... which was desktop unit.

minor ref:
http://www-03.ibm.com/ibm/history/exhibits/vintage/vintage_4506VV3103.html

from above:
The IBM 3800 laser-electrophotographic printer of 1975 had a speed of 20,000 lines a minute in preparing bank statements, premium notices and other high-volume documents. Laser beam paths were altered millions of times a second and were reflected from an 18-sided mirror that spun at 12,000 revolutions per minute. (VV3103)

... snip ...

some pictures:
http://ukcc.uky.edu/~ukccinfo/ibm3800.html
http://www-03.ibm.com/ibm/history/history/year_1976.html
http://pw1.netcom.com/~zmoq/pages/ibm370.htm

The System/360 Model 20 Wasn't As Bad As All That

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Sat, 08 Jul 2006 09:14:15 -0600

ArarghMail606NOSPAM writes:
Not entirely. The 1403 came in a bunch of different models. I don't know, but don't think that the models that could be hung on a 14xx could be hung on a 360. From the 1400 series books that I have, the 1403 models 1, 2, 3, 4 & 5 could be used on 1401/40/60 system. The only 1403 I ever saw on a 360 was a 1403-N1, connected via a 2848? 2484? control unit.

My first student job was to port a 1401 MPIO program to 360/30. MPIO did the unit record (cards) to tape and tape to unit record (print/punch) front end for the univ. 709. For a while they had both the 1401 and the 360/30 side-by-side ... and then they removed the real 1401 and would switch the 360/30 back-and-forth between 360 mode and 1401 hardware emulation mode.

controller reference:
http://www.beagle-ears.com/lars/engineer/comphist/ibm_nos.htm

from above:
2803 Tape Control Unit for S/360.

Used to attach 2401 drives.

2821 Unit Record Preipheral Control Unit for S/360. Used to attach 1403 and 2540 to multiplexer channel. Typically, the 1052 console typewriter would be at I/O address 009, the printer would be at 00F and a second printer at 00E.

2822 Tape reader control unit used to attach 2671 to S/360.

2841 DASD Control Unit for S/360.

Used to attach 2303 drum, 2311 disk and 2321 Data Cell.

2848 Display cluster controller for 2260 display heads.

Used an acoustic delay line to hold the screen buffer. The character generator used a magnetic core ROM to hold the character dot matrix lookup table.

... snip ...

1401 reference:
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP1401.html

In the above, it talks about 1403 operating at 600 lines/minute. I think this is 1403-7(?) ... it still had manual cover lift and the paper box feed was exposed.

The 360/30 had a 1403-N1 that operated at 1100 lines/minute, and had a hydraulic lift cover ... that completely enclosed the paper box feed. The top of the 1403-N1 was convenient height for placing things (coffee cups, card trays, etc), however, the 1403-N1 had this habit of automatically raising the cover when it ran out of paper. This top was hinged on the back so as the cover raised, the top went from horizontal to nearly veritical position.

The univ. 360/30 had 1052-7 operators console at address '009', the 2540 card reader at address '00C', the 2540 punch at address '00D', and the 1403 at address '00E'.

For the MPIO port, I got to design and implement my own stand-alone monitor, interrupt handlers, device drivers, storage management, task management, etc.

previous 1403 post
https://www.garlic.com/~lynn/2006n.html#0 The System/360 Model 20 Wasn't As Bad As All That

The System/360 Model 20 Wasn't As Bad As All That

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Sat, 08 Jul 2006 09:33:24 -0600

eugene@cse.ucsc.edu (Eugene Miya) writes:
But IBM was more a set of fiefdoms back then as it is now. It's harder for newer gens. to think about renting computers as they were harder to maintain back then for their expense. Security even back then was minimal despite what Lynn says. Computers weren't given host or node names back then.

different operating systems were structured in different ways ... most of the "batch" systems tended to have minimal security, in part because there was little direct access to the actual machine by the people using them.

the time-sharing systems
https://www.garlic.com/~lynn/submain.html#timeshare

tended to have somewhat more robust security ... and, in fact, saw some uses in organizations that tended to have somewhat stringent security issues. this has a reference to some use from the late 60s and early 70s:
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

I've repeated several times the effort at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

where the "unannounced" 370 virtual memory was emulated on the science center's 360/67. this had some number of issues since the corporation treated the unannounced 370 virtual memory as extremely sensitive corporate information ... and the science center's 360/67 was also providing online service to a number of non-employees in the boston area, including some number of students from various boston area institutes of higher education (bu, mit, harvard, etc).

another activity was that in the initial port apl\360 to cms\apl on the cambridge system,
https://www.garlic.com/~lynn/subtopic.html#hone

it opened up the APL workspace size from something like 32kbytes (real) to several megabytes (virtual). the corporate hdqtrs people found it attractive for doing business modeling and had the absolutely most sensitive of all corporate information loaded on the cambridge machine so they could do business modeling remotely from corporate hdqtrs. Being able to provide the highest level of data protection was a real issue ... especially with all the non-employee and student access to the same machine concurrently.

misc. past posts mentioning the effort virtualizing unannounced 370 virtual memory ... which was also one of the first distributed development projects using the internal network (between cambridge and endicott) ... and of course the cambridge host name was cambrdige:
https://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2004b.html#31 determining memory size
https://www.garlic.com/~lynn/2004d.html#74 DASD Architecture of the future
https://www.garlic.com/~lynn/2004p.html#50 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2005g.html#17 DOS/360: Forty years
https://www.garlic.com/~lynn/2005j.html#50 virtual 360/67 support in cp67
https://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
https://www.garlic.com/~lynn/2006e.html#7 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT
https://www.garlic.com/~lynn/2006l.html#21 Virtual Virtualizers

past posts mentioning the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

Not Your Dad's Mainframe: Little Iron

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Not Your Dad's Mainframe: Little Iron
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 08 Jul 2006 10:07:45 -0600

Dave Jones wrote:

http://blogs.businessweek.com/the_thread/techbeat/archives/2006/07/not_your_dads_m.html#more

While z/VM isn't explicitly mentioned in the blog entry, I do suspect that the Linux images the gamers are using are VM hosted. Who was it that first ran StarTrek on VM or TSO? I guess they were really ahead of their time. :-)

well here is a recent posts about some early security issues:
https://www.garlic.com/~lynn/2006n.html#2 The System/360 Model 20 Wasn't As Bad As All That

and one of the references from the above:
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

another early mention about the origins of the web and a couple gov. installations (including the first web site outside of europe)
https://www.garlic.com/~lynn/2006m.html#55 The System/360 Model 20 Wasn't As Bad As All That

and of course there is the story about the CERN CMS/TSO bake-off from circa 1974 and the resulting report to SHARE. It turned out that copies of the SHARE report available internally inside of the corporation got labeled "Confidential - Restricted" (i.e. need to know only) ... since they wanted to limit employee access to the CMS/TSO comparison information.

For games, how 'bout Adventure?

Tymshare was one of the early cp/cms commercial time-sharing service bureaus
https://www.garlic.com/~lynn/submain.html#timeshare

and they started offering "vmshare" online computer conferencing to SHARE in the mid-70s ... archive can be found here:
http://vm.marist.edu/~vmshare/

I was dealing with tymshare on regular basis ... including cloning the vmshare files and making them available on various internal systems ... including HONE ... which was the cp/cms based online service of all marketing, sales, and field people world-wide
https://www.garlic.com/~lynn/subtopic.html#hone

In any case, tymshare had port of adventure from pdp10 to cms ... and I acquired a copy and made it available internally ... which resulted in some amount of problems. I would distribute the executable internally ... but i would also send the source to anybody that could prove they had acquired all points.

misc. past post mentioning adventure
https://www.garlic.com/~lynn/98.html#56 Earliest memories of "Adventure" & "Trek"
https://www.garlic.com/~lynn/99.html#52 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
https://www.garlic.com/~lynn/99.html#83 "Adventure" (early '80s) who wrote it?
https://www.garlic.com/~lynn/99.html#84 "Adventure" (early '80s) who wrote it?
https://www.garlic.com/~lynn/99.html#169 Crowther (pre-Woods) "Colossal Cave"
https://www.garlic.com/~lynn/2000b.html#72 Microsoft boss warns breakup could worsen virus problem
https://www.garlic.com/~lynn/2000d.html#33 Adventure Games (Was: Navy orders supercomputer)
https://www.garlic.com/~lynn/2001m.html#14 adventure ... nearly 20 years
https://www.garlic.com/~lynn/2001m.html#44 Call for folklore - was Re: So it's cyclical.
https://www.garlic.com/~lynn/2001n.html#0 TSS/360
https://www.garlic.com/~lynn/2002d.html#12 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2002m.html#57 The next big things that weren't
https://www.garlic.com/~lynn/2003f.html#46 Any DEC 340 Display System Doco ?
https://www.garlic.com/~lynn/2003i.html#66 TGV in the USA?
https://www.garlic.com/~lynn/2003i.html#69 IBM system 370
https://www.garlic.com/~lynn/2003l.html#40 The real history of computer architecture: the short form
https://www.garlic.com/~lynn/2004c.html#34 Playing games in mainframe
https://www.garlic.com/~lynn/2004f.html#57 Text Adventures (which computer was first?)
https://www.garlic.com/~lynn/2004g.html#2 Text Adventures (which computer was first?)
https://www.garlic.com/~lynn/2004g.html#7 Text Adventures (which computer was first?)
https://www.garlic.com/~lynn/2004g.html#49 Adventure game (was:PL/? History (was Hercules))
https://www.garlic.com/~lynn/2004g.html#57 Adventure game (was:PL/? History (was Hercules))
https://www.garlic.com/~lynn/2004h.html#0 Adventure game (was:PL/? History (was Hercules))
https://www.garlic.com/~lynn/2004h.html#1 Adventure game (was:PL/? History (was Hercules))
https://www.garlic.com/~lynn/2004h.html#2 Adventure game (was:PL/? History (was Hercules))
https://www.garlic.com/~lynn/2004h.html#4 Adventure game (was:PL/? History (was Hercules))
https://www.garlic.com/~lynn/2004k.html#38 Adventure
https://www.garlic.com/~lynn/2004k.html#56 Xah Lee's Unixism
https://www.garlic.com/~lynn/2004m.html#20 Whatever happened to IBM's VM PC software?
https://www.garlic.com/~lynn/2005c.html#45 History of performance counters
https://www.garlic.com/~lynn/2005h.html#38 Systems Programming for 8 Year-olds
https://www.garlic.com/~lynn/2005k.html#18 Question about Dungeon game on the PDP
https://www.garlic.com/~lynn/2005k.html#41 Title screen for HLA Adventure? Need help designing one
https://www.garlic.com/~lynn/2005l.html#16 Newsgroups (Was Another OS/390 to z/OS 1.4 migration
https://www.garlic.com/~lynn/2005u.html#15 Fast action games on System/360+?
https://www.garlic.com/~lynn/2005u.html#25 Fast action games on System/360+?
https://www.garlic.com/~lynn/2005u.html#28 Fast action games on System/360+?

The System/360 Model 20 Wasn't As Bad As All That

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Sat, 08 Jul 2006 14:11:47 -0600

eugene@cse.ucsc.edu (Eugene Miya) writes:
I think the character set would have been called pica type (12 pt). I never dealt with the ALA until the 90s, but was aware of them and have attended ALA meetings.

I can rememebr UCSB (ARPA site host #3 because of Glenn Culler) before and after the TN train. I used it for Club mailing list gummed labels. That was mid-70s. I think I saw my first 3800 when I was working for JPL located at Caltech part time and Tech had a 3800, but I never used it.

Gary Starkweather (ex-PARC, Apple, now MS) gave the first Museum talk at Moffett on the 1st laser printer and a 30 Mb/s data link using Edmund Scientific parts. He mentioned the history leading up to the IBM 3800. I am not certain we taped that, but that was an awesome talk.

The only people who knew about fonts in the computer world in 1975 were basically PARC and Bell Labs. Knuth had not yet started TeX and Metafont (I just got a note from him in Oxford). People don't realize that word processing and document processing weren't wide spread in that era. Those guys produced very impressive papers at that time which made every one else in CS jealous. Long stories there.

2741 had a number of different fonts as different typeballs ... cms script ... originally runoff-like "dot" commands ... but then GML
https://www.garlic.com/~lynn/submain.html#sgml

was invented at the science center in 1969 and GML support was added to cms script. when different font was specified in a script document ... it had feature that would pause the 2741 to allow the user to change the typeball.

Some number of final draft quality documents were produced on 2741 using (new) film ribbon ... rather than standard fabric ribbon (film ribbon resulted in much sharper edge in the typed characters).

3800 came out in 1975 ... previous post reference
https://www.garlic.com/~lynn/2006n.html#0 The System/360 Model 20 Wasn't As Bad As All That

and 3800 reference here:
http://www-03.ibm.com/ibm/history/exhibits/vintage/vintage_4506VV3103.html

and essentially script/gml stuff that had been used for 2741 typeball font specification, was mapped to 3800 font capability.

Not Your Dad's Mainframe: Little Iron

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Not Your Dad's Mainframe: Little Iron
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 08 Jul 2006 17:51:52 -0600

Dave Jones wrote:

http://blogs.businessweek.com/the_thread/techbeat/archives/2006/07/not_your_dads_m.html#more

While z/VM isn't explicitly mentioned in the blog entry, I do suspect that the Linux images the gamers are using are VM hosted. Who was it that first ran StarTrek on VM or TSO? I guess they were really ahead of their time. :-)

re:
https://www.garlic.com/~lynn/2006n.html#3 Not Your Dad's Mainframe: Little Iron

... part II:

note that vm/4341 saw big explosion in use ... small to medium size customers as well as leading edge use for things like departmental computers ... with some companies ordering them in quantities of 100s.

there was a corresponding explosion internally in vm/4341s which helped contribute to there being nearly 1000 nodes on the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

on 1/1/83 ... which was the great switch-over of the arpanet to internetworking protocol.
https://www.garlic.com/~lynn/subnetwork.html#internet

at that point there was supposedly something like 100 networking IMPs and close to 255 nodes ... however possibly half of those "nodes" may have been terminal server IMPs (aka telecommunication control unit). a couple posts
https://www.garlic.com/~lynn/2006k.html#40 Arpa address
https://www.garlic.com/~lynn/2006k.html#42 Arpa address
https://www.garlic.com/~lynn/2006l.html#29 Mainframe Linux Mythbusting

and for really little iron ... recent post mentioning xt/370
https://www.garlic.com/~lynn/2006m.html#56 DCSS

Not Your Dad's Mainframe: Little Iron

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Not Your Dad's Mainframe: Little Iron
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 08 Jul 2006 23:44:41 -0600

Ed Finnell wrote:
There were the 9370's as node machines. We had one for our supercomputer node for a little while before the big-I got commercial. Then we got a 3090-400e and darned if it didn't have four of the buggers inside the 9032...

re:
https://www.garlic.com/~lynn/2006n.html#3 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006n.html#5 Not Your Dad's Mainframe: Little Iron

around 1980, a project started in pok to use a 4331 running a highly customized vm/370 release 6 as the service processor ... i.e. ios3270 was used for the service processor menu screens. by the time the 3090 shipped, the "service processor" was upgraded to a pair of 4361s.

Linux mainframe game machine

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Linux mainframe game machine....
Newsgroups: bit.listserv.vmesa-l
Date: Sat, 08 Jul 2006 23:48:40 -0600

Tom Duebush wrote:
I had a Star Trek game written in PL/1 that ran under TSO, back in the '74 time frame.

I learned a lot. Not just gaming, but how to limit the number of users based on processor utilization. How to keep everyone from copying my load module (the systems people calculated that, effectively, a couple 3330-11 packs were full with copies of my game. So I had to make the "copies", unusable (just checked what library it was called from).

Ahhh, to have that much free time again.... Now a days, I guess that is called.....retirement<G>

wikipedia star trek entry
https://en.wikipedia.org/wiki/Star_Trek_%28text_game%29

star trek history page
http://www3.sympatico.ca/maury/games/space/star_trek.html

PDP1 had a starwars game (on graphics tube). somebody at the cambridge science center
https://www.garlic.com/~lynn/subtopic.html#545tech

ported it in the late 60s to 2250m4 (i.e. 2250 with 1130). two player game with the keyboard split into left and right with keyboard keys used for controls. my kids use to come in on weekends to play it.

postings in similar thread on bit.listserv.ibm-main
https://www.garlic.com/~lynn/2006n.html#3 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006n.html#5 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006n.html#6 Not Your Dad's Mainframe: Little Iron

Not Your Dad's Mainframe: Little Iron

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Not Your Dad's Mainframe: Little Iron
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
CC: IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU>
Date: Sun, 09 Jul 2006 07:46:12 -0600

Anne & Lynn Wheeler wrote:
around 1980, a project started in pok to use a 4331 running a highly customized vm/370 release 6 as the service processor ... i.e. ios3270 was used for the service processor menu screens. by the time the 3090 shipped, the "service processor" was upgraded to a pair of 4361s.

re:
https://www.garlic.com/~lynn/2006n.html#6 Not Your Dad's Mainframe: Little Iron

for a little ios3270 drift, an ios3270 version of the green card was done; here is a crude conversion from ios3270 to html
https://www.garlic.com/~lynn/gcard.html

for some of the ios3270 description see
https://www.garlic.com/~lynn/gcard.html#greencard

I had added the sense bytes section
https://www.garlic.com/~lynn/gcard.html#17

Real green cards didn't have sense byte section ... but the 360/67 "blue cards" do (I still have one) ... but didn't include 3380 or A220 information ... see the sense byte section.

I got involved with writing a drivers for HYPERchannel and A220 as channel extension circa 1980 for Santa Teresa lab. They were rapidly growing and bursting at the seams ... so 300 people from IMS were being moved to offsite, leased bldgs (bldgs 96 & 97). They were use to CMS local channel attach 3270s (tso and sna/vtam local and remote were found to be pretty intolerable). HYPERchannel/A220 provided for channel extension over T1 microwave link.

there was T3 collins digital radio between bldg. 90/stl and bldg. 12 on the san jose plant site ... via a repeater tower on the hill above stl. the roof of bldg. 12 then had line-of-site to roof of bldg. 96 ... bldg. 12 then had line-of-site to roof of bldg. 96. A T1 sub-channel was created on the T3 link to bldg. 12 ... and then a T1 microwave tail-circuit installed between bldg. 12 and bldg. 97.

The 300 relocated IMS people then got nearly cms "local" 3270 performance from their remote location to STL.

I then used HYPERchannel for computer-to-computer links in high-speed data transport project
https://www.garlic.com/~lynn/subnetwork.html#hsdt

I also wrote the RFC1044 driver (in my standard RFC summary, clicking on the ".txt=nnn" field retrieves the actual RFC)
https://www.garlic.com/~lynn/rfcidx3.htm#1044

for the standard mainframe tcp/ip product.
https://www.garlic.com/~lynn/subnetwork.html#1044

because of various issues, the standard mainframe tcp/ip product would saturate a full 3090 processor peaking out at 44kbytes/sec. thruput. In some tuning tests we did at cray research between a cray machine and a 4341-clone, rfc1044 support was sustaining 1mbyte/sec thruput using only a modest amount of the 4341-clone.

Not Your Dad's Mainframe: Little Iron

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Not Your Dad's Mainframe: Little Iron
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 09 Jul 2006 08:22:31 -0600

jmfbahciv@aol.com wrote:
ROTFLMAO. Oh, you cruel, cruel person. They didn't have address break to find the last point. That is how Real Men with Real Gear do it. :-)))

re:
https://www.garlic.com/~lynn/2006n.html#3 Not Your Dad's Mainframe: Little Iron

well, even tho it was fortran source, some miscreants disassembled the executable and found the secret to get around the first shift 100-move limit (and various other things)

cms users also had access to trace command that included support for 370 PER (program event recording) hardware. you could single step, address-compare-stop (i.e. run until execution hit a specific address), stop on specific storage allocation, etc.

one of the first persons that got all the points (and the source), ported to PLI and first did a 450 point version and then a 600(?) point version.

recent announcement mentioning latest version of the trace command and support for the latest version of PER hardware
http://www-03.ibm.com/software/os/zseries/catalog/zswcatalog.nsf/Content/zVM_ondemandbusinesswithzvm?OpenDocument
http://developer.osdl.org/dev/robustmutexes/src/fusyn.hg/Documentation/s390/Debugging390.txt

overview of current trace command
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HCSE4B11/2.558?SHELF=HCSH2A80&DT=20060516125606

Not Your Dad's Mainframe: Little Iron

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Not Your Dad's Mainframe: Little Iron
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 10 Jul 2006 09:54:23 -0600

jmfbahciv writes:
Was this feature available to the OS developers when they debugged the monitor? Could the set a trace and run in production mode and stopping when the conditions were met?

re:
https://www.garlic.com/~lynn/2006n.html#3 Not Your Dad's Mainframe:
https://www.garlic.com/~lynn/2006n.html#9 Not Your Dad's Mainframe:

check the command guide ... the trace instruction was "class g" ... general/all users ... unrestricted access.

since virtual machine capability was also provided, it was a standard development thru-out the corporation to do OS and monitor development in virtual machines and use the capability. it was common to run production and test in parallel. this has also evolved into LPARs where lots of the virtual machine capability has moved into the hardware.

now if you go back to 360 (& 360/67) ... 360s didn't have PER ... so you couldn't set up control registers under program control for stop on instruction address match, stop on storage alteration, single step, etc. However, the machine had some of those capabilities on the front panel under manual control.

so there was broad spectrum. if it was pure batch ... there wouldn't be a lot of disruption ... but if your production batch system was supporting online ... like a couple hundred thousand (or more) ATM machines ... it wasn't likely that they were going to look very kindly on such service interruptions.

Not Your Dad's Mainframe: Little Iron

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Not Your Dad's Mainframe: Little Iron
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers,bit.listserv.vmesa-l
Date: Mon, 10 Jul 2006 19:50:41 -0600

"Rostyslaw J. Lewyckyj" writes:
Well I had exposure, access, to an IBM MVT product called TESTTRAN which was sort of available on our system with assembler F and , if I remember correctly, Fortran G, both in batch and TSO. One had to compile/assemble with the TEST option, which produced and kept a variables symbol table and a statement location table. One could then set breakpoints, examine program values etc. etc. But it was very awkward to use, badly documented, and buggy. When I asked I was told that it wasn't developed because it wasn't used. Which I considered to be a very much a chicken and egg kind of argument.

I had a little exposure to TEST under our CMS systems. But as we didn't really support VM/CMS too well at TUCC&UNC I can't comment much except that I didn't find out much about what it was capable of.

huge amount of OS/360 TESTRAN was outputing all the (12-2-9) "SYM" cards as part of assemble/compile ... so that you effectively could support symbolic debugging. I don't know anybody that actually used it ... I remember having a TESTRAN manual at one point and running with option to generate SYM cards (just to see what they looked like) ... but never actually using it.

old post that has mention of "SYM" cards (as well as formats of most of the other 12-2-9 cards):
https://www.garlic.com/~lynn/2001.html#14 IBM Model Numbers

PER and TRACE command were initially "machine" level stuff ... hex addresses, hex locations ... etc .. not real symbolic stuff.

I wrote a debug tool in REX(X) called DUMPRX that eventually was used extensively internally and at one point by nearly all the (vm/cms) field support people
https://www.garlic.com/~lynn/submain.html#dumprx

that had some amount of symbolic capability

this has comment about locate command and symbolics (and testran) ... from 2001:
http://listserv.uark.edu/scripts/wa.exe?A2=ind0103&L=vmesa-l&D=0&P=39641

I had originally done "pageable" CP kernel function for cp67 3.1 the summer I did a stint with BCS in Seattle (i was still undergraduate) ... which didn't get released in product until vm370. Part of the thing that I did as part of the pageable CP kernel function was to capture the loader table symbolics (all the external entries) and write it out as part of the kernel image. this feature including the complete loader table symbolics as part of the (pageable) kernel image wasn't included in the pageable kernel stuff that went out in vm370 release 1. As a result, there were periodic games played with a compiled module frequently called DMKSYM ... that had symbolics for some amount of kernel external entries.

however, when i got around to doing dumprx, i recreated the capture of the complete loader table symbolics as part of saving the kernel image. Then the "locate" command was changed to use the complete loader table entries saved out in the pageable kernel (instead of DMKSYM) ... and other things were enhanced to utilize the actual loader table entries.

standard vm/cms postmortem kernel dump processing had facility of importing an image of the loader printed output. I modified the kernel dump process to initialize the dump image with a copy of the complete loader table image (from saving the original kernel image) as part of system startup (so postmortem dumps always had complete loader table information).

....

a little search engine use turns up a number of TESTRAN references, this has title of "A Survey of current debugging concepts"
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19690026235_1969026235.pdf

it looks somewhat like a cms/script document printed on 1403 with TN train (some of the rendering looks wavy ... which might be scanning the original, if not, then it isn't likely to have been 1403 output). It is dated August, 1969 ... and it has section 3-34 "TESTRAN, for IBM System/360"

I now some number of gov. installations had cp67 (and cms, and script, etc) in 69 ... but I don't know if Goddard had one(?).

The above does list TESTRAN reference as:
IBM Corporation. IBM System/360 Operating System TESTRAN. Systems Reference Library. Form C28-6648-0 File Number S360-37. February 1967

ref:
https://www.garlic.com/~lynn/2006n.html#3 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006n.html#5 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006n.html#5 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006n.html#8 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006n.html#9 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006n.html#10 Not Your Dad's Mainframe: Little Iron

Google Architecture

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Google Architecture
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 10 Jul 2006 22:39:17 -0600

Inside the Google-Plex
http://it.slashdot.org/story/06/07/10/216249/inside-the-google-plex
http://www.baselinemag.com/c/a/Infrastructure/How-Google-Works-1/

from above:
Google runs on hundreds of thousands of servers-by one estimate, in excess of 450,000-racked up in thousands of clusters in dozens of data centers around the world.

... snip ...

also ..

How Google Works
http://www.eweek.com/c/a/Mobile-and-Wireless/HP-TouchPad-Needs-68-Weeks-for-Additional-Shipments-142584/

Not Your Dad's Mainframe: Little Iron

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Not Your Dad's Mainframe: Little Iron
Newsgroups: alt.folklore.computers
Date: Mon, 10 Jul 2006 23:32:46 -0600

for afc n.g. readers ... a reply from somebody that appeared in the vmesa-l mailing list:
I never used TESTTRAN, but the VP/CSS debugger used the SYM cards, and that debugger was used heavily until the early to mid 90s. We ported moat of it to CMS, but never did all of the work to make it run in XA virtual machines so we when started to use XA and XC virtual machines for our developing work, we had to use TRACE and PER.

...

vp/css is the name of the ncss system ... their version of cp67 (several people left science center and joined ncss summer of 68):
https://www.garlic.com/~lynn/submain.html#timeshare

some recent postings mentioning ncss
https://www.garlic.com/~lynn/2006b.html#39 another blast from the past
https://www.garlic.com/~lynn/2006k.html#35 PDP-1
https://www.garlic.com/~lynn/2006k.html#36 PDP-1
https://www.garlic.com/~lynn/2006k.html#37 PDP-1
https://www.garlic.com/~lynn/2006k.html#39 PDP-1
https://www.garlic.com/~lynn/2006m.html#50 The System/360 Model 20 Wasn't As Bad As All That

ncss reference at the computer history webserver
http://www.computerhistory.org/corphist/view.php?s=select&cid=4

much longer description of ncss:
http://corphist.computerhistory.org/corphist

RCA Spectra 70/25: Another Mystery Computer?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RCA Spectra 70/25: Another Mystery Computer?
Newsgroups: alt.folklore.computers
Date: Tue, 11 Jul 2006 14:40:30 -0600

ArarghMail607NOSPAM writes:
I think that was used for the 360/370 card that plugged into a PC. AT/370 or some such.

code named "washington" ... initially announced as xt/370 ... then made available for at/370 ... recent post mentioning washington.
https://www.garlic.com/~lynn/2006m.html#56 DCSS

above reference also has lots of past URLs mentioning the machine

Old IBM protocol IBM 1006

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Old IBM protocol IBM 1006
Newsgroups: bit.listserv.ibm-main,bit.listserv.vmesa-l,alt.folklore.computers
Date: Tue, 11 Jul 2006 18:41:15 -0600

Charles Mills wrote:
Here's a good start:
http://listserv.uark.edu/scripts/wa.exe?A2=ind0509&L=ibmvm&P=8109

note in the above referenced archive ... it mentions transmission as reverse inverted
• ALC is transmitted "reverse inverted". For example, capital A is 0x31, but it's transmitted as 0x73. This makes it a major PITA to read off the wire.

my off-repeated story of doing our own mainframe terminal controller at the univ.
https://www.garlic.com/~lynn/submain.html#360pcm

and somebody writing an article blaming four of us for the mainframe pcm controller business.

the ibm mainframe channel interface had been reverse engineered and a channel interface controller card built for an interdata/3

the second or third bug we encountered was passing ascii from the interdata/3 (programmed to emulate 2702 over the channel interface to the mainframe) ... showed data was coming in all garbage. it took some time to realize that the linescanner on the interdata/3 was taking the leading bit off the line and storing it it in the high order bit position of the byte ... while the linescanner in the 2702 was taking the leading bit off the line and storing it in the low order bit position of the byte.

as a result "ascii" arriving in the mainframe memory from a 2702 (linescanner) was "bit-reversed" ... and the ibm translate tables were taking that into account.

On the 370/165 and the 360/85

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: On the 370/165 and the 360/85
Newsgroups: alt.folklore.computers
Date: Thu, 13 Jul 2006 11:02:30 -0600

seewebsite@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:
IBM took the 370/168, and implemented it in newer technologies, to produce the IBM 3033 computer.

I knew the AS/400 evolved out of the FS project, but hadn't remembered the details - that the System/38 was the predecessor of the AS/400.

It is interesting that the later IBM 3081 was *also* an FS outgrowth; the high-end FS prototype performing so well when 'emulating' a 370 that it became IBM's top-of-the-line 370.

not exactly 360/85 info (which I have no direct info)

there is some folklore that the pok group did 165->168->3033->3090

and the kingston group did 155->158->3081

along the way there was the 3031 and 3032 (in addition to the 3033).

the 303x line was differentiated by the "channel director" ... the 158 had integrated channels with the machine engine shared between 370 microcode and channel microcode. for the 303x, they packaged the 158 engine w/o the 370 microcode ... just the integrated channel microcode as the channel director. the 370/158 was then repackaged as the 3031 working with a channel director (i.e. effectively now a dual processor with two engines ... however one with only the 370 microcode and one with only the channel microcode). the 168 was repackaged as the 3032 to work with the channel director.

the 3033 started out as 168 wiring diagram mapped to denser and faster chip technology ... but only using the same number of circuits per chip as used in the 168 (meaning only about 20percent faster). because of competition and other issues, there was eventually some rework of the logic to use some of the additional circuits per chip ... eventually the 3033 was 50percent faster than 168 (approx. 4.5mips instead of 3.0 mips).

part of the 3033 folklore was that it was an extremely hurryup project after FS had been killed
https://www.garlic.com/~lynn/submain.html#futuresys

since so much corporate effort had been diverted to FS during that period ... that there was very little in the 370 pipeline (i.e. FS doctrine was that FS was going to completely replace 370).

the 3081 architecture code name was 811 ... extending 370 architecture to 31bit virtual addressing (not that the 360/67 previously had both 24-bit and 32-bit virtual addressing) and misc other features ... no FS features (the other stuff is pure rumor) ... just extending the 155/158 microcoded lineage to faster technology (while 165/168 lineage was much more hardwired).

The FS folklore is that the final nail in the FS coffin was a study by the houston science center that showed if FS architecture was implemented on the fastest, currently available technology (370/195), that 370/195 applications would have thruput of about 370/145 (somewhere around a factor of 20-30 times slowdown). optimized codes would peak around 10mips on 195 ... a lot of more conventional stuff ran around 5mips (no branch prediction or speculative execution, branches just drained the pipeline ... except for special case of looping within the pipeline buffer). 370/145 was in the .3mip to .5mip range.

3081 was going to be a multiprocessor offering only. initial 3081D had approx. two five mip engines. later 3081K had pair of approx. 7mip engines (14mips aggregate). because of some operating systems not having multiprocessor support (primarily TPF, the old airline control program), they were eventually forced to ship a single processor 3083. as an aside, prior to 3081, multiprocessors had been totally independent systems that got lashed together ... but could be separated and run as independent single processor complexes. they differentiated 3081 as being "dyadic" ... while it had two processors ... it couldn't be separated into two independent single processor systems (although there was 3084 which was essnentially a pair of 3081s).

a recent posting including an old discussion about some of the differences between the predominately microcode 3081 and the much more hardwired 3090 ("trout" in the following refers to 3090):
https://www.garlic.com/~lynn/2006j.html#27 virtual memory

The System/360 Model 20 Wasn't As Bad As All That

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Thu, 13 Jul 2006 18:41:50 -0600

Brian Inglis writes:
Ways of gaming the system still has to be taken into careful consideration for e-commerce applications, to ensure that even if internal policies and business rules are disseminated (such as by employee moves) no customer can take unfair advantage of the system. Of course, mistakes made by one customer, taken advantage of by another customer, is considered fair usage.

I had to do some fundamental stuff in the resource manager to avoid users gaming the system.
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

there is slightly related issue running recently about sox
https://www.garlic.com/~lynn/aadsm24.htm#35 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#36 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#39 Interesting bit of a quote

The System/360 Model 20 Wasn't As Bad As All That

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Fri, 14 Jul 2006 01:15:23 -0600

Brian Inglis writes:
They also sell/sold PC channel adapter cards: not sure how they packaged the bus and tag cable connections; they were big and the cables were not quite as rigid as thick wire ethernet!

adapter cable came out the back which then had connectors for bus&tag. PCCA card done in YKT ... emulated channel controller interface. couple past posts mentiong PCCA card from mid-80s
https://www.garlic.com/~lynn/2005r.html#2 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#17 Intel strikes back with a parallel x86 design

an "industrial/rack" pc/at with the pcca card was then sold as 8232 for mainframe tcp/ip support. but the way that ip was done for it, it required a lot of mainframe care&feeding ... it would burn a 3090 processor getting 44kbytes/sec.

I had added rfc 1044 support to mainframe tcp/ip support and in some tuning work at cray research between 4341-clone and cray machine got 1mbyte/sec sustained using only a modest amount of the 4341.
https://www.garlic.com/~lynn/subnetwork.html#1044

when i was an undergraduate, we had reverse engineered the ibm channel interface and built our on channel interface card for interdata/3 as part of emulating 2702 telecommunication controller. lots of past posts mentioning building plug compatible controller
https://www.garlic.com/~lynn/submain.html#360pcm

Improving 360 Addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Improving 360 Addressing
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 14 Jul 2006 12:57:18 -0600

Brian Inglis writes:
R13-R15 were used in the calling sequence. R0 and R1 were conventions used for some functions and system calls.

my trusty quick&dirty rendition of the old ios3270 "green card"

call/save/return conventions
https://www.garlic.com/~lynn/gcard.html#50

the "yy" register in the above save area chaining coding example is frequently R12.

The System/360 Model 20 Wasn't As Bad As All That

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Fri, 14 Jul 2006 13:08:08 -0600

Morten Reistad writes:
The concept of the batch job has been reborn, but in a timesharing cloak, as a "cron job". It is automated execution, but runs within the context of a timesharing system.

But all systems nowadays have an interactive or realtime flavour. The users, and/or the physical environment they serve demand that.

over time, it wasn't just the infrastructure that automated the start of an application ... but the whole paradigm that automated the care & feeding of an application during its execution.

i've recently mentioned having done a one week jad with the old taligent group ... about what it would take to add support for 7x24, industrial strength data processing.
https://www.garlic.com/~lynn/aadsm24.htm#20 On Leadership - tech teams and the RTFM factor

in the past, I've claimed that it can take 4-10 times the effort to transform a well debugged "interactive" application into a "service" application (that is capable of providing services and running unattended in 7x24 operation w/o human intervention) ... as it took to implement and debug the basic straight-line application.

slightly related to past postings mentioning assurance
https://www.garlic.com/~lynn/subintegrity.html#assurance

The System/360 Model 20 Wasn't As Bad As All That

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Sat, 15 Jul 2006 13:00:29 -0600

Joe Morris writes:
A way that some users could play "Beat the Clock" (does that reference say something about my age?) was to use the disk drives as a high-resolution timer: using a disk drive that spins at 3600 rpm (i.e., 60 rps), start a write operation sized to take just less than 1/60 second. When the write operation completes, set up a timer for 1/60 second and issue a WAIT. On an S/360 with the idiotic 60-Hz timer, you have done all of your calculations between timer ticks, and are thus charged for no CPU time. If you aren't using CPU time you stay at the head of the dispatch queue.

360/67 had high resolution time so that the low-order bit tic'ed at about 300*256 times/sec, approx every 13mics ... as opposed to tic'ing one of the higher order bits at lower resulution. the period of the 32bit location 80 timer stayed the same (approx 15.5hrs).

there were other ways that they gamed the system ... but i closed just about all of them ... initially with cp67 infrastructure rewrite i did as an undergraduate ... recent comment in this thread:
https://www.garlic.com/~lynn/2006n.html#17

and then later (when most of it was dropped in the cp67 to vm370 morph), re-introduced it for vm370 as the resource manager (11may76) ... recent 11may76 reference (dated 10may06):
https://www.garlic.com/~lynn/2006i.html#24

part of the infrastructure change (both cp67 and vm370) was tracking process recent resource consumption rate (as opposed to straight resource consumption) and adjusting execution order based on process resource consumption rate compared to the process's target resource consumption rate (with some finagling to handle edge conditions) ... with fair share being the default target resource consumption rate
https://www.garlic.com/~lynn/subtopic.html#fairshare

for a little drift when I got into doing high-speed data transport project (hsdt)
https://www.garlic.com/~lynn/subnetwork.html#hsdt

i also did a rate-based implementation. my assertion has been that the reason that window-based network implementations being much more prevalent was because most of the platforms from that period had such deplorable timer facilities. recent post that strayed into network rate-based control
https://www.garlic.com/~lynn/2006m.html#20

quick & dirty conversion of ios3270 greencard to html has details on the 370 64bit clock/timer. the 360 "low-resolution" location 80 timer was initially carried forward into 370 (but later dropped) ... but if you wanted higher resolution, you had to use the new 370 64bit clock and time facilities.
https://www.garlic.com/~lynn/gcard.html#16

the 360 32bit timer was defined at storage location 80 (x'50'), location x'54' and location x'4C' were "undefined". cp67 (to avoid "loosing" tics) ... saved current value at location x'54', stored a new value at location x'54' and then did an "overlapping" move instruction:
mvc x'4C'(8),x'50'

which moved the eight bytes starting at location x'50' to location x'4C', i.e. the current timer value at x'50' was moved to x'4C' and the new timer value at x'54' was moved to x'50', in one instruction w/o loosing a timer tic. then the difference was calculated between the value just moved into x'4C' and the value just previously saved from x'54' (which would have been the previous initial timer setting) ... before overlaying x'54' with the new timer value.

In the morph from cp67 to vm370 to use the higher resolution timers (effectively in timer registers ... not storage addressable), there was the possibility of loosing a timer tic ... since two separate instructions were required to save current value and then load new value; first doing a
STPT xxxxx

to save the current interval timer, followed by a
SPT yyyyy

to load the new value.

More detailed discussion of timers from esa/390 principles of operation:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/4.6?SHELF=EZ2HW125&DT=19970613131822

STPT, store cpu timer
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/10.47?SHELF=EZ2HW125&DT=19970613131822

SPT, set cpu timer:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/10.36?SHELF=EZ2HW125&DT=19970613131822

sorting was: The System/360 Model 20 Wasn't As Bad As All That

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: sorting was: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Sat, 15 Jul 2006 14:18:54 -0600

ArarghMail607NOSPAM writes:
At a PPOE, that sort of sorting used to drive me crazy. The computer system, which I programmed, sorted customer names in strict ASCII order. But the office manager (who originally came from manual systems) insisted on filing the hard copies as described above. It would sometimes take me 30 to 60 minutes to find a hard copy. And she would file company names that looked like personnel names as the last name. Things like "John M Smyth, & Co." under 'smith'.

in the late 70s, we were sitting around some drinking hole late one friday night trying to think of something that would help promote online computer use inside the company (for others than strickly professional programmers). we came up with the idea of online telephone book facilities (everybody looked up phone numbers).

the challenge was that the (lookup application) code had to be implemented in less a person week and the infrastructure and aministrative stuff was possibly another person week ... and the ongoing support operation had to be less than one or two person days a month (for all corporate phone books). this included periodic refresh of original source from the original corporate site owners, reformating and redistribution.

the typical online phone number lookup also had to be much faster than reaching for a paper copy (of purely local numbers) on the desk.

so the brain dead was to have the phone book as a sorted file and do a lookup using binary search. this was only border line acceptable, the search was updated to radix search based on measured first two letter frequency.

there are some number of issues with name representation ... and so some rules were created for canonical name representation. then the sort routine ... rather than directly using the name field as the sort key ... created a derived sort key from the name field based on the representation rules (however, all the records in the output file were in their original input format). then of course, the lookup routine had to convert the search argument into canonical format and also dynmacally convert each name field to canonical format as it checked for matches.

later we learned that there had been a corporate hdqtrs proposal for doing a centralized online phone lookup, with dedicated datacenter, 20-30 dedicated people and initial budget of $25m. our KISS solution decimated the corporate hdqtrs proposal.

sorting was: The System/360 Model 20 Wasn't As Bad As All That

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: sorting was: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Sat, 15 Jul 2006 19:03:07 -0600

krw writes:
I remember that. The PHBs were gaga when we could look up phone numbers in an instant. This became a problem because they wanted our (yet to be delivered) terminals. That was the one application that made it impotent for a PHB to have a terminal on his desk. Soon after they needed the flashiest hardware to read their PROFS email (gack!).

ref:
https://www.garlic.com/~lynn/2006n.html#22 sorting was: The System/360 Model 20 Wasn't As Bad As All That

in that period, getting a 3270 on your desk required VP approval and the terminals requests also had to go into the fall budget plan. then one short period there was non-linear change ... it became known that a couple of the senior executives had 3270s and were doing email ... and all of a sudden all executives and middle management had to also have their 3270; which wasn't provided for in the standard budget cycle ... management just pre-empted everybody else's 3270 in their organization (it all of a sudden became a status symbol and the thing to have on manager's desk).

the "PROFS" group put menu interface on some number of things and claimed the whole thing as their own (even given awards for developing the email processor). however, several of the items they actually picked up from other places ... which caused some amount of embarrassment when it was pointed out. the email processor had been a very early, redimentary version of VMSG. when the person actually responsible raised the issue ... there was an attempt to get the person fired. the funny thing was not only was his initials on the source ... but he had also included his initials in a hidden control field of every email sent.

in any case, because of the fall planning and VP approval scenario for terminals ... we did the business analysis that showed the three year amortized cost for a terminal (at external customer list price, rather than internal transfer cost) was less per month than a business phone ... which went on everybody's desk as a matter of course (and most of these terminals eventually had lifetimes well in excess of a decade, or in some cases, two decades).

once the terminal status symbol for managers and executives got started, it then continued on ... where it was common to find managers pre-empt the newest and most decked out PCs, PS2, etc ... for their desk (many terminal if they were turned on at all and ever used ... it was purely for terminal emulation for infrequent PROFs operation). there were numerous complaints of brand new PS2m80 with the fastest processors, max'ed out memory and largest display screen ... ordered for real work on real projects ... getting diverted to some manager's desk for their status symbol (where it might be used for PROFs email a couple times a week).

some old email from long ago and far away (the VMSG source "borrowed" by the profs group ... was a much earlier version than this)

Date: 03/12/79 18:04:00
To: wheeler

Think VMSG is almost in a state where it's finished apart from ENCRYPTION. So do you want the source ?

Unless of course you've found more bugs.

... snip ... top of post, old email index

Date: 03/12/79 10:47:14
From: wheeler

yes, send source. I'm still interested in placing in shared segment.

... snip ... top of post, old email index

Date: 04/03/79 08:58:13
From: wheeler

IPSASM is the main module of the IPS package (encryption). VMSG now has mods. to support various security/encrypting options by calling IPSASM. A CRDR will be coming out shortly which will read encrypted files. Also VMSG has new option to support sending ITIPS

... snip ... top of post, old email index

in the above, my reply 3/12/79 is nearly eight hrs earlier than the original ... because the original message was sent from eight time-zones away.

as an aside, the same person that did VMSG ... also did parasite and story; a few past parasite/story posts:
https://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2003i.html#73 Computer resources, past, present, and future
https://www.garlic.com/~lynn/2003j.html#24 Red Phosphor Terminal?
https://www.garlic.com/~lynn/2004e.html#14 were dumb terminals actually so dumb???
https://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2006.html#3 PVM protocol documentation found
https://www.garlic.com/~lynn/2006c.html#14 Program execution speed
https://www.garlic.com/~lynn/2006f.html#37 Over my head in a JES exit
https://www.garlic.com/~lynn/2006m.html#35 Draft Command Script Processing Manual

sorting was: The System/360 Model 20 Wasn't As Bad As All That

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: sorting was: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Sat, 15 Jul 2006 19:11:47 -0600

krw writes:
We (hardware design engineers) were using computers long before that. I was a spearhead in getting terminals moved from terminal rooms into our offices. I had one of the first 3277GAs in an office on Boardman Road (Blgd. 701). We did have to hook them up remotely over 8600bps modems, but that was till better than 2741s. By mid '77 pretty much everyone that wanted/needed a terminal had one in the office (though many were shared). By contrast, only Senior Engineers and above had "personal" 2741s. I used to use the office and 2741 of one of the most senior engineers (can't remember his name, but he was one of the inventors of the channel) and his terminal. The few times he came around he simply sat on the other side of his desk. ...great guy!

re:
https://www.garlic.com/~lynn/2006n.html#22 sorting was: The System/360 Model 20 Wasn't As Bad As All That
https://www.garlic.com/~lynn/2006n.html#23 sorting was: The System/360 Model 20 Wasn't As Bad As All That

something of an exception. the science center was different since we were doing all sorts of invention, etc.
https://www.garlic.com/~lynn/subtopic.html#545tech

not only did i get a personal 2741 in my office ... but from mar70 on, i also had personal 2741 at home. initially with just a plain second phone line ... but eventually the second home phone line was replaced with a standard corporate "tie" line.

sorting was: The System/360 Model 20 Wasn't As Bad As All That

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: sorting was: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Sat, 15 Jul 2006 21:02:41 -0600

krw writes:
Were these pre or post-Rolm phones? I'm sure we still have two- decade-old ROLM garbage still around. Single-duplex speaker phones in conference rooms, anyone?

re:
https://www.garlic.com/~lynn/2006n.html#22
https://www.garlic.com/~lynn/2006n.html#23

3270 terminal amortized business analysis was done late 70s ... long before rolm

and for some drift ... from long ago and far away ... a little rolm drift:

Date: 09/26/84 14:29:20
From: wheeler

just talked to xxxx ... who wanted to know what i know about what is going on at rolm. As an aside she mentioned that after the AT announcement, Rolm decided that PC/AT is strategic direction rather than S/1s and they will cancel their order for 900 S/1s.

... snip ... top of post, old email index

Date: 11/16/84 11:14:44
From: wheeler

just got back from rolm ... they have a number of 512k s/1s with high speed programmable interfaces, v.35, two 200meg hard disks, tape drives, & 370 channel attach (I was there looking for a couple of s/1s to send to hawthorn for the DBS project). Rolm needs to double check the serial numbers against their books next week to determine which specific machines have not been installed &/or any money paid for. They will know by the week of dec. 3rd which machine's we can possibly hijack ... do you want try for any out of Rolm???

Other than that, i've found IBM four "small" S/1s w/o channel attach &/or hard disks, two 512k S/1s w/o channel attach but with 200meg disk, and one 512k s/1 w/o channel attach but with 60meg hard disk. Do you want to try for any of these? Two of the 512k S/1s are packed and ready to be shipped back ... probably Monday morning ... so say now if you want them (the 512k S/1s apparently were configured for ADS ... & I don't know how to match the HONE list for YALE/IUP against the ADS list).

... snip ... top of post, old email index, HONE email

the first email refers to some people at rolm that I had known before the acquisition that were in the rolm datacenter organization ... and were trying to find out who might be making what decisions. the DGs that ROLM had been using were getting old and creaky and they had decided to migrate to S/1s as a platform (and placed an order for 900 S/1s).

i had been told that I had to demonstrate at least some ibm content in my high-speed data transport project
https://www.garlic.com/~lynn/subnetwork.html#hsdt

the "old time" telecommunication that would support even up to T1 (1.5mbits/sec us, 2mbits/sec european) was the 2701 from the 60s (approx. twenty years old). the only other choice was that FSD (federal systems division) had done an RPQ "zirpel" card for the S/1 for special federal bids (as upgrade to 2701, there was no standard "product" on the drawing boards before the early 90s). as a result, I was being forced to scrounge up some S/1s to use with zirpel cards (and the rolm 900 S/1s order had temporarily made s/1s impossible to get ... at least until rolm decided to change direction ... and I could then pick up several machines that were even still sitting crated in rolm hallways).

sorting was: The System/360 Model 20 Wasn't As Bad As All That

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: sorting was: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Sat, 15 Jul 2006 21:27:57 -0600

krw writes:
I always wondered what would happen if our customers saw how _we_ used our hardware.

my wife reminded me about the old adage about the children of the cobbler having no shoes.

part of the issue ... especially after FS
https://www.garlic.com/~lynn/submain.html#futuresys

a lot of the top executive possisions had come up from the DP division (sales & marketing) ... technical and engineering had lost some credability with the FS fiasco.

except for HONE ... the online (vm370-based) service providing support for world-wide field, sales, and marketing
https://www.garlic.com/~lynn/subtopic.html#hone

management and executives tended to have very little exposure to online computer use (starting with 370/115 & 370/125 ... HONE configurator was required for even placing a system order).

that was one of the things that led to the discussion about some application (online phone directory) that would attract management and executives to using online system as part of their every day experience.
https://www.garlic.com/~lynn/2006n.html#22
https://www.garlic.com/~lynn/2006n.html#23

to a large extent, the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

thru the 70s and much of the 80s had happen in spite of any corporate strategic policies and objectives. in fact, in the very early 80s, it came as a shock to quite a few executives that the internal network even existed (and that it had been larger than the arpanet/internet for just about the whole period).

at one point there was even a paper written by an academic type out of corporate hdqtrs that claimed proof that the internal network didn't exist. academia supposedly had proven that the type of distributed control operation implemented by the internal network required a massive amount of resources to implement (nearing the amount that had been written off in the failed FS effort) ... and after extensive study of all company budgeted activites for several year period ... no such funded activity could be identified.

sorting was: The System/360 Model 20 Wasn't As Bad As All That

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: sorting was: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Sun, 16 Jul 2006 08:09:26 -0600

krw writes:
VP approval was normal at the time. The '70s were *bad* economically. They certainly in the fall plan - I put them there. The necessary 9600bps modems were $10K a pair, and we allotted three terminals per 3270 and modem. ...and were happy with that. ;-)

re:
https://www.garlic.com/~lynn/2006n.html#23

the 70s weren't overall particularly bad ... however FS
https://www.garlic.com/~lynn/submain.html#futuresys

gave the corporation quite some problems. one issue was that there were several claims that any other company would have gone under if they had dumped as much money and effort (that went into FS) on an unsuccessful product that was then canceled w/o every being announced (i.e. claims that no other company in the computer biz could have survived a fiasco the magnitude of FS).

besides the direct financial downside of the resources that went into FS ... the indirect downside was that during FS ... nearly all non-FS activity was stalled/suspended.

as the company was recovering from the FS cancelation ... they found a lack of near term products in the pipeline .... your comment that 3081/811 was then started to be the next product offering but as 3081/811 continued to slip ... 303x was thrown in to try and fill the gap (there is folklore about the head of POK working in his office 1st shift and then playing cpu engineer 2nd shift on engineering 3033 processors).

...

however, in our terminal business analysis ... we attempted to show that VP approval for terminals was false economy. nobody was considering that VP approval was required for phones on desks ... and we showed that 3yr amortized cost of terminal was less than phone monthly cost (even using full list price rather than internal transfer costs).
https://www.garlic.com/~lynn/2006n.html#25

Key exchange

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Key exchange
Newsgroups: sci.crypt
Date: Sun, 16 Jul 2006 10:00:20 -0600

"John E. Hadstate" writes:
This pretty well describes how most cryptographic hashes are used to create keys. See your email for PDFs and diagrams on how to use hash functions to generate cipher keys from passwords.

there is similar stuff for "derived" keys ... i.e. financial industry derived unique key per transaction ... search on DUKPT ... for instance see reference to DUKPT & X9.24 in this old nist document:
http://csrc.nist.gov/CryptoToolkit/aes/pre-round1/comments.pdf

also transit systems with magstripe or "memory" chips ... and various other infrastructures have derived keys. there is sysetm-wide master key (for transit systems in each processor connected to turnstyles). the card is read containing account number and encrypted information. the combination of of the system master key and account number is used to calculate the card-specific derived key, the information is decrypted, updated, re-encrypted, and then written back to the card (systemic risk countermeasure to brute force attack on a single system-wide symmetric master key)

CRAM, DataCell, and 3850

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CRAM, DataCell, and 3850
Newsgroups: alt.folklore.computers
Date: Sun, 16 Jul 2006 13:49:00 -0600

seewebsite@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:
Neither the 3850 nor the DataCell was a roaring success for IBM, and Hypertape was particularly unsuccessful. Version II sold to two customers, one of them the IRS, and the only customer for Version I was Canada's equivalent of the IRS.

datacell was direct access .... i.e. applications selected records on strip (using BBHHCCR convention) and directly read/wrote the records.

3850(/MSS) were virtualized 3330 disk drives. there was pool of real 3330 disk drives ... managed as some larger number of virtual 3330 disk drives. access to a non-staged cylinder ... would result in a "fault" analogous to a page-fault. system then staged data from tape-to-disk. faults could be handled as either six cylinder units or full tape. virtual 3330 data was staged to/from 3850 tape reels ... managed by 3850 tape robot.
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3850.html

the 3850 tape reels were wide tape wrapped around a cylinder looking shape (2in diameter, 4in long, with 3in x 770in tape) ... which were managed by the 3850 tape robot and these "cylinder" tape reels resided in honycomb looking structure (a tape could hold half a 3330-1 or 1/4th of a 3330-11). part of the 3850 problem was tracking newer generation of disk drives. a later 3850 model was made available with faster and higher capacity 3350 drives but they were used to still simulate virtual 3330 drives.

emerging in that some time frame was purely software HSM ... i.e. hierarchical storage manager ... with (stk) tape robot systems using more traditional shapped tape reels. operating system HSM support would stage data to/from tape at a higher level abstraction (basically on per file bases) rather than at the lower level (virtual) hardware level.

I had done a backup/archive system that was deployed at several internal locations. This was eventually repackaged with a lot of PC and workstation clients and marketed as workstation datasave ... which then morphed into ADSM (adstar storage manager) and is now marketed as TSM (tivoli storage manager). misc. past posts:
https://www.garlic.com/~lynn/submain.html#backup

HSM evolved to include SMS (system managed storage) and newer generations of tape robots. SMS reference:
http://www.ibm.com/systems/storage/software/sms/smstour/smstour.html

In the same time frame, STK's "iceberg" virtual disk technology emerged, sort of a technology update of the 3850/mss. 3850/mss had been done by the Boulder lab ... so it is possible that some of the same people had moved down the road to STK and worked on iceberg. san jose had competitive effort with codenames like seastar and seahorse that had various schedule problems. a few posts mentioning iceberg, seastar, etc
https://www.garlic.com/~lynn/2002d.html#55 Storage Virtualization
https://www.garlic.com/~lynn/2004o.html#30 z/OS UNIX
https://www.garlic.com/~lynn/2006d.html#1 Hercules 3.04 announcement
https://www.garlic.com/~lynn/2006d.html#3 Hercules 3.04 announcement
https://www.garlic.com/~lynn/2006d.html#15 Hercules 3.04 announcement

Several gov. labs. developed various kinds of storage management systems. LANL developed one using IBM mainframe managing tape library and staging to large pool of disks ... non-IBM processors could access disks using HYPERchannel thru "remote device adapters". As part of the increased "technology transfer" activities in the late 80s and and early 90s (trying to get technology out of gov. installations and into commercial operation), the LLNL was marketed by General Atomics as "DataTree".

LLNL had developed a hierarchical storage management system ... and we ... in our cluster activities part of ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp

had funded the port to standard unix platforms and it was marketed on several platforms as "UniTree".

NCAR also had developed a storage system somewhat similar to LANL's. In addition to working with LLNL in the porting and marketing of "UniTree" ... we also worked with a NCAR spin-off called "Mesa Archival" to port NCAR's system to unix platform and market it.

I've also commented that NCAR's original implementation might be considered the original SAN (storage area network).

CRAM, DataCell, and 3850

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CRAM, DataCell, and 3850
Newsgroups: alt.folklore.computers
Date: Sun, 16 Jul 2006 16:11:50 -0600

Peter Flass writes:
Didn't the Datacell come first? I think it was announced with the first 360's, or soon thereafter. I'd guess CRAM at early 70s.

this reference
http://www.columbia.edu/cu/computinghistory/datacell.html

has the datacell being designed by shugart in early 60s and announced 1964
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_PH2321A.html

this lists NCR made CRAM available '62
http://www.techweb.com/encyclopedia/defineterm.jhtml?term=CRAM

from computer history museum
http://archive.computerhistory.org/resources/text/NCR/NCR.CRAM.1960.102646240.pdf

and RCA's RACE from late 60s
http://www.techweb.com/encyclopedia/defineterm.jhtml?term=RACE

CRAM, DataCell, and 3850

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CRAM, DataCell, and 3850
Newsgroups: alt.folklore.computers
Date: Sun, 16 Jul 2006 20:33:49 -0600

haynes@alumni.uark.edu (Jim Haynes) writes:
I remember seeing the RCA machine at the GE plant in that time frame, didn't realize any customer had actually bought one. People who saw it running tended to compare it to a chicken plucker. I'm not sure it was RCA remarketing NCR; it might have been an independent development of RCA. There was also an IBM data cell drive in the GE plant for a while.

see this reference
https://www.multicians.org/mgr.html#RACE

for 645 configuration RCA RACE unit under GE "skins"

thread:
https://www.garlic.com/~lynn/2006n.html#29 CRAM, DataCell, and 3850
https://www.garlic.com/~lynn/2006n.html#30 CRAM, DataCell, and 3850

The System/360 Model 20 Wasn't As Bad As All That

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The System/360 Model 20 Wasn't As Bad As All That
Newsgroups: alt.folklore.computers
Date: Mon, 17 Jul 2006 14:41:27 -0600

Peter Flass writes:
Thius is the fallacy of using microcomputers for serious work. Store the library in one place on one real computer, and you only have to update it once for everyone to have it.

there is a some topic drift in some sox threads ... there use to be audits comparing multiple, independent, original sources ... and inconsistencies were treated as possible problems (modulo collusion issues).

IT technology can centralize everything ... so that the audits are done against information that may all be coming from a single source (no provisions to compare original, independent sources). the current scenario is somewhat to specify audits to ever increasing detail ... but that is one thing you can program a computer for, generating consistent information to any level of detail desired (increasing the level of detail doesn't magically create independent, original sources for comparison).

some of the recent sox posts:
https://www.garlic.com/~lynn/2006h.html#58 Sarbanes-Oxley
https://www.garlic.com/~lynn/2006i.html#1 Sarbanes-Oxley
https://www.garlic.com/~lynn/aadsm24.htm#35 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#36 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#39 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#40 Interesting bit of a quote

... this also can come up in the different fraud, threats, and vulnerabilities between doing offline authentication and authorization vis-a-vis doing online authentication and authorization ... misc. recent posts:
https://www.garlic.com/~lynn/aadsm24.htm#1 UK Detects Chip-And-PIN Security Flaw
https://www.garlic.com/~lynn/aadsm24.htm#2 UK Banks Expected To Move To DDA EMV Cards
https://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
https://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#18 On Leadership - tech teams and the RTFM factor
https://www.garlic.com/~lynn/aadsm24.htm#25 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm24.htm#29 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#42 Naked Payments II
https://www.garlic.com/~lynn/aadsm24.htm#43 DDA cards may address the UK Chip&Pin woes

CRAM, DataCell, and 3850

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CRAM, DataCell, and 3850
Newsgroups: alt.folklore.computers
Date: Mon, 17 Jul 2006 17:31:16 -0600

"Rostyslaw J. Lewyckyj" writes:
HSM could be considered as an extension of data (file) caching to slower less accessible levels. The highest most accessible (fastest) level was Level 0 which was the level normally read and written by the processing programs. Usually it was on a fast disk. Level 1 was compacted Level 0 which was usually on slow direct access (disk). In addition to being compacted the data might be software compressed according to one of several criteria and data type. Level 2 was files from Level 1 migrated off to usually tape. Movement of files between levels was automatic with administrator controlled rules. But could also be invoked by the user via direct requests. We had HSM with fast and slow 3380s and ordinary tape reels. We migrated our Level 2 between two types of tapes 1600bpi --> 6400bpi (??) and then to STK cartriges in a silo. Finaly we migrated some of the Level 2 cartridges off site when space got tight in the near machine room area.

re:
https://www.garlic.com/~lynn/2006n.html#29 CRAM, DataCell, and 3850

we had instrumented several systems in the san jose area, so that we could get trace of every record accessed. we used it for some i/o (electronic memory) caching models ... comparing effects/sizes of disk arm level, controller level, channel/bus level , and system level record/track caches.

one of the interesting things that came up of that study was there was finding quite of bit periodic activity that used collections of files ... and in fact, some of the collections had very strong affinity (i.e. they were only used when others in the collections were also used). conjecture was that it was related to periodic (frequently quite deterministic) execution of specific business applications. some amount of this was quite large sequential access (much larger than most traditional electronic memory "caches" ... i.e. the standard electronic memory caches provide little or no benefit for such activity)

you see some of the backup/archive systems (like TSM) attempting to optimize for such behavior with things that some refer to as "containers" ... i.e. groups of files that are managed as a collecton ... where contents of containers may also be compacted/compressed as a unit.

for other drift ... the current generation of tapes can have such large capacity ... there are deployment considerations given to moving stuff first to disk-based "virtual tape reels" ... and then "stacking" large number of virtual tape reels from disk to a single large capacity physical tape (some of the traditional backup/archive to tape software tended to use a minimum of a single tape per operation, which led to frequently leaving new generation of physical tapes almost entirely empty).

misc. past backup/archive relates posts
https://www.garlic.com/~lynn/submain.html#backup

Not Your Dad's Mainframe: Little Iron

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Not Your Dad's Mainframe: Little Iron
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers,bit.listserv.vmesa-l
Date: Mon, 17 Jul 2006 23:42:26 -0600

Jim wrote:
DUMPRX was one of the slickest tools available for VM sysprogs in the '80s. With the overall level of code quality at that time, it was really needed. I have always thought that the only reason it wasn't included in the product was the NIH mentality that was common in IBM at that time in Endicott and IBM Kingston.

re:
https://www.garlic.com/~lynn/2006n.html#11 Not Your Dad's Mainframe: Little Iron

i may have alienated endicott ... which had a whole group supporting dumpscan (which was a large program written all in assembler). I had made a comment that i would implement dumprx in less 3 months elapsed time only working half time on it. It would have ten times the function of dumpscan as well as ten times the performance. also since this was the leading edge of the OCO-wars ... i pointed out that it would be implemented all in REXX (except for possibly a hundred assembler instructions) so that the source would have to be shipped.

I got all the basic stuff done early ... and since i had been building up a knowledge base of failure scenarios ... i started a library of dumprx/rexx routines that searched for particular classes of failure signatures/characteristics.

it could be run either as cms terminal line-mode ... or as a xedit rexx macro ... and then have full xedit capability for the dumprx session

since they wouldn't ship it, i eventually got approval to give a detailed implementation dumprx talk at SHARE ... in case anybody else wanted to implement their own.

re:
https://www.garlic.com/~lynn/submain.html#dumprx

The very first text editor

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The very first text editor
Newsgroups: alt.folklore.computers
Date: Tue, 18 Jul 2006 00:05:17 -0600

Brian Inglis writes:
Remember Lynn's story about having to change some code because of more than the expected number of some kind of channel error being reported from all systems globally?

standard system stuff is EREP ... i remember early in the 3380 cycle where they added predictive maintenance based on soft/recoverable error trend analysis.

there was an industry service that collected customer erep data ... sanatized the customer information and published some detailed erep statistics across installed machines (a little like consumer reports for mainframe RAS ... reliability, availability, serviceability). in the 70s and 80s there was more "clone" products in the market place competing.

i've periodically mentioned having done HYPERchannel ... channel extension device driver as part of moving something like 300 people from the IMS group out of the bldg90 (santa teresa lab) to a leased bldg. some ten miles away. ... recent post
https://www.garlic.com/~lynn/2006n.html#8 Not Your Dad's Mainframe: Little Iron

I would periodically get an unrecoverable error on the TELCO part of the HYPERchannel channel extension (after small number of retries) ... and after some investigation of the operating system error recovery and recording ... would reflect an emulated "channel check" for the operation. The operating system then would do additional recovery actions. misc. collected HSDT posts ... many mentioning HYPERchannel
https://www.garlic.com/~lynn/subnetwork.html#hsdt

so some years later ... I got call from 3090 product manager in POK ... who was quiet upset. they had designed the 3090 so there would be something like 3-5 "channel check" errors for a year of operation across all installed 3090s (i.e. not 3-5 total channel checks per 3090 over a period of a year ... but 3-5 aggregate channel checks for a period of a year across ALL 3090s). The industry service was reporting something like a total aggregate of 20 channel checks for the first year of customer installed 3090s. Some customers with 3090s were using HYPERchannel channel extension ... and "channel check" was being reflected for various kinds of long-haul transmission errors. So I was asked if I would get the software changes so that it reflected (emulated) something else than "channel check". I dug around the operating system error retry and recovery code some more and decided that reflecting (emulated) IFCC (interface control check) invoked effectively the same recovery actions.

in 2001, i had given one of the keynotes at HDCC (nasa highly dependable computing) workshop
https://web.archive.org/web/20011004023230/http://www.hdcc.cs.cmu.edu/may01/index.html

and related a short version of the industry wide erep/ras published information and asked the other vendors present if they had similarly published statistics for their installed machines.

The very first text editor

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The very first text editor
Newsgroups: alt.folklore.computers
Date: Tue, 18 Jul 2006 13:48:08 -0600

KR Williams writes:
Sure. I was hinting at things larger than the machine room. ;-) When I was in the 3090/ES9000 crypto group we had dealings with the "war room" (they didn't like that name) regarding error reporting. They could track just about anything, though by design everything we were doing was fenced from prying eyes. ;-)

re:
https://www.garlic.com/~lynn/2006n.html#35 The very first text editor

i.e. the industry service that was collecting customer erep data and doing monthly published summaries ... across wide variety of customers, processors (non-clones and clones) as well as various other devices (everything you would expect to find in erep reports in a mainframe shop).

for a little crypto drift from the early to mid-80s ...

one of the monster custom hardware projects was the data aggregator ... which was a full bandwidth T3 trunk encryptor (frequently called the data aggravator). there are stories that it was visited by MIB and told they were going to jail if they turned it on (there were some number of subsequent exchanges, and the aggravators were finally turned on anyway) ... past posts mentioning MIB being interested in the data aggravator.
https://www.garlic.com/~lynn/2004g.html#33 network history
https://www.garlic.com/~lynn/2006.html#26 IBM microwave application--early data communications

it was mandated that all the internal network links (leaving a facility) had to be encrypted
https://www.garlic.com/~lynn/subnetwork.html#internalnet

the internal network was larger than the arpanet/internet from just about the beginning until sometime the summer of '85 and supposedly at one point, over half of all the link encryptors in the world were installed on the internal network (some folklore was that whole companies were put into business with orders for equipment for the internal network).

i was doing a project i called HSDT ... high speed data transport
https://www.garlic.com/~lynn/subnetwork.html#hsdt

... with some number of T1 and higher speed backbone trunks ... and I thot I was paying an exorbitant amount of money to a certain company (whose name started with a "C") for T1 link encryptors. My idea was to be able to do a board that could be built for less than $100, handle in the 16mbit-24mbit/sec range ... and have some other features. The people in the crypto product group initially claimed it severely compromised DES. Took three months to win the argument (instead of being weaker than standard DES, it was actually stronger than standard DES).

shortly after winning the argument, i was told that we could produce as many boards as we wanted to ... it was just that there would only be a single customer for all boards (and it wasn't going to be me).

some of this was light weight stuff compared to trying to get network connections in other parts of the world (purely between internal installations in different countries) and the links had to have mandated link encryptors (crossing national boundaries).

and a recent post that mentions encryption from the late 70s
https://www.garlic.com/~lynn/2006n.html#23 sorting was: The System/360 Model 20 Wasn't As Bad As All That

in the early 80s, 3081 was taking about 1cpu second to do DES crypto on 150kbytes (i.e. about half of a full-duplex T1 ... aka you could saturate both processors of a 3081 just doing encryption/decryption for a full-duplex T1 link).

... i.e. following email only refers to dedicating a single 3081 processor to DES encryption/decryption of half-duplex T1

Date: 11/15/84 12:28:53
From: wheeler

A) 3081 can't be expected to implement software DES of a 1.5megabit data stream (i.e. 150kbytes of data per second) ... using current software unless you are willing to dedicate one of the processors solely to DES'ing the data, i.e. DES must be performed outboard of the 3081 CPU (there are DES chips available which will handle 3megabits).

... snip ... top of post, old email index

History: How did Forth get its stacks?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: History: How did Forth get its stacks?
Newsgroups: comp.lang.forth,alt.folklore.computers
Date: Wed, 19 Jul 2006 10:35:05 -0600

KR Williams writes:
Nor CISC like /360, /370, zSeries. ;-)

at one point, the follow-on to 4341 was going to be 801-based microprocessor ... in fact there was whole corporate effort to migrate the large variety of corporate microprocessors to 801. endicott got a brandnew multi-story brick building that housed much of the effort (up until then most of the facility looked like converted warehouses). i help with white paper that killed 801-based microprocessor for the 4341-following (the 4381).
https://www.garlic.com/~lynn/subtopic.html#801

i've claimed that a lot of early 801 effort could be construed as a reaction to go to the exact opposite extreme of the FS effort
https://www.garlic.com/~lynn/submain.html#futuresys

i.e. extreme hardware simplicity instead of extreme hardware complexity. i've mentioned before an internal advanced technology conference in pok in the mid-70s ... where we were presenting "logical machine" project (16-way smp using 158 engines) and the 801 group was presenting risc, CPr, PL.8, stuff.

that earlier effort is finally taking hold (replacing plethora of internal microprocessors with 801s) ... as/400 has gone 801 (power/pc), and lots of the "embedded" processors are being done with 801.

I have an old proposal i did dated 8mar85 titled VLSI Processor clusters ... with rack drawers with large number of boards (almost blades except they were installed on more of an "all slot" backplane within the drawers). It proposed abritarily intermixing boards with 5mip 370 Roman chip sets (done in Boeblingen) with boards having 801 chips (possibly blue iliad, first 32bit 801 that was never finished). Cooling was a big configuration issue.

for a little more drift ... another cluster scale-up activity
https://www.garlic.com/~lynn/95.html#13

Linux - Our Saving Grace?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Linux - Our Saving Grace?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 19 Jul 2006 11:04:58 -0600

Tom Marchant wrote:
You mean for instance, from the web site referred below, "But whereas iSeries and pSeries share a common processor, the zSeries won't - its architecture is just too different."

at one time "fort knox" was going to replace lots of internal microprocessors with 801 ... there was a big project to implement the 4341 follow-on (4381) with 801 microprocessor. recent reference
https://www.garlic.com/~lynn/2006n.html#37

the above also mentions a proposal i had early 85 for a VLSI processor cluster ... racks stuffed with boards ... arbitrarily intermixing boards with 370 chipsets and boards with 801 chipsets.
https://www.garlic.com/~lynn/subtopic.html#801

the original "iSeries" was s/38 ... folklore has it that after FS was killed ... some number of FS'ers retreated to Rochester and built the s/38. the s/38 then morphed into a (cisc-based) as/400 ... but later switched to 801-based processor line (power/pc) ... aka iSeries.
https://www.garlic.com/~lynn/submain.html#futuresys

sorting

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: sorting
Newsgroups: alt.folklore.computers
Date: Wed, 19 Jul 2006 11:17:54 -0600

Brian Inglis writes:
From what I've heard, those courses started as repackaged sales support training courses, that familiarized the salesmen with the products and their applications.

for a little topic drift ... past posts referring to early history of pc network server effort ... some of the implementation was work-for-hire subcontract to a group in Provo (before the decision to abandon the effort and let the Provo group retain rights to the work they had done so far):
https://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
https://www.garlic.com/~lynn/2000g.html#40 No more innovation? Get serious
https://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
https://www.garlic.com/~lynn/2001n.html#24 Alpha vs. Itanic: facts vs. FUD
https://www.garlic.com/~lynn/2002g.html#79 Coulda, Woulda, Shoudda moments?
https://www.garlic.com/~lynn/2002o.html#33 Over-the-shoulder effect
https://www.garlic.com/~lynn/2003c.html#27 difference between itanium and alpha
https://www.garlic.com/~lynn/2004f.html#16 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2005q.html#9 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005q.html#36 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2006l.html#39 Token-ring vs Ethernet - 10 years later

Identity Management Best Practices

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Identity Management Best Practices
Newsgroups: alt.computer.security
Date: Wed, 19 Jul 2006 12:05:11 -0600

"Jim" writes:
Know your customer regulations - There is a difference between knowing a customer and knowing an account holder. A customer may have multiple accounts and their pattern of activity overall may be deemed suspicious even if no individual account looks suspicious on its own.

Fraud reduction potential - No one is committing fraud today using their own name, address, and Social Security Number. Frauds involve creating or stealing identities, taking over real customers' accounts, and using real customers' identity tokens (codes, checks, cards, passwords, personal data) to steal from the customers' accounts.

this is something of a difference between strong identification and strong authentication. at places like point-of-sale ... it is desirable to have strong authentication (is the entity authorized to use the account) as opposed to strong identification (is the entity john doe) because of privacy issues.

current infrastructure has included indentification somewhat because of poor authentication technology; you name is on the payment card at point-of-sale ... allowing clerk to ask for gov. photo-id and cross-check the name on the payment card with the name on the gov. photo-id ... as an authentication mechanism ... but relying on identification to achieve authentication ... and as a result results in privacy problems.

at various points the EU has passed directives that payment cards were no longer to carry people names ... reducing level of privacy invasiveness (and hoping to promote strong authentication technology differentiated from identification technology); aka retail payments should be similar privacy invasive as cash.

there have even been some US banks issuing payment cards w/o names on the cards ... i.e. while financial instituations have "know your customer" regulations ... that doesn't mean that your name needs to be publicly, boldly displayed on every retail transaction.

the x9a10 financial standards working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments (internet, point-of-sale, debit, credit, stored-value, aka "ALL"). the result was x9.59 financial standard. i've periodically claimed it to be privacy "agnostic" ... it uses strong authentication for transaction integrity w/o requiring names to be plastered all over every transaction.
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

whether a financial institution keeps a mapping between the account holder to a name ... is outside the x9.59 protocol.

as to identity theft ... FTC and other institutions have made some attempts to differentiate betwen using personal information to establish new accounts (i.e. identity fraud) and account fraud ... where criminals use compromised information to perform fraudulent transactions against existing accounts. strong authentication in x9.59 retail transactions is targeted at account fraud compromises.

there has been some observations that just strengthening countermeasures to identify fraud won't actually reduce overall fraud as long as it is so easy to perform account fraud (differentiating between identification and authentication).

Tek 4010, info and prices

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tek 4010, info and prices
Newsgroups: alt.folklore.computers
Date: Wed, 19 Jul 2006 13:44:28 -0600

KR Williams writes:
I wonder what the IBM channel-attached graphics stations cost?

"2250m1" (there were 2250s that were directly mainframe channel attach as well as a "2250m4" ... which was 2250 combined with 1130 ... science center had 2250m4 to which space wars had been ported). sticks in my mind that a 2250m1 and a 2250m4 (w/1130) were about the same price ... but i can't remember what that was.

2250 upgrade was 3250 ... which i believe were rebranded sanders(?) vector graphics displays.

the high-end (for chip design) was CALMAs ... i remember los gatos lab had at least two.

Why is zSeries so CPU poor?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why is zSeries so CPU poor?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 19 Jul 2006 16:20:55 -0600

McKown, John wrote:
Since we are recalling the past, IIRC there was some CPU designed and manufactured to natively execute p-code. It didn't really make a very good showing in the market.

To be totally off topic: I really liked what I read about the Intel iAPX 432. Built from the ground up to be object oriented only.

http://www.sasktelwebsite.net/jbayko/cpu7.html

it was '79? or '81? asilomar acm sigops conference (i've lost my proceedings over the years and don't have ready reference) .... the 432 guys gave a talk. i remember them mentioning was that a lot of multiprocessor operation was hidden by the hardware ... you pass process work to the "hardware" ... and it kept track of how many processors there were and which processes ran on which processors. it was interesting since i had done something similar for m'code '75 for VAMPS ... a 5-way 370 smp project. ... misc. past postings mentioning VAMPS project:
https://www.garlic.com/~lynn/submain.html#bounce

today it would be considered slightly analogous to what happens with LPARs.

The other thing they mentioned in the sigops talk was that all this high -level function was dropped directly into 432 silicon ... and there was no way of patching it ... short of shipping brand new silicon. That characteristic was enuf to doom 432. i've got 3 old 432 intel books
https://www.garlic.com/~lynn/2000f.html#48 Famous Machines and Software that didn't

the above post lists the following i432 books (in my basement) ... along with quote from one of the intros mentioning b5000 from the 60s and also referencing s/38

....

there have been some number of other past discussions comparing 432 and s/38 (aka as/400 precursor) ... as well as s/38 embodying several "FS" features
https://www.garlic.com/~lynn/submain.html#futuresys

attached from long ago and far away (talking about VAMPS smp work from 1975). i had done dynamic adaptive resource management for cp67 as an undergraduate in the 60s and then rereleased the "resource manager" for vm370 on 11may76.

Date: 09/17/82 11:16:14
From: wheeler
re: VAMPS;

I did all the design work & innovation for both the machine architecture & operating system that made the number of real processors relatively transparent

Dispatching & interruption was completely in the microcode (below the machine interface). Essentially the number of processors were therefor below the interface ... my feedback algorithms had to be beefed up to allow for dynamically calculating the amount of CPU resources that were currently available for consumption.

Turns out all the verbage in the Intel 432 document about number of processors in a complex is transparent to the SCP. It can be transparent from the standpoint of the dispatcher ... but the overall resource allocation algorithms have to have a pretty good idea of the amount of CPU resource available in the complex for doing a accurate job.

... snip ... top of post, old email index

MTS, Emacs, and... WYLBUR?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MTS, Emacs, and... WYLBUR?
Newsgroups: alt.folklore.computers
Date: Thu, 20 Jul 2006 00:17:27 -0600

seewebsite@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:
And the idea of an editor being one's programming environment, of course, puts me in mind of Emacs, which had been effectively the environment, instead of the shell, of many users of Unix. Although the two editors are very different in many ways.

a lot of stuff was similarly done for XEDIT ... especially in conjunction with various amount of REX(X) programming ... recent mention of having done a large application (DUMPRX) in REX(X) and that it could be run either from command line or from within XEDIT environment.
https://www.garlic.com/~lynn/2006n.html#34 Not Your Dad's Mainframe; Little Iron
https://www.garlic.com/~lynn/2006n.html#11 Not Your Dad's Mainframe; Little Iron

i had started on dumprx very early in REX's existance ... before its release to customers and the name change from REX to REXX.

in that early period ... there was some contention that REX was just another command scripting environment (similarly to EXEC and EXEC2). Part of the exercise for DUMPRX was to demonstrate that REX was a significant enhancement over the existing command scripting processes.
https://www.garlic.com/~lynn/submain.html#dumprx

as to wylbur ... it had been heavily used (and enhanced) at NIH
http://datacenter.cit.nih.gov/interface/interface206/if206-01.htm

from above:
Over the next 12 years the NIH Computer Center received many requests to include more features among WYLBUR's then-elaborate package of capabilities. In response to these requests, the NIH Computer Center staff installed a complete rewrite of WYLBUR named NIH Extended WYLBUR in 1981, replacing the original version of WYLBUR acquired from Stanford University in 1969.

... snip ...

search engine turns up quite a few nih wylbur references.

... there is commercial superwylbur
http://www.superwylbur.com/

Any resources on VLIW?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any resources on VLIW?
Newsgroups: comp.arch,alt.folklore.computers,bit.listserv.vmesa-l
Date: Thu, 20 Jul 2006 13:02:18 -0600

Brian Inglis writes:
Might be relevant if Lynn Wheeler could expand on the unreleased VAMPS microcode to speed up 370 SMP, and also provided logical processors with similarities to those on current zSeries LPARs, although that may just have dropped parts of 370 sequential code down into microcode.

so presumably this recent post vis-a-vis VAMPS and the later i432
https://www.garlic.com/~lynn/2006n.html#42 Why is zSeries so CPU poor?

misc. collected past VAMPS postings
https://www.garlic.com/~lynn/submain.html#bounce

early microcode effort was "VMA" original for 370/158 that helped virtual machine performance. for subset of "supervisor" state instructions, microcode was added to execute the instruction using virtual machine rules (to avoid interrupting into the virtual machine hypervisor where the instruction was simulated).

concurrent with VAMPS effort was "ECPS" for 370 138&148. ECPS did some more stuff like VMA on the 158 (direct supervisor state instruction execution) ... but it also identified parts of the hypervisor kernel and moved that kernel code into microcode. the issue on 138&148 machines was that there was an avg. of 10:1 microcode instructions executed for every 370 instruction. Much of the kernel code moved to microcode on straigh 1:1 basis resulting in ten times performance speed up. old posting identifying specific kernel code segments for migrating into microcode.
https://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

the VMA-related efforts eventually evolved into SIE ... where nearly all supervisor state instructions had microcode enhancement for directly executing with regard to virtual machine rules (avoiding a lot of interruption into virtual machine hypervisor to simulate supervisor state instructions). SIE was a state change instruction that gathered up all the fields needed by various supervisor state instructions to execute according to virtual machine rules. post of old SIE discussion about implementation issue differences between 3081 and "trout" (3090)
https://www.garlic.com/~lynn/2006j.html#27 virtual memory

there were still things like page faults for the virtual machine that resulted in interruptions into the hypervisor kernel for handling. a special case was defined involving things like dedicated real storage for a virtual machine ... eliminating need to interrupt into the hypervisor kernel. This resulted in being able to operate a virtual machine subset directly supported by hardware ... w/o the need for a virtual machine kernel. This was called "PR/SM" ... and PR/SM capability eventually evolved into the current LPARs (logical partitions). a reference discussing some current LPAR and PR/SM
http://researchweb.watson.ibm.com/journal/rd/483/siegel.html

current machines can have a configurable limited number of LPARs ... and it is possible to run a virtual machine hypervisor in an LPAR, which in turns supports a much larger number of virtual machines. The has been an evoluation of the SIE support. Initially, SIE was not virtualized but LPARs make use of SIE for support. That met that a virtual machine hypervisor running in an LPAR wouldn't have performance assist of SIE for running its virtual machines (all virtual machine supervisor instructions would interrupt into the hypervisor for simulation). Enhancements were required to virtualize SIE for at least one level (so it could be used both by LPAR function and also by hypervisor running in an LPAR).

Since I was doing both VAMPS and ECPS ... I borrowed a lot of stuff done for ECPS for doing VAMPS. However, for VAMPS, I wanted it extended in a much more architected way ... rather than simply doing a 1-fo-1 movement of existing kernel 370 code into microcode. VAMPS was to have up to five processors ... and I defined a microcode hardware queued work interface where the hypervisor put units of work on the queued work interface (and the microcode took the queued work and executed on whatever available processor there were). The hardeware microcode also placed queued work for the hypervisor to handle ... like things that were i/o interrupts in traditional 370 or page fault interrupts (from executing virtual machines), etc.

The VAMPS abstraction of queued work for multiprocessor environment was somewhat akin to the later defintion found later in i432. Some of the VAMPS abstraction for i/o work queueing was somewhat akin to what showed up later for 370-xa i/o operations.

After VAMPS was killed, I adapted the multiprocessing microcode queued processing to an software implementation. A lot of the SMP kernel implementations used a single, global kernel SPIN lock to serialize all kernel execution. This drastically minimized the amount of code changes to adapt a single-processor operating system to support a multiprocessor operation.

In adapting the VAMPS multiprocessing microcode support to software, I took the equivalent kernel software functions (that had been moved to microcode in VAMPS) and made them multiprocessing parallelized with fine-grain locking. This amounted to the majority of the software kernel execution time ... but a relatively small amount of the total kernel instructions. The majority of the kernel instructions relied on a somewhat traditional global kernel lock. However, when ever the "parallized" kernel code required to transition into the "sequential" kernel code ... rather than "spinning" on the global kernel lock ... it "bounced". If it obtained the global kernel lock, then it proceeded as normal. If it couldn't obtain the global kernel lock, it would queue a super lightweight work request ... and go off and look for other "parallelized" work.

This approach obtained almost all the thruput benefit of having a kernel fine-grain locking implementation, avoided the degradation of single kernel spin-lock implementation ... but the kernel code changes were not significantly more than required for a single kernel spin-lock implementation. This implementation shipped in VM370 release four.

sorting

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: sorting
Newsgroups: alt.folklore.computers
Date: Thu, 20 Jul 2006 11:42:51 -0600

"Rostyslaw J. Lewyckyj" writes:
With a fixed width sort field, How did you accomplish adding cards between fully adjacent indexed entries? Did you re-index?

cp67/cms had a source *update* appliatiion called *update* that used sequence numbers on card images (default field in cols 73-80)

it would take a combination of the original source and an *update* file and produce a temporary working file (for actual compilation/assembly).

an update file statement was of the form:

input new set after card with particular sequence number:
./ I 828000

replace a card with one or more new cards
./ R 242000

replace starting card until ending card with one or more new cards
./ R 242000 245000

delete a card
./ D 242000

delete from start until end
./ D 242000 245000

it was dependent on all the card images in the input file have increasing sequence numbers in the sequence number field. originally it also required that new/replacement card images have the new sequence field numbers manually created.

when i was undergraduate, i was doing so many changes to cp67 kernel source that i got tired of manually producing the sequence numbers for the new/replacement statements ... so i wrote a utility that preprocessed update files and produced temporary output files for the cms *update* program.

my source update files had optional fields of the form:
./ I 828000 $ 828500 100

./ R 242000 $ 2420500 100

where the preprocessing utility would take the "dollar" field and used that for generating sequence numbers on the new/replacement card images, as well as removing the dollar fields before passing the file to the standard update program.

later, at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

during the joint effort w/endicott to add 370 virtual machine support to cp67. a multi-level update procedure was created ... where a "control" file was defined that defined a search order for a series of possible update names to look for to be applied serially (before the assembly). after the first update was applied and the temporary file was produced, successive updates would be applied to the previous output workfile (generating a new temporary output workfile which would be renamed to the standard output workfile name for subsequent processing).

later the cms *update* command was enhanced to both directly handle the $/dollar processing convention as well as internally provide the sequential processing for multi-level update application (instead of having it done externally by an command scripting *EXEC* file ... which eliminating the production of a lot of temporary work files).

CMS editors were also enhanced to take all edit changes and produce *update* files ... as opposed to producing a new copy of the original file with all changes applied. simple example:


./ R 01001000          $ 1001000 300                  10/09/80 21:40:21
         L    R15,FSTIL                                        @VA11461
         LA   R15,2(R15)                                       @VA11461
         MR   R2,R15                                           @VA11461

the editor produced a new *update* file of source changes with the "$" field convention ... and also added date/time of the change out in comment field of the "./" control statement. when you went to edit a source file ... it would also optionally apply all previously generated incremental update files.

a few urls from around the web discussing cms update command
http://mitvma.mit.edu/cmshelp.cgi?CMS%20EXECUPDT%20(ALL
http://mitvma.mit.edu/cmshelp.cgi?XEDIT%20SAVE%20(ALL
http://mitvma.mit.edu/cmshelp.cgi?CMSFILES%20WCOMPARE%20(ALL
http://ukcc.uky.edu/~ukccinfo.391/cmsref.html

description of current cms update command
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HCSD8B00/2.344?SHELF=hcsh2a70&DT=20040720161417

discussion of the cms multi-level update process
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/HCSD0B00/2.6?SHELF=hcsh2a70&DT=20040720092957

Why is z series so CPU poor?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why is z series so CPU poor?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 20 Jul 2006 13:25:35 -0600

john gilmore wrote:
Of chief interest here is the fact that execution of an MVCL is suppressed when destructive overlap would have occurred if it had been executed.

It is possible to build machines that behave very differently. Many System/360 and System/370 clones were, for example, built not to suppress but to truncate such operations not just ast overlap but at storage-protection boundaries.

360s instructions would check starting and ending operand address for exception (fetch, store, invalid address, and on 306/67 page available) and not initiate instruction.

370 introduced clcl and mvcl instructions which were defined as executing incrementally (and restartable). as a result clcl and mvcl could precheck ending operand address and not start execution ... it had to check exceptions as operand address was incrementally updated.

early 370/125 had a microcode bug in mvcl that didn't start execution if precheck on ending address had exception.

original vm370 kernel generation had added some code that used mvcl with maximum length to clear core ... and on the exception figure out amount of real storage (based on residual length in register). trying to generate a vm370 kernel (on these early 370/125s) would fail ... since the mvcl residual length count in the register would indicate machine without any available real storage.

Any resources on VLIW?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any resources on VLIW?
Newsgroups: comp.arch,alt.folklore.computers,bit.listserv.vmesa-l
Date: Thu, 20 Jul 2006 13:42:47 -0600

John Ahlstrom writes:
Lynn:

Can you point us to any information on 138/148 microprogramming and microarchitecture? Examples of the 10:1 microcode to 370 instruction expansion would be fascinating.

re:
https://www.garlic.com/~lynn/2006n.html#44 Any resources on VLIW?

i don't have any left ... and am not aware of any online resources. possibly somebody has some old field engineering manuals with instruction description.

the high-end 370s had horizontal microcode ... more akin to VLIW.

the low and mid-range 370s tended to be relatively straightforward processor enginess ... and the 370 "microcode" was relatively straight-foward sequential instruction sequences (i.e. "vertical" microcode) ... and the avg. of 10:1 microcode instruction per 370 instructions was relatively the same across variety of engines (i.e. the microprocessor MIP rate had to be on the order of ten times that of whatever 370 model it was being used in).

the large variety of these different (microcode) processing engines gave rise to the "fort knox" effort circa 1980 ... to replace most of the internal microcode processing engines with 801s (aka risc).
https://www.garlic.com/~lynn/subtopic.html#801

where the standard 801/risc instruction set was extended with some instructions that aided in instruction simulation.

the follow-on to the 138/148 was the 4331/4341. the follow-on to the 4331/4341 (4361/4381) were going to have 801 risc processors as the microcode engine. i help author a white paper that killed that effort. the issue was that technology was advancing to the point where it was possible to implement nearly the whole 370 directly in silicon ... avoiding much of the instruction emulation overhead altogether (i.e. 4381 was much more of a direct silicon implementation).

some number of the 370 instructions required a lot more then 10 microprocessor instructions and for which there wouldn't be a direct simple microcode instruction ... however, the typical high usage 370 kernel instructions tended to be a lot of testing bits/state and branching ... for which there typically was an exact correspondence in the microcode instruction set (i.e. eliminate microcode decode of the 370 instruction, manipulate the 370 registers, etc)

Any resources on VLIW?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any resources on VLIW?
Newsgroups: comp.arch,alt.folklore.computers,bit.listserv.vmesa-l
Date: Thu, 20 Jul 2006 13:52:23 -0600

re:
https://www.garlic.com/~lynn/2006n.html#44 Any resources on VLIW?
https://www.garlic.com/~lynn/2006n.html#47 Any resources on VLIW?

as an aside ... some number of the relatively recent 370 emulators written for intel platforms have quoted avg. instruction ratio numbers around 10:1 also (have to play some real tricks to get it much below 10:1).

Not Your Dad's Mainframe: Little Iron

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Not Your Dad's Mainframe: Little Iron
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 20 Jul 2006 14:57:02 -0600

Brian Inglis writes:
IBM OS and major subsystem products often include a trace table which is a ring buffer containing a record of the last umpty internal operations performed by the product, one of the most useful items included in a crash dump, and sometimes available for recording via an API.

misc. recent dumprx references
https://www.garlic.com/~lynn/2006n.html#11 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006n.html#34 Not Your Dad's Mainframe: Little Iron
https://www.garlic.com/~lynn/2006n.html#43 MTS, Emacs, and... WYLBUR?

so the obvious thing with dumprx in advanced analysis of postmortem kernel dumps was searching for various signatures in the trace table.

one of the things that cp67 had was a "DIE" condition (svc0) where it would generate (originally) a paper dump (when it encountered a fatal condition). this was enhanced to copy the contents of storage to disk and then (automatically) immediately reboot. when i was playing with loader tables as part of the pageable kernel (in cp67) ... i start looking at uniquely flagging each "DIE" situation. This was released in vm370 with each DIE condition having a unique identifier ... and there was a manual which gave a brief overview of the conditions for each "DIE" operation.

there is a story here of local customer modification resulting in cp67 kernel "DIE" and immediate restart (footnote comparing multics which might take half a day to recover from a failure situation):
https://www.multicians.org/thvv/360-67.html

so the internal dumprx ... had a softcopy of the manual and could present the brief overview text for each situation. however, the advanced dumprx analysis started automated examination of lots of stuff that normally be done manually as part of problem determination.

however, another gimmick on live system ... was do some operation, turn off trace table entires (since sometimes it could wrap quite quickly), capture ("snap shot") the kernel storage location of the trace table, and then turn it back on ... and then examine the trace table entries slightly more liesurely.

lots of past postings related to dumprx, problem determination, etc
https://www.garlic.com/~lynn/submain.html#dumprx

stacks: sorting

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: stacks: sorting
Newsgroups: alt.folklore.computers
Date: Fri, 21 Jul 2006 17:39:24 -0600

ArarghMail607NOSPAM writes:
I was only counting the keys on the main part of the keyboard. (a-z, 0-9, the other 11 keys, and the Fkeys) I had forgotten(skipped) ESC, TAB, BS and ENTER.

Hmmm, well, I get 65 on the main keyboard, plus 17 on the Num pad, plus 10 (well, 13) in the middle. Always assuming that I counted correctly. :-)

I think that we agree that is possible to generate MANY more values from the keyboard that can be used in any meaningful way.

this is somewhat the idea behind cord keyboards ... augment (engelbart) had a striaght piano looking five(?) cord keyboard (tymshare picked up augment ... which in turn was picked up by m/d when the bought tymshare).

part of cord-keyboard is the hand never has to leave/move ... simple would be a single hand being able to do all cords with the other hand always on some sort of pointer/mouse construct.

circa 1980, human factors group did sort of a mouse-shaped cord-keyboard; semi-hemisphere which had depressions for each finger with rocker switches under the fingertip. claim was that with practice, nearly everybody could reach at least 80 words per minute.

one of the flights of fancy was to create one for each hand ... with both having mouse/pointer capability ... in addition to the cord keyboard capability. the fingertips never leave the depressions.

stacks: sorting

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: stacks: sorting
Newsgroups: alt.folklore.computers
Date: Fri, 21 Jul 2006 18:23:23 -0600

re:
https://www.garlic.com/~lynn/2006n.html#50 stacks: sorting

... and from long ago and far away ...

Date: 07/03/80 13:24:45
From: wheeler

25 cord keyboards were manufactured at $100,000. Plug comaptible replacement for 3277 keyboard. There is one in San Jose area with human factors group here. Looks like I can borrow for a couple of weeks.

... snip ... top of post, old email index

the more things change, the more things stay the same

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: the more things change, the more things stay the same
Newsgroups: alt.folklore.computers,bit.listserv.vmesa-l
Date: Sat, 22 Jul 2006 20:27:06 -0600

x-post from
https://www.garlic.com/~lynn/aadsm24.htm#45 Case Study: Thunderbird's brittle security as proof of Iang's 3rd Hypothesis in secure design: there is only one mode, and it's secure

IBM Virtualization Achieves One of Industry's Highest Security Levels, Says Government Evaluator
http://www.marketwire.com/mw/release_html_b1?release_id=146570

the more things change, the more things stay the same, some reference to doing this same stuff nearly 40 years ago
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

recent post some of the stuff going back only 20-30 years
https://www.garlic.com/~lynn/2006n.html#44 Any resources on VLIW?
https://www.garlic.com/~lynn/2006n.html#47 Any resources on VLIW?

I wasn't actually aware of this stuff when i was an undergraduate. i became aware of it later on when i was asked to teach classes. it then started to dawn on me where some of the early requests for system integrity enhancements may have originated.

misc. past posts mentioning system assurance
https://www.garlic.com/~lynn/subintegrity.html#assurance

the more things change, the more things stay the same

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: the more things change, the more things stay the same
Newsgroups: alt.folklore.computers,bit.listserv.vmesa-l
Date: Sun, 23 Jul 2006 13:09:20 -0600

seewebsite@excxn.aNOSPAMb.cdn.invalid (John Savard) writes:
Not surprising: the NSA's "Security-Enhanced Linux" includes, as its unique security feature, something called mandatory security. A file can be flagged as having restrictions on it, and then any program which accesses this file, and writes on other files, causes the restrictions to propagate.

This, of course, was one of the features of Multics, which indeed dates from about 40 years ago.

re:
https://www.garlic.com/~lynn/2006n.html#52 the more things change, the more things stay the same

they were on the 5th floor of 545 tech sq ... while we were on the 4th floor
https://www.garlic.com/~lynn/subtopic.html#545tech

MD5 for z/OS?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MD5 for z/OS?
Newsgroups: bit.listserv.ibm-main
Date: Tue, 25 Jul 2006 09:38:20 -0600

gilmap@ibm-main.lst wrote:
OK. I can't read. The OP asked about MD5 (which is somewhat deprecated nowadays); I answered about SHA (which is somewhat less deprecated, so far). C source code for MD5 appears in RFC 1321.

two years ago, in the middle of a crypto 2004 talk on MD5 attacks ... somebody emailed me asking about doing list of a RFCs that reference MD5 ... so i added md5 RFC reference
https://www.garlic.com/~lynn/rfcmd5.htm

to my rfc index
https://www.garlic.com/~lynn/rfcietff.htm

recently playing around with css ... i changed the md5 background to yellow just for the fun of it.

The very first text editor

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The very first text editor
Newsgroups: alt.folklore.computers
Date: Tue, 25 Jul 2006 12:36:40 -0600

re:
https://www.garlic.com/~lynn/2006n.html#35 The very first text editor
https://www.garlic.com/~lynn/2006n.html#36 The very first text editor

... and from long ago and far away ...

Date: 5/31/81 15:31
To: wheeler

Lynn,

After seeing some of the RED/XEDIT dialogue between you and xxxxxx, I thought I would express my point of view as one who used to use WED, switched to RED, became fond of RED, then switched happily to XEDIT. (WED is known here as simply EDIT, and RED is known not so simply as RALEDIT, in case I slip up on my names.)

First let me say that I am comparing the versions currently available on the VM system disks at yyyyyy and restricting myself to a few technical issues. You are certainly right that RED would be better if it had the benefit of a couple more years of usage/debugging/refinement. However, I am not now convinced I would prefer RED even if it had this benefit.

Second, if I were to compare the current yyyyyy versions in terms of freedom from errors I've observed and significance of the errors, I would cite WED as essentially error free, RED as having a few mysterious and quite serious errors and a number of frustrating inconsistencies and XEDIT being closer to WED than RED but not what it should be. More than once a week RED used to leave me stuck in CP and/or get stuck in a loop that forced me to abort it until I recognized command/subcommand sequences that had to be avoided.

Backtracking a bit, I came to yyyyyy in '75, a fresh Ph.D. from Texas at Austin, with no experience on IBM machines except some minimal experiences via punched cards and JCL. I learned to use WED without having much more than a hint that it was not the plain CMS EDIT. After my experiences with the primitive editor and command language on the CDC 6400 at U.T., CMS and WED seemed just great.

In '77 I decided that even the benefits of my position here (I'm not being facetious) were not worth living in Westchester and went back to be a prof. at U.T., on leave of absence from IBM. Though most of the people there seemed relatively content with the DEC-10 that had come to dominate the 6400, both the command language (local version of TOPS-10) and the editors (DEC's TECO and Arizona's SOS) were pretty discouraging to me after enjoying CMS and WED.

In '79 I decided the benefits of my position here were worth living in Westchester, much as I would rather live in Austin. Though at first when I came back I used WED, as soon as I discovered RED I switched to it. I was very happy with its improvements, especially, but not limited to, the full screen capability and the string/pattern matching facility. I endured its errors and inconsistencies because I was able to work more efficiently in spite of these.

... snip ... top of post, old email index

AT&T Labs vs. Google Labs - R&D History

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: AT&T Labs vs. Google Labs - R&D History
Newsgroups: alt.folklore.computers
Date: Tue, 25 Jul 2006 15:10:10 -0600

AT&T Labs vs. Google Labs - R&D History
http://science.slashdot.org/story/06/07/25/1437231/att-labs-vs-google-labs---rd-history

for some drift ... there was summary of some institutional operations summer of 1981, previous reference to some of the detail (about some of the institutions visited):
https://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)

from a summary someplace summer of 1981 (25 years ago) ... with a little editorial highlighting:


Organization
____________

Bell Labs employs about 22,000 people, 2000 of whom are in the
"research division."  The Communications Principles Research Division
has 200 people, divided thusly:

Mathematics       about 25 people.

Psychology        about 100 people.

Econometrics      about 25 people.

Computer Science about 50 people, 10 of whom are co-ops, summer
students or other visitors.

Computer Science is broken down into the following groups: Techniques,
Sciences, Systems, Mathematics and Statistical Computation.

Systems and Their Use
_____________________

The Communications Principles Research Division has access to a
computation center serving all of the laboratory. This center has the
following mainframes:

• Honeywell 60/80.  This is a 5-way multiprocessor, each CPU a 1.5
mips engine. The operating systems is GCOS.

• Cray I. This is a 22 mips vector machine.

• 3 VAX 11/780s, at 1.1 mips each, running UNIX.

Network connections to at least 4 IBM 168s in Holmdel are available,
and the comp center has other small PDP 11s, high speed printers,
phototypesetters, etc.

In addition to the central computation center, the division has a VAX
11/780, of which half is allocated to the computer science department.
Another VAX is expected in August of this year.

The computer science department has, in addition to access to the
central computation center, the following computers:

Name    CPU      Mips     Memory   Disk    Total Concurrent
Alice   11/780   1.1      4.0      750     309   25
Ikeya   11/750   0.7      1.0      320      35    5
Enrke   11/750   0.7      1.0      320      35    5
Seki    11/750   0.7      2.0      320      35    5
Forbes  11/750   0.7      2.0      320      35    5
Swift   11/750   0.7      2.0      320      35    5
R70     11/70    1.1      1.6      920     244   25
FS      11/45    0.5      0.2      200     209   10

All of the systems are running Unix, but not all at the same level.
In particular, the 11/750s are used to try out new, experimental bits
and pieces.  Also available is a network connection to a Unix system
at UC Berkeley, which is actively maintaining and distributing the
latest version of Unix.  Code is regularly exchanged between Murray
Hill and Berkeley over the network.

No accounting is done on any machine, except for the 11/780, which is
shared with the rest of the division.  No disk allocation is done;
when a system runs out of disk space, someone (usually the person
responsible for the system) sends all users a message asking them to
erase unneeded files.  In general, they are at 50% utilization of disk
space.

There are no systems programmers or system administrators for these
systems.  One researcher "owns" a particular machine, and performs
these duties part time. Service obviously suffers when this person is
away on business or on vacation, but this is considered normal.  Each
user is responsible for getting his terminal fixed when it breaks; he
must contact the appropriate service company directly.  Unix has no
concept of an operator; thus one is not needed.  The computation
center sends an operator around every night during third shift to do
incremental backup to tape on the 11/780, 70 and 45.  The 11/750s are
backed up by copying the file system from one disk to another on each
system. Recovery of backed up data is manual.

The 11/45 is used primarily by the secretaries for text processing.
The existing secretaries train a new one; there is no consultant.  The
laboratory runs an education program much like the RePep program,
which does offer formal courses in programming and other topics.  The
central computation center offers "program counselling" which seems
similar to our consulting service.

The computer science department has its own phototypesetter, a
Merganthaler Linocomp.  It is run as a self-service machine.  The AP
news wire and weather wire run into the VAX 11/780.  Several nice
programs assist users in displaying news stories of interest to
them. Also, one can find out what the weather is for any part of the
nation.  Each member of the department has a terminal in his office,
and at home.  The terminals are ascii "glass teletypes," comparable to
the IBM 3101. At home they dial up over 1200 baud lines, in the lab
they run at 9600 baud.  Several Tektronix 4014 terminals are available
in terminal rooms, they also run at 9600 baud.

They are very satisfied with 9600 baud as a terminal line speed. It is
a faster rate than one can read at, and the fact that the terminals
roll up and down nicely greatly compensates for the slower speed.
I've used a local 3277 (around 40-80,000 effective baud rate) for the
last 6 years here, but I think I could comfortably live with 9600 baud
on a Unix system.  Full duplex also compensates for the slower line
speed.  Fullscreen editors are not widely used, and the fullscreen
editors in use are quite different from IBM fullscreen editors, due to
differences in the terminals.  They do not see the advantage of the
very high bandwidth lines with which we connect our terminals (except
for graphics); then again, they admit that their computers could not
support many terminals at such speeds.

The Unix operating system is well documented elsewhere, particularly
in the July-August 1978 issue of the Bell System Technical Journal,
Vol. 57, No. 6, part I.  A couple of things to point out about it:

• Unix is very small; the listing of the operating system (no
commands, but including the kernel, device drivers and file system) is
less than 1 inch thick, and is contained in about 70 files comprising
25,000 lines of sparsely commented code, occupying 1/2 megabyte of
disk storage. The complete system, including compilers, text
formatters, LISP, etc., takes 16 megabytes of disk to store the
uncompacted source.  Unix is written in the C language (which is a
high level language).

• It takes only 15 minutes of CPU to compile the C compiler on a PDP
11/70. (How long does it take to compile the PL.8 compiler?!!)  In
general, it would seem that it takes less CPU to get the same thing
done on Unix than on VM/CMS.

• Two researchers are working (part time) to rewrite the Unix kernel.
This is being done "to keep the moss from growing."  No business case
was done, and they will give the code to Berkeley, who will then
distribute it to the world in general.

• There is no documenation of Unix internals, but since it is only
25,000 lines of high level language, it is something one can study for
a few weeks and get to know as an entity. The locally produced user
manuals are kept up to date, and do not distinguish local commands
from "official" commands.

Plans
_____

Alice (the 11/780) will go to 8 megabytes of main memory, and another
11/780 with 8 megs will be arriving soon.  The comp center is
purchasing an additional 11/780 to be reserved for the research
division.  This machine will have full operator support.  It will run
the "standard" version of Unix that is compatible with the rest of the
Bell System.  They plan to purchase additional 11/750s as needed.
They cost under $100,000 each, including disks, and get delivered
within 6 months of order. The 11/750s can't be shared among more than
5 people, and running the text formatters or the VLSI programs bogs
the machines down.

Observations
____________

The people in the computer science department in general will choose
the latest and greatest version of a system instead of an older but
more stable version.

They observed that it is difficult to justify to upper management the
purchase of general purpose hardware and its support, especially when
it starts to get over $100,000. The 11/750s are justified as
supporting particular projects, and are thus easier to obtain.

When all of the users on a particular system know each other (and form
a peer group), you can dispense with a great deal of overhead, both in
terms of people and programs. You don't need operators, system
administrators, performance monitors, allocations, huge security
systems, and so on. The people at Bell have chosen to keep things
small, simple and friendly.

Self-maintenance of systems can get overbearing, for those who are
doing the self-maintenance.  Andy Koenig is in charge of the 11/780,
and has been spending well over half his time doing "support" work,
not research.  He says that this level is finally beginning to drop as
the system stabilizes.

Project Machines versus Personal Machines
_________________________________________

The computer science department at Murray Hill is not moving toward
a personal machine for each professional. Instead, they plan to
continue using 11/750s as project machines, with a maximum of 5 users
per machine.  These project machines all run Unix, and will be tied
together with a network that implements a single file name space among
all of the machines in a manner completely transparent to programs
running on each machine.

They point out that there is no running network software for the Perq
(the only readily available personal machine), and thus no easy
sharing of data. They have observed that at Xerox PARC there is
less sharing of software and tools among the Alto users (who are
linked by the Ethernet) than at Murray Hill. They feel that the
effort to build a network of personal machines that will allow the
easy sharing of data that they are accustomed to has been greatly
underestimated.

One of the other features typically provided by personal machines such
as the Perq is a bit-mapped high resolution raster display. Work is
underway at Murray Hill to provide such a display as a Unix
terminal. It is called the Jerq, and some of its features are:

• A full page, high resolution display, with a P4 (green) phosphor.

• No local disk is provided, as the Jerq is to be a terminal only, not
a work station.  It is connected to the host Unix system by a 19.2
kilobit serial line.

• A Motorola 68000 and 1/4 megabyte of memory is used, with plans
to move to 1/2 megabyte.  (1/2 meg lets you save 2 full screen images;
useful in task switching.)  There are no bit blit instructions for the
display; everything is straight 68000 instructions.  The complete
package is about 12in by 3in by 18in, and uses no fan.  It will be
mounted vertically on the side of the display box.

• The primary code running in the 68000 is a window manager and a
"multiplexor" that routes multiple streams of data from multiple host
processes to the various windows on the screen.  Keystrokes will also
be handled within the terminal, rather than sending characters one at
a time to the host as is presently done on the current full duplex
alphanumeric terminals.  These functions are memory and CPU intensive;
thus they were offloaded from the host computer.  Code for the Jerq is
written in C (of course).

• The expected cost is less than $4,000 each for the first
hundred or so.

• A tablet and mouse (similar to that of the Perq) is used as a
pointing device.

... snip ...

The very first text editor

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The very first text editor
Newsgroups: alt.folklore.computers
Date: Tue, 25 Jul 2006 19:46:35 -0600

re:
https://www.garlic.com/~lynn/2006n.html#36 The very first text editor

and for some recent crypto drift ...
https://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#50 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snake oil or good idea?

Copy protection

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Copy protection
Newsgroups: alt.folklore.computers
Date: Wed, 26 Jul 2006 18:34:15 -0600

ArarghMail607NOSPAM writes:
Maybe. IIRC, Copy2PC was a floppy diskette copy program. There was also an option card that got connected to the floppy drive somehow. It was intended to dup 5 1/4 FDs including all errors. I don't think that it worked very well with the FDs that had the laser burn.

I think that I might have one of those option cards, somewhere, but no software. Of course, it won't work on any modern system.

i have two copy2pc old 5.25in floppies ... now if i only had a floppy drive (for another 50 or so floppies i might like to read again, a number of turbo pascal releases, etc)

a) copy ii pc, 1983, disk copy program, central point software, inc

b) copy ii pc, pc, pc/xt version, disk backup program, central point software, inc. 1983

System/360 Prototype

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: System/360 Prototype
Newsgroups: alt.folklore.computers
Date: Thu, 27 Jul 2006 10:03:40 -0600

hancock4 writes:
IBM hadn't introduced any significantly improved computer products for several years (they had upgrades to their existing line, such as 7090 -> 7094). The competition was catching up. Honeywell came out with a machine that was stealing 1401 users. As a result, Watson Jr was terribly worried and rushed System/360's announcement. In his memoirs ("Father Son & Company") he admits this may have been premature since so much development and debugging work still remained; he said the sales models were cardboard mockups not real machines.

i was having lunch yesterday with somebody who told a story about back in the 60s trying to get 10Ks for IBM, GM, and a couple other big companies ... and he had to write the SEC to get physical copies made.

When he got back the 10K for IBM, somebody had also copied and included Watson's executive compensation plan ... which was apparently also in the file. he said it made for interesting reading. He said, that among other things, it gave watson a sales commission on every machine sold by the company.

How Many 360/195s and 370/195s were shipped?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How Many 360/195s and 370/195s were shipped?
Newsgroups: alt.folklore.computers
Date: Thu, 27 Jul 2006 10:17:25 -0600

hancock4 writes:
I never understood the difference between a 360/195 and a 370/195. Could anyone explain it?

neither machine had cache .. but did have nstruction pipeline. the machines ran about 5mips on "normal" codes ... but if you could get tailored looping for instructions in the pipeline ... it would peak around 10mips (normally, branches drained the pipeline).

the obvious stuff for 370 ... it had some of the new instructions that were part of the initial 370 announcement, clock stuff, a few others. i was also told that some level of instruction retry stuff was added for 370 (many of the 370s introduced some level of instruction retry for various kinds of "soft" failures).

previous, , index - home