<unclassified>
internal use only
confidential
confidential - restricted
registered confidential

on things like page mapped filesystem support
https://www.garlic.com/~lynn/submain.html#mmap

that got Z'ed. there were also "Y" document prefix ... that were frequently program logic manuals.

... registered confidential had all copies numbered and had to be kept in double locked cabinets. site security had list of all registered confidential documents and would peridically perform audits as to them still being in your possession.

at one point, i had collected a file cabinet drawer full of the 811 documents (for 11/78) that were registered condidential (various 370-xa hardware, software and architecture documents).

when we started doing the online phone book ... the paper copies were typically stamped internal use only. early on, various plant site people from around the world would refer us to their site security people before giving up machine readable copy. the site security people would insist that machine readable versions of the phone book had to be classified at confidential (at a minimum) ... and the idea that we would be collecting machine readable copies from all the sites ... appeared to boggle their mind. after some amount of effort, we got a couple major sites to relent (san jose, pok, etc) and let us have the machine readable as purely internal use only. after that, we would deal with local site security people by referring them to other sites that had already relented.

then there was the case of the cern tso/cms bakeoff share report (circa 1974?), the internal corporate copies got stamped confidential - restricted, available on a need-to-know basis only (only appropriately authorized employees were allowed to see the tso/cms comparison done by cern).

misc. past posts mentioned online phonebook work:
https://www.garlic.com/~lynn/2000b.html#92 Question regarding authentication implementation
https://www.garlic.com/~lynn/2000g.html#14 IBM's mess (was: Re: What the hell is an MSX?)
https://www.garlic.com/~lynn/2000g.html#35 does CA need the proof of acceptance of key binding ?
https://www.garlic.com/~lynn/2001j.html#29 Title Inflation
https://www.garlic.com/~lynn/2001j.html#30 Title Inflation
https://www.garlic.com/~lynn/2002e.html#33 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2002m.html#19 A new e-commerce security proposal
https://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)
https://www.garlic.com/~lynn/2003p.html#20 Dumb anti-MITM hacks / CAPTCHA application
https://www.garlic.com/~lynn/2004c.html#0 A POX on you, Dennis Ritchie!!!
https://www.garlic.com/~lynn/2004l.html#32 Shipwrecks
https://www.garlic.com/~lynn/2004p.html#13 Mainframe Virus ????
https://www.garlic.com/~lynn/2005c.html#38 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#43 History of performance counters
https://www.garlic.com/~lynn/2005s.html#3 Flat Query

misc. past references to corporate security classifications
https://www.garlic.com/~lynn/98.html#28 Drive letters
https://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
https://www.garlic.com/~lynn/2001l.html#20 mainframe question
https://www.garlic.com/~lynn/2001n.html#37 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2001n.html#79 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
https://www.garlic.com/~lynn/2002d.html#8 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002g.html#67 Coulda, Woulda, Shoudda moments?
https://www.garlic.com/~lynn/2002h.html#14 Why did OSI fail compared with TCP-IP?
https://www.garlic.com/~lynn/2002h.html#51 Why did OSI fail compared with TCP-IP?
https://www.garlic.com/~lynn/2002j.html#64 vm marketing (cross post)
https://www.garlic.com/~lynn/2002n.html#37 VR vs. Portable Computing
https://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
https://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
https://www.garlic.com/~lynn/2003c.html#69 OT: One for the historians - 360/91
https://www.garlic.com/~lynn/2003k.html#13 What is timesharing, anyway?
https://www.garlic.com/~lynn/2003m.html#56 model 91/CRJE and IKJLEW
https://www.garlic.com/~lynn/2003o.html#16 When nerds were nerds
https://www.garlic.com/~lynn/2003o.html#21 TSO alternative
https://www.garlic.com/~lynn/2004c.html#10 XDS Sigma vs IBM 370 was Re: I/O Selectric on eBay: How to use?
https://www.garlic.com/~lynn/2004n.html#17 RISCs too close to hardware?
https://www.garlic.com/~lynn/2005f.html#42 Moving assembler programs above the line
https://www.garlic.com/~lynn/2005f.html#49 Moving assembler programs above the line

random past posts mentioning cern:
https://www.garlic.com/~lynn/98.html#28 Drive letters
https://www.garlic.com/~lynn/2000e.html#23 Is Tim Berners-Lee the inventor of the web?
https://www.garlic.com/~lynn/2000f.html#61 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
https://www.garlic.com/~lynn/2001g.html#24 XML: No More CICS?
https://www.garlic.com/~lynn/2001g.html#54 DSRunoff; was Re: TECO Critique
https://www.garlic.com/~lynn/2001h.html#11 checking some myths.
https://www.garlic.com/~lynn/2001i.html#5 YKYGOW...
https://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
https://www.garlic.com/~lynn/2001l.html#20 mainframe question
https://www.garlic.com/~lynn/2001m.html#19 3270 protocol
https://www.garlic.com/~lynn/2001m.html#43 FA: Early IBM Software and Reference Manuals
https://www.garlic.com/~lynn/2001n.html#40 Google increase archive reach
https://www.garlic.com/~lynn/2002g.html#67 Coulda, Woulda, Shoudda moments?
https://www.garlic.com/~lynn/2002h.html#14 Why did OSI fail compared with TCP-IP?
https://www.garlic.com/~lynn/2002h.html#51 Why did OSI fail compared with TCP-IP?
https://www.garlic.com/~lynn/2002i.html#37 IBM was: CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002j.html#64 vm marketing (cross post)
https://www.garlic.com/~lynn/2002n.html#35 VR vs. Portable Computing
https://www.garlic.com/~lynn/2002n.html#37 VR vs. Portable Computing
https://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
https://www.garlic.com/~lynn/2002o.html#54 XML, AI, Cyc, psych, and literature
https://www.garlic.com/~lynn/2003.html#54 Timesharing TOPS-10 vs. VAX/VMS "task based timesharing"
https://www.garlic.com/~lynn/2003c.html#53 HASP assembly: What the heck is an MVT ABEND 422?
https://www.garlic.com/~lynn/2003g.html#14 Page Table - per OS/Process
https://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
https://www.garlic.com/~lynn/2003h.html#19 Why did TCP become popular ?
https://www.garlic.com/~lynn/2003k.html#13 What is timesharing, anyway?
https://www.garlic.com/~lynn/2003m.html#56 model 91/CRJE and IKJLEW
https://www.garlic.com/~lynn/2003o.html#16 When nerds were nerds
https://www.garlic.com/~lynn/2004c.html#10 XDS Sigma vs IBM 370 was Re: I/O Selectric on eBay: How to use?
https://www.garlic.com/~lynn/2004c.html#26 Moribund TSO/E
https://www.garlic.com/~lynn/2004c.html#27 Moribund TSO/E
https://www.garlic.com/~lynn/2004d.html#39 System/360 40th Anniversary
https://www.garlic.com/~lynn/2004d.html#53 COMPUTER RELATED WORLD'S RECORDS?
https://www.garlic.com/~lynn/2004n.html#10 RISCs too close to hardware?
https://www.garlic.com/~lynn/2004n.html#17 RISCs too close to hardware?
https://www.garlic.com/~lynn/2005l.html#10 who invented CONFIG/SYS?
https://www.garlic.com/~lynn/2005s.html#12 Flat Query

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

whats the difference between Encryption and Encoding ? or both are same ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: whats the difference between Encryption and Encoding ? or both are same ?
Newsgroups: sci.crypt
Date: Wed, 19 Oct 2005 08:18:36 -0600

from the security PAIN acronym
P privacy
A authentication
I integrity
N non-repudiation

a digital signature is targeted at authentication and integrity w/o having to address privacy (secrecy or confidentiality).

for a little drift ... i've sporadicly mentioned that sometimes there appear to be semantic confusing "digital signature" and "human signature" ... since they both contained the word "signature". various past collected postings on the signature subject
https://www.garlic.com/~lynn/subpubkey.html#signature

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/

MVCIN instruction

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MVCIN instruction
Date: Thu, 20 Oct 2005 10:16:20 -0600
Newsgroups: bit.listserv.ibm-main

i also used a variation on the page mapped interface in the 80s for doing a rewrite of the vm370 spool file systtem ... somewhat as part of hsdt project
https://www.garlic.com/~lynn/subnetwork.html#hsdt

the base spool filesystem was written in assembler as part of the kernel ... it provided a "high-speed" interface for applications that involved synchronously moving 4k blocks back and forth across the kernel line. this synchronous character became a problem for vnet/rscs when trying to support lots of high-speed links. a heavily loaded spool file system might be doing 40-50 4k transfers a second. however, because it was a synchronous api, rscs/vnet was non-runanable during the actual disk transfers ... and never could have more than one request active at a time. as a result rscs/vnet might only get 5-6 4k spool transfers per second (competing with all the other uses of the spool system).

so my objectivs for the hsdt (high speed data transfer) spool file system (SFS) rewrite were:
1) move implementation from kernel to virtual address space
2) implement in vs/pascal rather than assembler
3) overall pathlength of the new pascal-based implementation running in a virtual address space should be less than the existing assembler, kernel implementation
4) support contiguous allocation
5) support multiple block transfer requests
6) support asynchronous transfer requests

so cp kernel needed several modifications ... first it had to be able to come up w/o having a spool system active at initial boot (like it was custom to), be able to activate the spooling subsystem for managing spool areas ... and handle spooling activity by making up-calls into the spool processor address space.

an annoyance in the existing implementation was that all spool areas were treated as one large resource ... all spool resrouces had to be available ... or the system didn't come up. the kernel now had to be able to operate independently of the spool resource. so while i was at it, i added some extended integrity and availabilitity. each spool physical area could essentially be independently activated/deactivate (varied on/off). there was an overall checkpoint/warm start facility ... however there was additional information added to spool records ... that if checkpoint and warm start information was missing ... it was possible for the spooling resource to sequentially physical read a physical area (it could generate paged mapped requests for 150 4k blocks at a time ... and the kernel might even chain these into a single physical i/o, aka if it happened to be a 3380 cylinder) and recover all allocated spool files (and nominally do it significantly faster than the existing cp ckeckpoint process ... which sort of had starting records for each file ... but then had to sequentially following a chain of records, one read at a time). if warm start information wasn't available ... the large sequential physical read tended to be significantly faster than the one at a time, checkpoint scatter read.

the standard kernel spool implementation had sequentially chained control blocks representing each file. for large active spool system, the implementation spent significant pathlength running the sequential chains. the pascal implementation used library routines for hash table and red/block tree management of all the spool file control blocks. this tended to more than offset any pathlength lost moving the function into virtual address space.

the high-speed spool api was extended to allow specifying multiple 4k blocks for both reads & writes ... and enhanced to allow the api to operate asynchronously. a single full-duplex 56kbit link could mean around up to 2 4k transfers per sec (1 4k transfers in each direction). several loaded 56kbit links could easily run into spool file thruput bottleneck on heavily loaded systems (rscs/vnet possibly be limited to 5-6 4k records/sec)

hsdt machine had several channel connections to other machines in the local area and multiple full-duplex T1 (1.5mbits/sec) connections. a single T1 has about 30 times the thruput of a 56kbit ... which in turn increases the two 4k record thruput requirements to 60 4k record thruput per second (for a single full-duplex T1 link). an hsdt vnet/rscs node might reasonably be expected to have thruput capacity of several hundred 4k records/sec (design point thruput possibly one hundred times a nominal rscs/vnet node).

hsdt operated three sat. stations, san jose, austin, and yorktown ... with hsdt node having multiple channel and T1 links to other machines in the local area. the sat. bandwidth was initially configured as multiple T1 full-duplex links between the three nodes. however we designed and were building a packet broadcast operation. The earch stations were TDMA so that each station had specific times when it could transmit. The transmit bursts could then be configurated to simulate full-duplex T1 operation. The packet switch-over was to eliminate the telco T1 emulation and treat it purely as packet broadcast architecture (somewhat analogous to t/r lan operation but w/o the time-delay of token passing since the bird in the sky provided clock synchronization for tdma operation).

the san jose hsdt node was in bldg. 29, but there were high-speed channel links to other machines in bldg. 29 and telco T1 links to other machines in the san jose area ... besides the sat. links.

one of the challenges was that all corporate transmission had to be encrypted. the internal network had been larger than the whole arpanet/internet from just about the beginning until sometime mid-85.
https://www.garlic.com/~lynn/subnetwork.html#internalnet

arpanet was about 250 nodes at the time it converted to tcp/ip on 1/1/83. by comparison, later that year, the internal network passed 1000 nodes ... minor reference
https://www.garlic.com/~lynn/internet.htm#22

note the size of the internal network does not include bitnet/earn nodes ... which were univ. nodes using rscs/vnet technology (and was about the same size as arpanet/internet in the period. misc. posts mentioning bitnet &/or earn:
https://www.garlic.com/~lynn/subnetwork.html#bitnet

about the time we were starting hsdt, the claim was that the internal network had over half of all link encryptors in the world. moving from an emulated telco processing for hsdt also eliminated the ability to use link encryptors ... so we had to design a packet-based encryption hardware that potentially was changing key on every packet ... and aggregate thruput hit multiple megabytes/second. we further complicated the task by establishing an objective that the card could be manufactured for less then $100 (using off-the-shelf chips ... and still support mbyte/sec or above thruput). also wanted to be able to use it in lieu of standard link encryptors which were running $16k.

the other piece was hsdt nodes was making a lot of use of HYPERchannel hardware .... so when the initial mainframe tcp/ip implementation was done in pascal ... i added rfc 1044 support. the base product shipped with 8232 controller which had some idiosyncrasies; the support would consume a whole 3090 processor getting 44kbytes/sec. by contrast, in some 1944 tuning tests at cray research, we got 1mbyte channel speed between a 4341-clone and a cray machine ... using only a modest amount of the 4341 processor.
https://www.garlic.com/~lynn/subnetwork.html#1044

having drifted this far ... i get to also mention that we weren't allowed to bid on nsfnet backbone (the arpanet change over to tcp/ip protocol on 1/1/83 was major technology milestone for the internet. however, the birth of modern internetworking ... i.e. operational prelude to the modern internet ... was the deployment of the nsfnet backbone ... supporting internetworking of multiple networks) however, my wife appealed to the director of nsf and got a technical audit ... which concluded that what we had running was at least five years ahead of all nsfnet bids to build something new. minor recent post on the subject:
https://www.garlic.com/~lynn/2005q.html#46 Intel strikes back with a parallel x86 design

past posts mentioning SFS ... spool file system rewrite (as opposed to that other SFS that came later ... shared file system):
https://www.garlic.com/~lynn/99.html#34 why is there an "@" key?
https://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
https://www.garlic.com/~lynn/2001n.html#7 More newbie stop the war here!
https://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
https://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long post warning)
https://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
https://www.garlic.com/~lynn/2003b.html#46 internal network drift (was filesystem structure)
https://www.garlic.com/~lynn/2003g.html#27 SYSPROF and the 190 disk
https://www.garlic.com/~lynn/2003k.html#26 Microkernels are not "all or nothing". Re: Multics Concepts For
https://www.garlic.com/~lynn/2003k.html#63 SPXTAPE status from REXX
https://www.garlic.com/~lynn/2004g.html#19 HERCULES
https://www.garlic.com/~lynn/2004m.html#33 Shipwrecks
https://www.garlic.com/~lynn/2004p.html#3 History of C
https://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2005n.html#36 Code density and performance?

past post mentioning link encryptors
https://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm14.htm#0 The case against directories
https://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm18.htm#51 link-layer encryptors for Ethernet?
https://www.garlic.com/~lynn/99.html#210 AES cyphers leak information like sieves
https://www.garlic.com/~lynn/2002b.html#56 Computer Naming Conventions
https://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002j.html#52 "Slower is more secure"
https://www.garlic.com/~lynn/2003e.html#34 Use of SSL as a VPN
https://www.garlic.com/~lynn/2003e.html#36 Use of SSL as a VPN
https://www.garlic.com/~lynn/2003i.html#62 Wireless security
https://www.garlic.com/~lynn/2004g.html#33 network history
https://www.garlic.com/~lynn/2004g.html#34 network history
https://www.garlic.com/~lynn/2004p.html#44 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2004p.html#51 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2004p.html#55 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
https://www.garlic.com/~lynn/2005c.html#38 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005r.html#10 Intel strikes back with a parallel x86 design

IBM 3330

From: <lynn@garlic.com>
Newsgroups: alt.folklore.computers
Subject: Re: IBM 3330
Date: Fri, 21 Oct 2005 01:01:17 -0700

Internet today -- what's left for hobbiests

From: <lynn@garlic.com>
Newsgroups: alt.folklore.computers,alt.cyberpunk
Subject: Re: Internet today -- what's left for hobbiests
Date: Fri, 21 Oct 2005 01:04:23 -0700

MVCIN instruction

From: <lynn@garlic.com>
Newsgroups: bit.listserv.ibm-main
Subject: Re: MVCIN instruction
Date: Fri, 21 Oct 2005 01:19:14 -0700

you replied to
https://www.garlic.com/~lynn/2005s.html#19 MVCIN instruction
posted 10:30 17oct

the immediately following post had pointer to online scan of channel oem manaul
https://www.garlic.com/~lynn/2005s.html#20 MVCIN instruction
posted 11:31 17oct

Random Access Tape?

From: <lynn@garlic.com>
Newsgroups: alt.comp.hardware,alt.computers,alt.folklore.computers
Subject: Re: Random Access Tape?
Date: Fri, 21 Oct 2005 11:10:16 -0700

Power5 and Cell, new issue of IBM Journal of R&D

From: <lynn@garlic.com>
Newsgroups: comp.arch
Subject: Re: Power5 and Cell, new issue of IBM Journal of R&D
Date: Fri, 21 Oct 2005 13:01:25 -0700

in the mean time the acis group in palo alto were working on a bsd port to 370. minor folklore ... i had been trying to talk one of the people that had done vs/pascal to do a C front-end for it (for a 370 c compiler). he disappeared one summer and showed up at metaware in santa cruz. i suggested to the palo alto group that they could contract with metaware for 370 c compiler. somewhere along the way, the palo alto group got redirected to target the bsd port to the pc/rt (instead of 370 ... pc/rt was already out in the market). this became aos for the pc/rt (and also used metaware c compiler). The palo alto group took some pride in pointing out that aos/bsd port to pc/rt bare metal took less effort than either the vrm implementation or the AT&T port to the vrm interface.

there were misc. & sundry other rivalries between austin and palo alto. austin had done journaled file system for rios/power (aix v3) using special "database" 801 hardware ... claiming that it was more efficient and less work than modifying the filesystem code to perform traditional logging and commit calls. the palo alto group took the jfs code and reworked it for a "portable" version ... didn't rely on 801 hardware ... instead had traditional database logging and commit calls. The benchmarked both versions on same rios/power hardware ... and the version that didn't use the special hardware was faster. recent post on the subject
https://www.garlic.com/~lynn/2005r.html#27 transactional memory question

misc. past 801, romp, rios, fort knox, etc collected posts
https://www.garlic.com/~lynn/subtopic.html#801

Power5 and Cell, new issue of IBM Journal of R&D

From: "" <lynn@garlic.com>
Newsgroups: comp.arch
Subject: Re: Power5 and Cell, new issue of IBM Journal of R&D
Date: Fri, 21 Oct 2005 23:57:46 -0700

i've previously posted on the erep/ras issue for mainframe unix ports

1) at&t unix infrastructure and api on top a stripped down tss/370 kernel called ssup. only available internally within at&t 2) Amdahl uts (called gold before announce) .... typically ran under virtual machine hypervisor 3) aix/370 (& aix/ps2), ucla locus port ... also ran under virtual machine hypervisor (done by the same palo alto group that had done the bsd port to pc/rt for aos)

these mainframes were frequently multi-million dollar affairs with cadre of people doing service and preventive maintenance. the field service people claimed they couldn't/wouldn't do their job without the appropriate erep/ras (somewhat imagine automobile analogy and your multimillion dollar investment is out of warranty because of not getting its service).

the issue was that erep/ras was a major component of mainframe operating system ... a significantly larger undertaking than straight forward unix port to mainframe. the tss/370 ssup and the virtual machine hypervisors provided this erep/ras function on behalf of the unix port (w/o the significant effort of having to build a unix-based erep/ras implementation)

for quite a bit of topic drift ... some posts about doing erep/ras stuff for the disk engineering lab
https://www.garlic.com/~lynn/subtopic.html#disk

random past posts mentioning mainframe unix ports
https://www.garlic.com/~lynn/99.html#2 IBM S/360
https://www.garlic.com/~lynn/99.html#64 Old naked woman ASCII art
https://www.garlic.com/~lynn/99.html#66 System/1 ?
https://www.garlic.com/~lynn/99.html#190 Merced Processor Support at it again
https://www.garlic.com/~lynn/99.html#191 Merced Processor Support at it again
https://www.garlic.com/~lynn/2000c.html#8 IBM Linux
https://www.garlic.com/~lynn/2000e.html#27 OCF, PC/SC and GOP
https://www.garlic.com/~lynn/2000f.html#68 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000f.html#70 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2001.html#44 Options for Delivering Mainframe Reports to Outside Organizat ions
https://www.garlic.com/~lynn/2001.html#49 Options for Delivering Mainframe Reports to Outside Organizat ions
https://www.garlic.com/~lynn/2001f.html#20 VM-CMS emulator
https://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
https://www.garlic.com/~lynn/2001l.html#17 mainframe question
https://www.garlic.com/~lynn/2001l.html#18 mainframe question
https://www.garlic.com/~lynn/2001l.html#19 mainframe question
https://www.garlic.com/~lynn/2002b.html#36 windows XP and HAL: The CP/M way still works in 2002
https://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling convention
https://www.garlic.com/~lynn/2002i.html#54 Unisys A11 worth keeping?
https://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2002i.html#81 McKinley Cometh
https://www.garlic.com/~lynn/2002j.html#36 Difference between Unix and Linux?
https://www.garlic.com/~lynn/2002n.html#54 SHARE MVT Project anniversary
https://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
https://www.garlic.com/~lynn/2002n.html#67 Mainframe Spreadsheets - 1980's History
https://www.garlic.com/~lynn/2002p.html#45 Linux paging
https://www.garlic.com/~lynn/2003d.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
https://www.garlic.com/~lynn/2003d.html#54 Filesystems
https://www.garlic.com/~lynn/2003h.html#35 UNIX on LINUX on VM/ESA or z/VM
https://www.garlic.com/~lynn/2003h.html#45 Question about Unix "heritage"
https://www.garlic.com/~lynn/2003i.html#53 A Dark Day
https://www.garlic.com/~lynn/2003k.html#5 What is timesharing, anyway?
https://www.garlic.com/~lynn/2003o.html#49 Any experience with "The Last One"?
https://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
https://www.garlic.com/~lynn/2004c.html#10 XDS Sigma vs IBM 370 was Re: I/O Selectric on eBay: How to use?
https://www.garlic.com/~lynn/2004d.html#72 ibm mainframe or unix
https://www.garlic.com/~lynn/2004h.html#41 Interesting read about upcoming K9 processors
https://www.garlic.com/~lynn/2004h.html#42 Interesting read about
upcoming K9 processors
https://www.garlic.com/~lynn/2004n.html#30 First single chip 32-bit microprocessor
https://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development Philosophy
https://www.garlic.com/~lynn/2004q.html#38 CAS and LL/SC
https://www.garlic.com/~lynn/2004q.html#39 CAS and LL/SC
https://www.garlic.com/~lynn/2005b.html#22 The Mac is like a modern day Betamax
https://www.garlic.com/~lynn/2005c.html#20 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005f.html#28 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005h.html#5 Single System Image questions
https://www.garlic.com/~lynn/2005j.html#26 IBM Plugs Big Iron to the College Crowd
https://www.garlic.com/~lynn/2005m.html#4 [newbie] Ancient version of Unix under vm/370
https://www.garlic.com/~lynn/2005m.html#7 [newbie] Ancient version of Unix under vm/370
https://www.garlic.com/~lynn/2005q.html#14 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005q.html#26 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005q.html#49 What ever happened to Tandem and NonStop OS ?

Filemode 7-9?

From: <lynn@garlic.com>
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Subject: Re: Filemode 7-9?
Date: Sat, 22 Oct 2005 01:33:20 -0700

the cp67 development group split off from the science center (on the 4th flr)
https://www.garlic.com/~lynn/subtopic.html#545tech

and absorbed the boston programming center on the 3rd flr. a lot of the morph from cp67 to vm370 was done there ... eventually the group outgrew the 3rd flr space and moved out to the old SBC bldg in burlington mall (sbc had gone to cdc as part of some litigation settlement).

there was constant pressure to kill vm370 and the next release was always the last. eventually pok got vm370 and burlington killed on the grounds that all the people had to be moved to pok to support the vmtool ... which was a 370-xa internal use only implementation ... needed for supporting mvs/xa development.

one issue was that endicott had a rapidly expanding market for vm based on explosion in 148 (and later 4341) vm sales. endicott finally was able to save vm370 from being completely killed and allowed that some of the people might move to endicott ... rather than everybody needed to move to pok for supporting mvs/xa development.

however, some number of people didn't want to leave the boston area. vms was just getting started and some number of people went to dec ... i remember some also went to prime computers.

there was some joke that one of the major contributions to vms was by the head of pok lab.

Filemode 7-9?

From: <lynn@garlic.com>
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Subject: Re: Filemode 7-9?
Date: Sun, 23 Oct 2005 00:00:27 -0700

two other pieces of folklore somewhat related to the closing of burlington mall location

1) the news of burlington mall closing and killing the product (since all the people were required to support mvs/xa development) was leaked to somebody in the group. there was then an extended period where everybody was interviewed to try and identify who leaked the information. a cload of suspicion pretty much hung over the place until the bldg. was actually vacated.

2) somebody had completely rewritten most the os/360 simulation support (there was the joke at the time that the 8mbyte os/360 simulation in mvs might be doing a few more things than the 64kbyte os/360 simulation in cms). somewhat fading memory, but the rewrite really did a lot more of complete os/360 simulation, i believe a bunch of bdam bells and whistles were added as well as a bunch of stuff for both reading and writing os/360 formated filesystems. the announcement that vm370 and burlington was being killl put all such new stuff on the shelf ... and the person responsible was one of the people that went off to DEC. i'm pretty sure that the work was never revived and just evaporated with the closing of the burlington mall location.

.....

part of endicott's install base had really started to ramp up with ecps for the 138/148 ... minor ref
https://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

and, in fact, there was an attempt to make the ecps announcement appear that vm & hypervisor was integrated into every machine shipped (somewhat like the current generation of mainframe lpars) ... however this was eventually overruled as being "non-strategic".

then you find 4341 and vax/vms pretty much competing head-to-head in the same market segment. some price/performance and feature threshold had been crossed ... and you found large corporations placing 4341 orders for several hundred at a time. there was a similar explosion in the deployment of 4341s inside the corporation ... which also contributed to some of the large explosion in the number of nodes on the internal network. minor recent post
https://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
which was follow-on to
https://www.garlic.com/~lynn/2005s.html#25 MVCIN instruction

Von Neumann machines. The key to space and much else

From: <lynn@garlic.com>
Newsgroups: sci.physics,rec.aviation.military,sci.space.policy,alt.folklore.computers
Subject: Re: Von Neumann machines. The key to space and much else.
Date: Sun, 23 Oct 2005 04:24:27 -0700

here is a hint
http://www.svlug.org/directions/veritas.shtml

MVCIN instruction

From: <lynn@garlic.com>
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Subject: Re: MVCIN instruction
Date: Mon, 24 Oct 2005 00:30:12 -0700

for two-processors, 370 typically slowed down each engine by 10 percent (compared to simplex) in order to allow for x-cache chatter activity. originally 3081 was never targeted as having a single processor operation (3081 was two processors, 3084 was two 3081s tied together for four processors). somewhat because tpf (airline control program) didn't have multiprocessor support, 3083 was brought out ... which had the cycle time unslowed down ... so 3083j engine was nearly 15 percent faster than 3081k engine.

a recent thread in comp.arch mentioning pok strong memory consistency and cycle slow-down
https://www.garlic.com/~lynn/2005r.html#46 Numa-Q Information

some older posts mentioning kernel allocation cache-line work in the 3081 time-frame:
https://www.garlic.com/~lynn/2001j.html#18 I hate Compaq
https://www.garlic.com/~lynn/2002h.html#87 Atomic operations redux
https://www.garlic.com/~lynn/2003j.html#42 Flash 10208

a quick use of search engine turns up
http://homepage.virgin.net/roy.longbottom/mips.htm

a little bit from above:
This document contains performance claims and estimates for more than 2000 mainframes, minicomputers, supercomputers and workstations, from around 120 suppliers and produced between 1980 and 1996. Speed is given as MIPS (Millions of Instructions Per Second). Maximum MFLOPS (Millions of Floating Point Instructions Per Second) are also provided, usually for systems with supercomputer vector processing capabilities. Where available, production dates and cost is also shown. Details of IBM's larger mainframes and PC CPUs up to 2004 have also been included.

....

Manufacturer      No. of    OS       MHz    MIPS    MAX   Type Year  Cost
Processor          CPUs  CPU chip           Claim  MFLOPS            £=GBP

IBM                      OS VM/MVS
3083 E              1       ECL      38.5    4.7           MF  1982  $1.2M
3083 B              1       ECL      38.5    6.9           MF  1982   $2M
3083 J              1       ECL      38.5    8.9           MF  1982   $3M
3081 D              2       ECL              11            MF  1981
3081 G              2       ECL      38.5   12.6           MF  1983  $3.3M
3081 K              1       ECL      38.5    16            MF  1982  $4.3M
3084 Q              4       ECL      38.5    28            MF  1983  $8.7M
3083 CX             1       ECL      41.7    3.7           MF  1985  $605K
3083 EX             1       ECL      41.7     5            MF  1984  $960K
3083 BX             1       ECL      41.7    7.3           MF  1984  $1.7M
3083 JX             1       ECL      41.7    9.5           MF  1984  $2.6M
3081 GX             2       ECL      41.7   13.6           MF  1984  $2.8M
3081 KX             2       ECL      41.7   17.8           MF  1984  $3.4M
3084 QX             4       ECL      41.7    31            MF  1984  $6.9M

IBM                      OS MVS
                         Cost excludes VF (MFLOPS results)
3090-120E           1       ECL      54.1     9     108    MF  1987  $985K
3090-150E           1       ECL      56.2   12.2    112    MF  1987 $1.65M
3090-180E           1       ECL      58.1   19.4    116    MF  1987  $2.7M
3090-280E           2       ECL      58.1   35.5    232    MF  1988  $4.9M
3090-200E           2       ECL      58.1   35.5    232    MF  1987  $4.6M
3090-300E           3       ECL      58.1    52     348    MF  1987  $5.6M
3090-400E           4       ECL      58.1    64     464    MF  1987  $8.4M
3090-500E           5       ECL      58.1    78     580    MF  1988  $9.7M
3090-600E           6       ECL      58.1    89     696    MF  1987 $10.3M

Filemode 7-9?

From: <lynn@garlic.com>
Subject: Re: Filemode 7-9?
Date: Tue, 25 Oct 2005 01:31:15 -0700
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers

a little more drift related to growth of internal network in 83
https://www.garlic.com/~lynn/internet.htm#22

the 4341 follow-on was originally going to be an 801-based chip
https://www.garlic.com/~lynn/subtopic.html#801

however, there was a document produced showing that it was now possible to get 370 in silicon. the 801 strategy had been to take all the internal microprocessors and converge to a single chip architecture for microprocessors. however, the document showed that is was getting to be possible to directly implement 370 in silicon ... as opposed to taking a simpler microprocessor silicon engine and implementing 370 in microprogramming. however, by the time that 4381 shipped ... the great exploding market segment that saw 4341 and vax uptake was starting to move to workstations and high-end PCs. slightly related posting
https://www.garlic.com/~lynn/2004g.html#24 |d|i|g|i|t|a|l| question

some of the vax numbers during the period:
https://www.garlic.com/~lynn/2002f.html#0 Computers in Science Fiction

Filemode 7-9?

From: <lynn@garlic.com>
Newsgroups: bit.listserv.vmesa-l
Subject: Re: Filemode 7-9?
Date: Sat, 29 Oct 2005 00:33:37 -0700

in the above reference by rochester ... there is some chance that the individual cited ... i may have been their direct report at some point.

Random Access Tape?

From: <lynn@garlic.com>
Newsgroups: alt.comp.hardware,alt.computers,alt.folklore.computers
Subject: Re: Random Access Tape?
Date: Sun, 30 Oct 2005 11:22:44 -0800

one was redoing the cp67 implemention supporting the 2301 "drum" increasing the peak 4k page transfers from about 80/sec to 300/sec. the other was the handling of the 3330 disk when trying to do sequential transfers of 4k pages that might reside on different track ... but at the same arm/cyl. position.

i also did some further stuff when doing the page mapped filesystem support ... playing games with re-ordering requests for optimal revolution and arm motion ... even when the requests were originally presented in some totally different ordering. recent post in the same referenced thread
https://www.garlic.com/~lynn/2005s.html#25 MVCIN instruction

note that the cms filesystem i/o was something left over from real i/o paradigm ... that then had to be simulated in a virtual memory environment. the "simulation" process would execute the disk i/o in the order pass to it. the changes for page mapping allowed the i/o ordering to be re-organized for optimal execution. some more on that subject
https://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction

feasibility of certificate based login (PKI) w/o real smart card

From: <lynn@garlic.com>
Newsgroups: microsoft.public.security.crypto
Subject: Re: feasibility of certificate based login (PKI) w/o real smart card
Date: Mon, 31 Oct 2005 09:37:46 -0800

there is a business process called public key ... where on of the keys (of an asymmetric key pair) is identified as public and made readily available; the other key (of the pair) is identified as private, kept confidential and never divulged.

there is a business processed called digital signature ... where a hash of a message/document is computed and encoded with the private key resulting in the digital signature. The message/document along with the (encoded hash) digital signature is transmitted. The recipient (or relying party) then can recompute the hash, decode the digital signature with the corresponding public key and compares the two hashes. if the two hashes are the same, then the recipient can assume

1) the message/document hasn't changed since the digital signature was originally calculated 2) something you have authentication, aka the originator has access to and use of the corresponding private key.

from 3-factor authentication paradigm
https://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have
• something you know
• something you are

... the verification of the digital signature typically represents something you have authentication.

the digital signature business process has assurance and integrity dependencies on the level of preserving the confidentiality of the private key. in many cases, private keys are protected by purely software means which have numerous threats and vulnerabilities. Various kinds of hardware security tokens have been developed for improving the confidential integirty and assurance of the private key
https://www.garlic.com/~lynn/subintegrity.html#assurance

the original pk-init draft for kerberos
https://www.garlic.com/~lynn/subpubkey.html#kerberos

originally just specified registering a public key in lieu of password and performing straight-foward digital signature verification in lieu of password matching. subsequently, the support for PKIs (certification authorities, digital certificates, etc) was added to pk-init draft .... supplementing straight-forward authentication via digital signature verification
https://www.garlic.com/~lynn/subpubkey.html#certless

there is this business process frequently referred to as PKI which was targeted at the letters of credit (or letters of introduction) paradigm from the sailing ship days. it was somewhat methodology for addressing the offline email operation from the early 80s ... i.e. dial-up the (electronic) postoffice, exchange email, hangup, and then process email. The recipient could possible then be faced with processing first-time email from a total stranger. The idea behind PKIs and x.509 identity certificates was to provide sufficient information for the recipient to decide how to deal with first-time communication from an otherwise total stranger ... and not having any local resources AND having no direct communication mechanism for determining anything about the total stranger.

In the early 90s, this was somewhat expanded ... to suggest that x.509 identity certificates should be appended to all operations ... converting even the simplist of authentication operations into heavy weight identification operations. It was further aggravated by certification authorities not necessarily knowing all possible identification information that a relying party might require about a total stranger. This somewhat led in the direction of attempts to grossly overload x.509 identity certificates with enormous amounts of personal information.

In the extension of kerberos pk-init to include support for PKI ... it basically implies that a total stranger, by presenting an x.509 identity certificate, will be authenticated and allowed to access the system.

in fact, most such systems don't actually do this ... effectively negating the basic PKI design point ... and with a little analysis, it is then trivial to demonstrate that the actual digital certificates are redundant and superfluous.

recent post with similar theme
https://www.garlic.com/~lynn/aadsm21.htm#20 Some thoughts on high-assurance certificates

Somebody is certified to access the system, their public key is then registered in the infrastructure ... as per the original kerberos pk-init draft ... and possibly additional information is also certified and recorded along with the public key. For instance, integrity information that might be worth certifying is whether or not the private key is protected by some form of hardware token and the level of protection said hardware token actually provides. Another pieces of certified integrity information might be whether the correct operation of the hardware token requires a PIN. A relying party that knows the integrity level of the private key protection might be willing to allow higher risk than if they had no information regarding the private key protection. Also a hardware token with a PIN requirement then can imply two-factor authentication ... aka from
• something you have
• something you know
• something you are

a PIN would imply something you know authentication in addition to the something you have authentication represented by the token. From a threat model standpoint .... PINs can be viewsd as countermeasure to lost/stolen tokens.

The corresponding process w/o using a hardware token is a software container where the processes surrounding the access and use of the software container approx. that of a hardware token. The software container may have the contents encrypted and a PIN/PASSWORD required for every extraction and use of the private key (this corresponds to the hardware token PIN countermeasure to a lost/stolen token).

An advantage of the hardware token ... is that most software containers can be replicated/copied ... possibly w/o the owner's knowledge. The attacker then can spend some brute force recovering the private key and be able to impersonate the rightful owner for some period. The other countermeasure for lost/stolen hardware token, is the owner reports it as lost/stolen (which allows the corresponding public key to be revoked). In the case of the software container being replicated/copied, the owner may not even realize that it has happened.

Note that the issue of PKIs and digital certificates are an additional business process layered on top of digital signature verification for simple authentication. The PKI and digital certificate business process layers were created so that stand-alone identification and processing could be performed for total strangers by the relying party w/o needing any previous contact and/or any other sources of information.

P2P Authentication

From: <lynn@garlic.com>
Newsgroups: comp.security.misc
Subject: Re: P2P Authentication
Date: Mon, 31 Oct 2005 12:51:19 -0800

there is a business process where one key (of the key pair) is identified as public and made readily available; the other key is identified as private and kept confidential and never divulged.

there is a business process called digital signature where a hash of a message/document is calculated and encoded with the private key, resulting in the digital signature. the originator then transmits the document/message along with the digital signature. The recipient recalculates the hash, decodes the digital signature with the appropriate public key (taken from the recipient's trusted public key repository) and compares the two hashes. If the two hashes are the same, then the recipient assumes that

1) the message hasn't be modified since the digital signature was calculated
2) something you have authentication, i.e. the originator has access and use of the corresponding private key.

to somewhat address the business opportunity analogous to the letters of credit from the sailing ship days ... there is business process involving PKI, certification authorities, and digital certificates. The target is somewhat the offline email from the early 80s, i.e. dial-up the (electronic) post-office, exchange email, hang-up and process email. The recipient may be dealing with first-time communication from total stranger with no recourse to information about the stranger.

in this scenario, the stranger has gone to a certification authority and had certain information certified. the certification authority issues a digital certificate containing the certified information and the applicant's public key. this digital certificate is digitally signed by the certification authority. in this scenario, the stranger appends their digital ceritifcate to the digitally signed message/document (as in the above description). the recipient first performs the digital signature verification process on the digital certificate issued by the certification authority (i.e. retrieving the certification authority's public key from the recipient's trusted public key respository to verify the certification authority's digital signature on the digital certificate). once the digital certificate has been validated, the recipient then retrieves the originator's public key from the digital certificate (having already verified the certification authority's digital signature) and uses the originator's public key to verify the digital signature on the actual message.

Given that the originator's digital signature verifies, the recipient now can use the other information in the digital certificate to determine how to deal with first-time communication from total stranger.

one of the issues that came up with this approach was the work on x.509 identity certificates in the early 90s. an objective was to require that an x.509 identity certificate would be appended to all digitally signed operations, turning even the most trivial authentication operations into heavy duty identification operations (even when first time communication between complete strangers wasn't involved). The other issue was that it wasn't necessarily clear to certification authorities, at the time, exactly what identification information might be required by relying parties in the future ... so there was some direction to overload x.509 identity certificates with enormous amounts of personal information.

in the mid-90s there was some direction involving relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

because of the realization that enormous amounts of personal information in x.509 identity certificates represented significant privacy and liability issues. as a result, the entity information from the digital certificate was moved into some sort of repository entry at the relying-party, and replaced in the digital certificate with some sort of index value into the repository. however, it is trivial to show that such digital certificates became redundant and superfluous, in part because it basically invalidates the fundamental justifications for PKIs ... i.e. to provide a solution for first time communication between complete strangers.

for some topic drift ... a couple recent related postings on the subject
https://www.garlic.com/~lynn/2005s.html#42 feasibility of certificate based login (PKI) w/o real smart card
https://www.garlic.com/~lynn/aadsm21.htm#20 Some thoughts on high-assurance certificates

winscape?

From: <lynn@garlic.com>
Newsgroups: alt.folklore.computers
Subject: Re: winscape?
Date: Wed, 02 Nov 2005 06:11:39 -0800

and then on hundreds of other machines (eventually accumulated something like decade of information). this help motivate the work on synthetic workloads, benchmarking, performance modeling, performance profiling and the work that eventually evolved into capacity planning.

on of the applications was an apl-based analytical model that evolved into the marketing support tool available on hone called performance predictor
https://www.garlic.com/~lynn/subtopic.html#hone

that allowed marketing people to input information about customer configuration and load and ask what-if questions (changes to load and/or hardware).

when i was getting ready to release the resource manager & fair-share scheduler
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

a wide spectrum of synthetic workloads and configuraitons were evaluated for calibrating the operation of the resource manager. then a modified version of the performance perdictor was created which examined a broad range of customer workload and configuration data and created an automated benchmark specification (configuration, system options, synthetic workload characteristics). the benchmark would be run and the results feed into the modified predictor. The predictor validated the expected results for the resource manager and then also used the information as input for choosing the next benchmark configuration. This process itereated eventually for 2000 benchmarks that took three months of elapsed time to run.
https://www.garlic.com/~lynn/submain.html#bench

note that the overall system technology was not only used for a lot of commercial and gov. installations ... but also used as the basis for a number of commercial time-sharing offerings (including the hone system that provided world-wide field, sales, and marketing support):
https://www.garlic.com/~lynn/submain.html#timeshare

some minor drift
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

winscape?

From: <lynn@garlic.com>
Newsgroups: alt.folklore.computers
Subject: Re: winscape?
Date: Wed, 02 Nov 2005 13:27:55 -0800

for a little topic drift ... there was an industry service that collected erep data (ras and error recording data) from large number of customer installations .... somewhat removed customer identifying information and published summaries on machines. customers could compare reliability data on different machines, models, disks, etc. both from vendor as well as all the clone processors, controllers, devices, etc.

in late 1980 time-frame, stl was going to move something like 300 ims programmers to an offsite location. they really hated the idea of having to access systems at stl via remote 3270. I wrote HYPERchannel driver support that was basically a form of channel extension ... which allowed moving "local" kind of devices to remove location ... and sort of allowed them to operate over high-speed telco links.

as part of doing the driver support for channel extension ... i had to translate various kinds of unrecoverable telco errors back into some form of emulated local channel error (where then the standard ras support would do additional retries/restarts as well as record the information).

when 3090 processor had been in customer shops for a year ... one of the 3090 product managers tracked me down. they had predicted that for a certain class of channel errors, the 3090 would have approx. 3-5 such errors .... per year across ALL 3090s (i.e. not 3-5 errors per 3090 per year ... but 3-5 errors per year total aggregate across all 3090s). the industry service was reporting something like 15-20 total errors of this kind for the previous year across all installed 3090s.

it turned out that the emulated channel error condition that i had chosen had gotten out into driver support that was shipped to some customers ... and that the additional 10-17 errors for the 3090 product line for the previous year was coming from a customer that had this channel extension software installed. the report of these additional dozen or so errors for the 3090 product line year was causing an enormous commotion.

so i looked at the problem for awhile ... and there was another channel related error condition that i could emulate ... that for all intent resulted in the same RAS process ... but didn't inflate the statistic of specific interest.

a couple recent postings on the same subject
https://www.garlic.com/~lynn/2005d.html#28 Adversarial Testing, was Re: Thou shalt have no
https://www.garlic.com/~lynn/2005e.html#13 Device and channel

misc. past collected hsdt postings
https://www.garlic.com/~lynn/subnetwork.html#hsdt

previous post in this thread mentioning time-sharing and 3274
https://www.garlic.com/~lynn/2005s.html#17 winscape?

other recent postings touching on time-sharing subject
https://www.garlic.com/~lynn/2005r.html#12 Intel strikes backw ith a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#14 Intel strikes backw ith a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#15 Intel strikes backw ith a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#16 Intel strikes backw ith a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#28 Intel strikes backw ith a parallel x86 design
https://www.garlic.com/~lynn/2005s.html#26 IEJ/IEB/... names??

Various kinds of System reloads

From: <lynn@garlic.com>
Newsgroups: alt.folklore.computers,bit.listserv.vmesa-l
Subject: Re: Various kinds of System reloads
Date: Thu, 03 Nov 2005 04:09:58 -0800

part of booting the system including bringing up the spool file system ... and was prerequisite to the system coming up .... so it had to come up. in part, the "spool file" disk area tended to be shared between spool files and dynamic virtual memory paging. if the area wasn't initialized and available ... you also didn't have paging ... integral to the operation of the system.

oiriginally a cold start was that it initialized the area to completely empty (all existing data was lost). warm shtudown would write in-storage allocation information to disk at shutdown typically on boot, this information would be reread back into memory. on things like power-failure ... the system went down w/o having written the warm start information and had to come up cold. cp67 also added automatic creation of a "dump file" (in the system spool area) on a kernel crash ... and then automatic reboot (kernel failure, dump, save warm data, reboot, and warm start could be done in a minute or two.

there is this story about somebody at mit making a kernel change to one of their systems in an i/o driver and having 26 system crashes and reboots in the course of the day. the story is that this prompted some improvements in multics ... since multics at the time supposedly might take an hr or so to come back up after a crash
https://www.multicians.org/thvv/360-67.html

part of this was that the cp67 & vm370 stuff was done at the science center on 4th flr of 545 tech sq
https://www.garlic.com/~lynn/subtopic.html#545tech

and multics was being done on the 5th flr of 545 tech sq.

to handle the power failure case, chkpt start was added. during normal operation, a very abbreviated vesion of some in-storage control information was written to disk. if reboot selected chkpt start ... boot would read the abbreviated information and then use that to reread the spool area to recreate the rest of the information. this was somewhat analogous to fsck since the reread/reconstruct could take an hr for a spool system with a large number of files.

the automatic reboot would bring the system back to the point where users could log back in. however, over the years, lots of automated processes were added to normal operating environment ... and these required manual initialization.

for the automated benchmarking process, mention in recent post
https://www.garlic.com/~lynn/2005s.html#44 winscape?
https://www.garlic.com/~lynn/2005s.html#45 winscape?

i had added a boot process that could be used to start up these automated processes at boot as part of normal production operation. the purpose for automated benchmark
https://www.garlic.com/~lynn/submain.html#bench

was to allow rebooting between the automated benchmarking ... to have a clean, fresh startup between each benchmark. the automated benchmarking could run for days unattended ... with automated reboot and starting each new benchmark.

this feature was incorporated in standard released system and is now part of standard production vm operation.

later doing some high-speed networking support as part of hsdt
https://www.garlic.com/~lynn/subnetwork.html#hsdt

i did "spool file system" rewrite ... recent lengthy post discussing characteristics of sfs rewrite
https://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction

it was primarily to significantly improve the performance ... but while i was at it ... i changed the paradigm so that spool areas could be added & removed during normal operation (w/o rebooting the system). this had the side-effect that even if chkpt-like start was required .... the system reboot didn't have to be delayed until it finished (i also redid how the chkpt operation was implemented so that it was significantly quicker).

Gartner: Stop Outsourcing Now

From: <lynn@garlic.com>
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Subject: Re: Gartner: Stop Outsourcing Now
Date: Thu, 03 Nov 2005 04:43:47 -0800

i remember going thru sales pitch and mock up of 747. one of the lines that stuck in my mind was that 747 would be carrying so many people that airports would ALWAYS use at least four jetways (two on each side) ... to avoid passenger congestion getting on and off.

part of the current issue is that IT is being used for a wide variety of purposes ... from trivial word processing to integral part of business decision making. outsourcing has supposedly been acceptable for commodity operations that don't actually provide any business competitive advantage. one confusion factor may be understanding what parts of IT are just commodity operations that provide no competitive advantage and which parts of IT are actually fundamental to the core business uniqueness.

one of my offspring had a co-op job when he was going to school at an air freight forwarding company (he answered phones and took freight orders ... he had to memorize most of the airport 3letter codes and frieght dimenisons sizes for most of the flying planes). one of the things they also handled was aog (not oag, official airline guide, aog ... airline on ground) for replacement equipment. typically parts were air freighted to the airport with the plane on the ground ... but periodically it required physical cuourier of the part to some place in the world. they had converted to emailing the equipment invoices to the part depot (instead of physical paper). during one of the past internet virus outbreaks, their email was offline for several days ... and they had to try to find real paper invoice forms and physically carrying the invoice to the part depot. it was quite traumatic.

one could claim that a large part of business communication has now been outsourced to the internet ... w/o necessarily understanding all the implications.

and of course, i couldn't finish w/o mentioning my favorite competitive business subjects ... john boyd ... collection of my past posts
https://www.garlic.com/~lynn/subboyd.html#boyd

and numerous other boyd pages from around the web
https://www.garlic.com/~lynn/subboyd.html#boyd2

sample from above:
http://www.belisarius.com/
https://web.archive.org/web/20010722050327/http://www.belisarius.com/

Gartner: Stop Outsourcing Now

From: <lynn@garlic.com>
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Subject: Re: Gartner: Stop Outsourcing Now
Date: Thu, 03 Nov 2005 06:09:29 -0800

as an aside ... during that period ... there was a number of companies that sort of spun off their IT operations as independent business units. part of the issue was that internal corporate politics frequently interfered with running an efficient IT operation. there was frequently large capital requirements with long preparation periods ... capital justification, physical facilities, simple long times for order delivery. there were frequently all sorts of internal corporate politics that would interfer with managing all of the practical aspects in an efficient manner. separate business operation would create slightly more business like relationship between the IT organization and the rest of the business; some of it was as simple as changing IT from being a cost center to being a profit center (at least as far as books were concerned ... i.e. even if it was corporate funny money ... there were real live business transfers between business operations). there are some aspects of that in some of the current IT outsourcing ... where delivery of IT business operation to an outside business, manages to address some internal corporate politics that couldn't be addressed any other way.

phishing web sites using self-signed certs

From: <lynn@garlic.com>
Newsgroups: netscape.public.mozilla.crypto
Subject: Re: phishing web sites using self-signed certs
Date: Thu, 03 Nov 2005 14:09:44 -0800

• who is doing certification
• what process are they using for certification
• are they willing to accept liability associated with their certification
• how is the certification represented

using a taxonomy that clearly delineates the difference between certification of information from using digital certificates for representing that certification process ... somewhat shows up some of the fallicy of self-signed digital certificates .... part of this is sometimes people seem to be confusing the existance of a digital certificate as having some magical certification quality all by itself ... rather than as a representation of some certification process.

PKIs and digital certificates are a business process to address the letters of credit paradigm from the sailing ship days for offline certification representation ... i.e. the relying party has no mechanism for doing real-time and/or online checking the validity of the information. furthremore, current generation of certification authorities have tended to be independent 3rd parties who are checking with various authoritative agencies as to the validitity of some information and then issuing certificates that represent that such a checking process has been done. they typically haven't been the authoritative agency actually responsible for the verified information.

as the online world with the internet becoming more pervasive ... some of the authoritative agencies actually responsible for various kinds of information being verified have looked at providing online, real-time verification services associated with the information in question (as opposed to the stale, static certificate model that was designed to meet the needs of relying parties that had no direct way of actually contacting the authoritative agency for directly verifying the information).

to some extent, as the online, internet world has become more pervasive ... the target offline market for digital certificates has shrunk and there has been some migration to the no-value market segment. rather than the relying party being unable to directly contact the authoritative agency responsible for the information, the no-value market has the relying party doing operations where there is insufficient value justification for directly contacting the authoritative agency (aka no-value operations). even this market segment is shrinking as the internet is not only providing pervasive world-wide online connectivity but also drastically reducing the cost of that online connectivity world-wide.

a couple related posts on the subject:
https://www.garlic.com/~lynn/2005s.html#43 P2P Authentication
https://www.garlic.com/~lynn/aadsm21.htm#20 Some thoughts on high-assurance certificates
https://www.garlic.com/~lynn/aadsm21.htm#21 Some thoughts on high-assurance certificates

misc. collected past posts on ssl domain name server certificates
https://www.garlic.com/~lynn/subpubkey.html#sslcert

misc. collected past posts on certification enviornments that can be done w/o requiring digital certificates for representing that certification
https://www.garlic.com/~lynn/subpubkey.html#certless

Various kinds of System reloads

From: <lynn@garlic.com>
Newsgroups: alt.folklore.computers,bit.listserv.vmesa-l
Subject: Re: Various kinds of System reloads
Date: Fri, 04 Nov 2005 04:22:48 -0800

cp67 (and vm370) "sysgen" was even simpler. the txt decks (output from the assembler) were bundled together and booted from cards using a card loader from BPS (basic progamming system ... about the most primitive of the systems for s/360). when the BPS loader had gotten everything into memory image ... it transferred control to cpinit. cpinit wrote a page formated image (of what had just been loaded into memory) to disk ..... and then wrote the necessary disk boot/ipl records to read cpinit back into memory.

on disk boot/ipl, cpinit would be read back into memory ... it would recognize that it was being loaded from disk (rather than in the earlier bps loader p;rocess) and reverse the earlier process of page block i/o for the kernel image ... this time doing reads instead of writes. once the kernel image was back into memory, it would then do the cold/warm(/ckpt) process for spool file system. after that it would transfer control to normal kernel operation.

my modification for doing the automated benchmarking was one of the last things invoked by cpinit process before transferring control to standard kernel processing (cpinit in vm370 was renamed dmkcpi)
https://www.garlic.com/~lynn/submain.html#bench

this auomated startup procedure was released as part of the standard product.

random past posts mentioning bps loader:
https://www.garlic.com/~lynn/94.html#11 REXX
https://www.garlic.com/~lynn/98.html#9 ** Old Vintage Operating Systems **
https://www.garlic.com/~lynn/99.html#135 sysprog shortage - what questions would you ask?
https://www.garlic.com/~lynn/2000b.html#32 20th March 2000
https://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2001b.html#26 HELP
https://www.garlic.com/~lynn/2001b.html#27 HELP
https://www.garlic.com/~lynn/2002f.html#47 How Long have you worked with MF's ? (poll)
https://www.garlic.com/~lynn/2002h.html#35 Computers in Science Fiction
https://www.garlic.com/~lynn/2002i.html#2 Where did text file line ending characters begin?
https://www.garlic.com/~lynn/2002n.html#62 PLX
https://www.garlic.com/~lynn/2002n.html#71 bps loader, was PLX
https://www.garlic.com/~lynn/2002n.html#72 bps loader, was PLX
https://www.garlic.com/~lynn/2002n.html#73 Home mainframes
https://www.garlic.com/~lynn/2002p.html#56 cost of crossing kernel/user boundary
https://www.garlic.com/~lynn/2002p.html#62 cost of crossing kernel/user boundary
https://www.garlic.com/~lynn/2003f.html#3 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#26 Alpha performance, why?
https://www.garlic.com/~lynn/2003o.html#23 Tools -vs- Utility
https://www.garlic.com/~lynn/2004b.html#33 A POX on you, Dennis Ritchie!!!
https://www.garlic.com/~lynn/2004f.html#11 command line switches [Re: [REALLY OT!] Overuse of symbolic
https://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
https://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005f.html#16 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005g.html#52 Software for IBM 360/30

random past posts mentioning having redone os/360 stage2 sysgen:
https://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
https://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
https://www.garlic.com/~lynn/97.html#28 IA64 Self Virtualizable?
https://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
https://www.garlic.com/~lynn/99.html#93 MVS vs HASP vs JES (was 2821)
https://www.garlic.com/~lynn/2000d.html#50 Navy orders supercomputer
https://www.garlic.com/~lynn/2001d.html#48 VTOC position
https://www.garlic.com/~lynn/2001h.html#12 checking some myths.
https://www.garlic.com/~lynn/2001l.html#39 is this correct ? OS/360 became MVS and MVS >> OS/390
https://www.garlic.com/~lynn/2002b.html#24 Infiniband's impact was Re: Intel's 64-bit strategy
https://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
https://www.garlic.com/~lynn/2002c.html#51 cp/67 addenda (cross-post warning)
https://www.garlic.com/~lynn/2003c.html#51 HASP assembly: What the heck is an MVT ABEND 422?
https://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming
https://www.garlic.com/~lynn/2004k.html#41 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2004l.html#29 FW: Looking for Disk Calc program/Exec
https://www.garlic.com/~lynn/2005b.html#41 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005h.html#6 Software for IBM 360/30 (was Re: DOS/360: Forty years)
https://www.garlic.com/~lynn/2005m.html#16 CPU time and system load
https://www.garlic.com/~lynn/2005n.html#40 You might be a mainframer if... :-) V3.8
https://www.garlic.com/~lynn/2005o.html#12 30 Years and still counting
https://www.garlic.com/~lynn/2005q.html#7 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2005r.html#0 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#38 IEH/IEB/... names?

phishing web sites using self-signed certs

From: <lynn@garlic.com>
Newsgroups: netscape.public.mozilla.crypto
Subject: Re: phishing web sites using self-signed certs
Date: Fri, 04 Nov 2005 04:48:54 -0800

PKIs, certification authorities, and digital certificates extended this process .... targeted for first time communication between two strangers that had no other method of resolving information about each other.

the certification authority would take information about an applicant (including their public key), validate the information and package the information in a digitally signed message called a digital certificate.

as part of this infrastructure ... using a standard out-of-band process for relying-parties dealing with trusted public keys, the certification authorities would distribute their public keys packaged in self-signed digital certificates. the relying parties would use standard out-of-band process for validating the certification authority's public key (contained in a certificastion authority's self-signed digital certificate) before loaded the certification authority's public key into the relying party's trusted public key repository.

in the future, any time the recipient/relying party received one of these specially formated digitally signed messages called digital certificates, they would retrieve the corresponding public key from their trusted public key repository to verify the certification authoritiy's digital signature on the digital certificate.

this part of the process is idential whether trusted publc keys from normal individuals are invovolved or trusted public keys from trusted certification authorities are involved. in both cases, the subject public keys have been validated by some out-of-band process before loading into the recipient/relying-party trusted public key repository.

the PKI, certification authority paradigm then defined a special cascading process relying on specially formated digitally signed message called a digital certificate ... allowing relying parties to deal with first time communication with a stranger and not having any other real-time or local mechanism for resolving information about the stranger.

from a theoritical digital signature business process ... the out-of-band ability to validate information associated with a self-signed (certificate) message before loading the corresponding public key into the recipient's trusted public key repository ... is no different for certification authority public keys or normal individual public keys.

In digital signature implimentations like PGP, there tends to be a lot more administrative support for relying parties to manage the public keys in their local trusted public key repositories.

TTP and KCM

From: <lynn@garlic.com>
Newsgroups: netscape.public.mozilla.crypto
Subject: Re: TTP and KCM
Date: Sat, 05 Nov 2005 04:25:31 -0800

one could claim that the business process part of KCM is essentially the old business process of registering pin/passwords and then continuing to use them over long periods of time.

that is also the PGP model ... of registering public keys in lieu of pin/password ... and doing digital signature verification with the registered public keys; aka the relying party having a set of registered public keys in their trusted repository of public keys.

note that, the foundataion for all the PKIs ... are in fact based on using this very business process model for establishing their root trusts. every relying party has to have a trusted repository of registered public keys in order for anything to work (even PKI). frequently, in the case of PKI supported processes ... they attempt to restrict the registration of public keys (in relying party trustued repositories) to just those entities called certification authorities.

when relying party trusted repositories are restricted to just the registration of public keys from certification authorities .... then those corresponding public keys are only used to validate digital signatures on special purpose messages called digital certificates. however, as repeatedly pointed out in the past ... the business process of using registered public keys from the relying party's trusted repository of registered public keys to verify digital signatures on messages .... turns out to be the same exact business process that is used whether the digital signatures being verified are applied to specially formated messages called digital certificates ... or any message ... regarldess of the contents.

if the TTP model were to declare that the business process of registerting public keys in the relying party's trusted public key repository was not possible ... then it would also not be possible for the relying party to have certification authority public keys (distributed in self-signed digitgal certificates) available ... and the whole TTP process collapses.

note that x.509 identity certificate standards from the early 90s had some interesting standards issues. to glaring issues were

1) the x.509 identity certificate non-repudiation bit ... which somehow conveyed the magical properties that if a relying party could produce a digital certificate that contained the public key and the non-repudiation bit set ... then it prooved that for any document or message digitally signed by the originator ... also carried with it the properties that the signer had read, understood, agrees, approves, and/or authorizes the contents of the signed object.

2) TTPs were somewhat unsure as to what information, furture relying parties, might find of interest. as a result there was some direction to grossly overload x.509 identity certificates with enormous amounts of personal information. by the mid-90s, there was a increasing realization that x.509 identity certificates grossly overloaded with personal information represented significant privacy and liability issues.

in the case of #2 and the enormous privacy issues represented by x.509 identity certificates ... you found some number of organizations retrenching to relying-party-only certificates ... some number of past collected postings on relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

basically the enormous amounts personal information is moved to some sort of database and replaced in the digital certificate with a database index or lookup value. however, it is trivial to demonstrated that relying-party-only certificates are redundant and superfluous.

in the case of #1 above, there are a variety of issues.

a) fundamentally, digital signature verification can be treated as a form of something you have authentication ... from the 3-factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have
• something you know
• something you are

there was a direction with x.509 identity certificate standards to mandate that all digitally signed operations required the appending of an x.509 identity certificates. This basically morphed all digital signature authentication operations (even the simplist and most straight-foward authentication) into heavy-weight identification operatons.

b) a nominal digital signature authentication may involve the server transmitting some random data as a kind of challenge (for instance, as countermeasure to replay attacks). the receiver, digitally signs the data and returns the digital signature for authentication. the contents of the challenge is not normally examined by the person doing the digital signing. the digital certificate non-repudiation bit would imply that if the relying-party could produce any digital certificate with the non-repudiation bit set (for the signer's public key) ... then it was proof that the signer had read, understood, agrees, approves, and/or authorizes what was digitally signed (even if the person had not actually examined what was signed).

misc. past posts referencing dual-use attacks (people thinking they are signing random data ... and it turns out to be some valid transaction or contract) and/or non-repudiation attacks (note that the definition of the standards non-repudiation bit has since become significantly depreciated).

misc. past posts on dual-use attacks:
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
https://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows
https://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
https://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols
https://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
https://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called)

previous, next index - home