From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "Mainframe" Usage Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 06 Mar 2000 20:14:26 GMTMarco S Hyman writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "Mainframe" Usage Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Mon, 06 Mar 2000 21:12:47 GMTanother side-subject was trying to get High Speed Protocol definition thru ANSI/ISO.
Basically anything that violated the 7-layer "rule" got stomped on.
Overview of the OSI model's layers
Physical
Data Link
Network
Transport
Session
Presentation
Application
TCP/IP itself, violates the OSI 7-layer model.
LANs violated the 7-layer model (effectively combining layers 1, 2, and part of 3 ... i.e. physical, data link, and part of network layer) into single piece. In some respect, LAN got done by going thru IEEE as a hardware standard and bypassing the ANSI/ISO networking politics.
HSP effectively would collapse the remaining pieces of 3 (not already in LANs) and layer 4 (transport) into a single layer; which in the optimal case would have two layers (LAN & HSP) below session.
HSP attempted to address a number of issues ... including high thruput, low latency, and transactions. In the transaction relm, HSP attempted to do a 3-packet exchange reliable protocol (compared to 7-packet minimum exchange for current TCP, and 5-packet minimum exchange for VMTP/RFC1045).
One of the issues in high thruput was being able to stream/pipeline data ... packets with (IP) header checksums were a big thing (i.e. you couldn't send the header out until the full message was processed, its checksum calculated and the value stuffed in the header ... so needed intermediate buffering equal to the largest possible message ... or direct addressing to the original message).
from: rfc1122:
3.2.1.2 Checksum: RFC-791 Section 3.1
A host MUST verify the IP header checksum on every received datagram and silently discard every datagram that has a bad checksum.
========
these days, LANs, modems, adapters, etc ... most transmission methodologies all have extensive built-in error detecting & even forward error correction.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "Mainframe" Usage Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Tue, 07 Mar 2000 01:29:26 GMTdon@news.daedalus.co.nz (Don Stokes) writes:
from rfc793:
TCP Header Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCP Header Format
& from rfc1700
TCP OPTION NUMBERS The Transmission Control Protocol (TCP) has provision for optional header fields identified by an option kind field. Options 0 and 1 are exactly one octet which is their kind field. All other options have their one octet kind field, followed by a one octet length field, followed by length-2 octets of option data. Kind Length Meaning Reference ---- ------ ------------------------------- --------- 0 - End of Option List [RFC793] 1 - No-Operation [RFC793] 2 4 Maximum Segment Lifetime [RFC793] 3 3 WSOPT - Window Scale [RFC1323] 4 2 SACK Permitted [RFC1072] 5 N SACK [RFC1072] 6 6 Echo (obsoleted by option 8) [RFC1072] 7 6 Echo Reply (obsoleted by option 8)[RFC1072] 8 10 TSOPT - Time Stamp Option [RFC1323] 9 2 Partial Order Connection Permitted[RFC1693] 10 5 Partial Order Service Profile [RFC1693] 11 CC [Braden] 12 CC.NEW [Braden] 13 CC.ECHO [Braden] 14 3 TCP Alternate Checksum Request [RFC1146] 15 N TCP Alternate Checksum Data [RFC1146] 16 Skeeter [Knowles] 17 Bubba [Knowles] 18 3 Trailer Checksum Option [Subbu & Monroe]--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "Mainframe" Usage Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Tue, 07 Mar 2000 02:33:19 GMTdon@news.daedalus.co.nz (Don Stokes) writes:
IP is designed to fit between network layer and transport layer and provide an additional network abstraction (not provided for in the OSI model).
misc. other refs.
IEN32
IEN111
IEN166
... from ien111:
For example, a TCP module would call on the internet module to take a
TCP segment (including the TCP header and user data) as the data
portion of an internet datagram. The TCP module would provide the
addresses and other parameters in the internet header to the internet
module as arguments of the call. The internet module would then
create an internet datagram and call on the local network interface to
transmit the internet datagram.
===============
which places IP above the network layer ... but below the transport layer. In the case of LAN network, the IP module would call the LAN network interface ... which would prefix a LAN network header in front of the IP internet header (which had been prefixed in front of the TCP transport header)
random references:
http://www.garlic.com/~lynn/99.html#37b
http://www.garlic.com/~lynn/99.html#38b
http://www.garlic.com/~lynn/99.html#38d
in the diagram taken from IEN-166 at:
http://www.garlic.com/~lynn/2000.html#72
The transport TCP intefaced to the internet IP layer
The internet IP layer interfaced to the network 1822/IMP layer
The network 1822/IMP layer (actually IMP) handled the data link & physical layer.
In the case of LANs today
THe transport TCP layer interface to the internet IP layer (& the internet ip layer adds a IP header in front of the TCP header)
The internet IP layer interface to the network LAN layer (& the network LAN layer adds a network header in front of the internet IP header)
The network LAN layer then handles the two lower levels.
In the case of most point-to-point links
The transport TCP layer interface to the internet IP layer (& the internet ip layer adds a IP header in front of the TCP header)
The internet IP layer interface ot the network PPP layer (& the network PPP layer adds a network header in front of the internet IP header)
The network PPP layer then handles the two lower levels.
Four layer TCP/IP would looks something like
1 physical/data link (osi 1&2)
2 network layer (osi 3)
3 IP/internet layer (osi ???)
4 transport TCP layer (osi 4)
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "Mainframe" Usage Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Tue, 07 Mar 2000 03:47:34 GMTdon@news.daedalus.co.nz (Don Stokes) writes
CPU Utilization at Gigabit Speeds
At gigabit speeds, routine networking tasks such as TCP/IP checksum
calculations can easily tie up the processor, resulting in 100 percent
CPU utilization. This leaves no processing power for running other
applications. Therefore, well-designed Gigabit Ethernet NICs offload
such tasks from the host processor, performing them in the NIC
hardware. These Gigabit Ethernet NICs also consolidate interrupts,
interrupting the CPU less frequently and for multiple tasks each
time. This reduces the number of times the processor has to save
context to service interrupts, and results in lower CPU utilization
for better application performance.
====================
the following from:
http://www.dec.com/info/DTJS05/
http://www.digital.com/info/DTJS05/DTJS05SC.TXT
A traditional system follows the networking subsystem model
implemented within the BSD releases of UNIX, shown in Figure 2. An
application uses the CPU to create data (1), the socket portion of the
system call interface copies the data into operating system buffers (2
and 3), the network transport protocol checksums the data for error
detection purposes (4), and the device driver uses programmed
input/output (I/O) or direct memory access (DMA) to move the data to
the network (5). Graphs showing the dominant costs of checksumming and
kernel buffer copies are presented in Reference 6.
===================
misc. references from around the net on HSP issues:
http://www-tkn.ee.tu-berlin.de/html/lehre/bla/tcp_hs.html
http://web.archive.org/web/20010126145400/http://www-tkn.ee.tu-berlin.de/html/lehre/bla/tcp_hs.html
http://www.cis.ohio-state.edu/~jain/cis788-95/transport/index.html
http://web.archive.org/web/20031003055250/http://www.cis.ohio-state.edu/~jain/cis788-95/transport/index.html
http://www.cs.umd.edu/~pravin/presentations/splice-talk/Splice-Talkl17.htm
ttp://web.archive.org/web/20041118002130/www.winlab.rutgers.edu/~pravin/presentations/splice-talk/Splice-Talkl17.htm
http://www.ca.sandia.gov/xtp/xtpintro.html
http://web.archive.org/web/20040404113457/http://www.ca.sandia.gov/xtp/xtpintro.html
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: ascii to binary Newsgroups: sci.crypt Date: Tue, 07 Mar 2000 06:01:07 GMTJohn Wingate writes:
709/709x/1401/etc binary could have all 12x80 holes punched & used BCD for character codes. with 360s & ebcdic (a superset of bcd) ... allowed for 256 codes (8bit bytes, four? holes per column was the most used & would generate hardware errors for columns with invalid hole combinations, my green card is in storage).
360s could interface to card reader/punch using something called column binary for processing 709/709x/1401/etc binary cards using 160bytes ... effectively each column had pairs of 6bit codes mapped to pairs of 360 (8bit) bytes
table that use to give punch codes:
http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/DZ9AR004/I%2e0
random reference:
http://users.ticnet.com/davea/greencard/start.htm
http://web.archive.org/web/20000302235907/http://users.ticnet.com/davea/greencard/start.htm
http://www.cwi.nl/people/dik/english/codes/80col.html
http://web.archive.org/web/20051228151320/homepages.cwi.nl/~dik/english/codes/80col.html
http://tronweb.super-nova.co.jp/characcodehist.html
http://www.fourmilab.ch/documents/univac/fieldata.html
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: ascii to binary Newsgroups: sci.crypt,alt.folklore.computers Date: Tue, 07 Mar 2000 06:53:35 GMT... oops, a little too quick on the send.
url with complete bcd & ebcdic card codes (26key punch, 29key punch)
http://www.cs.uiowa.edu/~jones/cards/codes.html
it also has proprietary 026 varients by control data, dec, GE, & univac
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "Mainframe" Usage Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Tue, 07 Mar 2000 15:53:01 GMTFloyd Davidson writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "Mainframe" Usage Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Tue, 07 Mar 2000 16:02:51 GMTdon@news.daedalus.co.nz (Don Stokes) writes:
basically asserting that the extra memory was reasonable trade-off given the problem of changing installed TCP implementations to support trailer checksums.
however, the discussion started out as to what issues was HSP trying to address. HSP wouldn't have the trade-offs of implementations already in the field. The issue for HSP was did the aggregate benefit from HSP justify the new protocol.
some HSP issues
more efficient checksum processing better congestion control & pacing possibly zero data copies, pipelining from transport interface directly into protocol engine easier use of larger MTUs 3 packet minimum exchange (compared to TCP 7 packet minimum exchange, improved latency reliable multicast more efficient error handling
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "Mainframe" Usage Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Tue, 07 Mar 2000 20:38:51 GMTFloyd Davidson writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "Mainframe" Usage Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Tue, 07 Mar 2000 21:07:13 GMTdon@news.daedalus.co.nz (Don Stokes) writes:
we had run into similar problem using any sort of windowing based infrastructure in high-speed real-world bursty environment in the mid-80s and had gone to rate-based pacing (not only needing to react to changes in congestion but also that ACKs can clump on the return and all of a sudden you have all of your buffers wide open).
while long-lived HTTP gives some better prediction of pending activity ... it is also prone to non-stable slow start.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Fairshare scheduling Newsgroups: comp.programming,comp.programming.threads Date: Sat, 11 Mar 2000 20:10:54 GMTJustin Liew writes:
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Proletarians of the World Wide Web, unite against ICANN! Newsgroups: alt.culture.internet,alt.folklore.computers,alt.internet.media-coverage Date: Fri, 17 Mar 2000 04:15:53 GMTjmfbahciv writes:
random URL
http://www.garlic.com/~lynn/internet.htm
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Will Radius be obsolute if implement 2-token authentications? Newsgroups: comp.security.firewalls Date: Fri, 17 Mar 2000 16:32:41 GMT"Jin Rid" writes:
random refs:
http://www.garlic.com/~lynn/99.html#217
http://www.garlic.com/~lynn/99.html#224
http://www.garlic.com/~lynn/aadsm2.htm#straw
http://lists.commerce.net/archives/ansi-epay/199912/msg00008.html
http://web.archive.org/web/20020607133811/http://lists.commerce.net/archives/ansi-epay/199912/msg00008.html
there have also been demos of webserver upgrades to utilize radius protocol in a similar manner (in place of ROI userid/password for web site authentication).
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: How many Megaflops and when? Newsgroups: alt.folklore.computers Date: Fri, 17 Mar 2000 19:25:25 GMTcronology of machines ... 6600 63/08 ann, 64/09 first customer ship
some references to 360/91 (1967)
http://emess.mscd.edu/~csi3060/Tomasulo/tsld002.htm
http://web.archive.org/web/20060114145609/http://emess.mscd.edu/~csi3060/Tomasulo/tsld002.htm
http://www.cs.herts.ac.uk/~comrrdp/pipeline/p_4_4.html
http://web.archive.org/web/20030406215205/homepages.feis.herts.ac.uk/~comrrdp/pipeline/p_4_4.html
parallel computing reference
http://ei.cs.vt.edu/~history/Parallel.html
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: How many Megaflops and when? Newsgroups: alt.folklore.computers Date: Sun, 19 Mar 2000 07:31:14 GMTdpeschel@sumatra.cs.washington.edu (Derek Peschel) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: ooh, a real flamewar :) Newsgroups: alt.folklore.computers,comp.unix.advocacy Date: Sun, 19 Mar 2000 17:27:15 GMTi asserted starting back around '89 that a large portion of the exploits were symptomatic of C convention of null terminated implicit lengths ... contributing to large number of buffer overrun scenerios (which continues today).
I also believe that somewhere in the early '90s there was report &/or press release from the austin tandem labs about contributing changes back to the system V base a set of changes that were specifically reliability oriented (including hundreds ... if not thousands of panics removed from the kernel, etc).
misc. refs
http://www.garlic.com/~lynn/99.html#30
http://www.garlic.com/~lynn/99.html#85
http://www.garlic.com/~lynn/99.html#163
http://www.garlic.com/~lynn/99.html#219
http://www.garlic.com/~lynn/2000.html#25
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: ooh, a real flamewar :) Newsgroups: alt.folklore.computers,comp.unix.advocacy Date: Sun, 19 Mar 2000 18:32:04 GMTidentifying and removing panics isn't necessarily trivially straight forward
some of the panics are things like hard disk errors ... so to pull the panic wasn't just a matter of removing the panic ... but replacing it with some detailed error recovery logic
other panics may be recognizable memory pointer problems ... which if system were left running might result in propagating the error into things like file system corruption &/or other integrity problems.
frequently the error & failure recovery logic ... can be four times as much code as the base non-recovery code.
random refs (including pieces of 'mainframe & unix' thread from '96 &
"OSes commercial, history" thread from 97 ... both in comp.arch)
http://www.garlic.com/~lynn/93.html#28
http://www.garlic.com/~lynn/94.html#00
http://www.garlic.com/~lynn/94.html#16
http://www.garlic.com/~lynn/94.html#33a
http://www.garlic.com/~lynn/94.html#44
http://www.garlic.com/~lynn/95.html#1
http://www.garlic.com/~lynn/96.html#18
http://www.garlic.com/~lynn/96.html#27
http://www.garlic.com/~lynn/96.html#28
http://www.garlic.com/~lynn/96.html#31
http://www.garlic.com/~lynn/96.html#32
http://www.garlic.com/~lynn/96.html#33
http://www.garlic.com/~lynn/96.html#41
http://www.garlic.com/~lynn/97.html#11
http://www.garlic.com/~lynn/97.html#12
http://www.garlic.com/~lynn/97.html#13
http://www.garlic.com/~lynn/97.html#14
http://www.garlic.com/~lynn/97.html#15
http://www.garlic.com/~lynn/99.html#16
http://www.garlic.com/~lynn/99.html#17
http://www.garlic.com/~lynn/99.html#31
http://www.garlic.com/~lynn/99.html#47
http://www.garlic.com/~lynn/99.html#49
http://www.garlic.com/~lynn/99.html#53
http://www.garlic.com/~lynn/99.html#71
http://www.garlic.com/~lynn/2000.html#21
http://www.garlic.com/~lynn/2000.html#22
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Tysons Corner, Virginia Newsgroups: alt.folklore.computers Date: Sun, 19 Mar 2000 19:48:29 GMTmy wife did tour thru SBS late 70s and came back when it was turned over to MCI. Building was (essentially) across the back parking lot of the best western (which faces on turnpike/7). MCI unloaded the bldg. and now occupied by BAH ... which built a matching bldg slightly downhill and put in a lobby/auditorium between the two.
had an array of dishes on top of the bldg. for quite some time.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: How many Megaflops and when? Newsgroups: alt.folklore.computers Date: Sun, 19 Mar 2000 20:09:06 GMT"Gerard S." writes:
there was a human response paper on response time & people's perception. Study of large body of people showed a distribution of what people could perceive ... between about .25 seconds and .10 seconds i.e. what threshold could they not decern different in response times ... for some the threshold was .25 seconds (they didn't notice the difference between .25seconds and .24 seconds). For some the threshold was as low as .10 seconds (i.e. would notice the difference between .11 seconds and .10 seconds).
Another study indicated that unexpected delays in response had a downside doubling of impact on productivity. If person was expecting a one second response ... and it was actually 2 seconds ... the person's attention would effectively start wandering and there would be a delay in the person refocusing their attention (delay approximately proportional between the difference between the actual response and the expected response). An unexpected 1 second delay in response actually resulted in a 2 second impact on productivity.
random refs:
http://www.garlic.com/~lynn/93.html#0
http://www.garlic.com/~lynn/93.html#31
http://www.garlic.com/~lynn/98.html#46
in the above "Big I/O or Kicking the Mainframe out the Door" response was for 90th percentile and for large mix-mode workload .. users doing complex combination of trivial interactive as well as compile, test, and various batch work.
in the following (acp/tpf related):
http://www.garlic.com/~lynn/2000.html#61
infrastructure had >100,000 terminals & displays w/nominal workload generating 3500-4000 I/O interrupts/second (120,000/min)
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: How many Megaflops and when? Newsgroups: alt.folklore.computers Date: Sun, 19 Mar 2000 20:17:01 GMTAnne & Lynn Wheeler writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: ooh, a real flamewar :) Newsgroups: alt.sys.pdp8,alt.sys.pdp10,alt.folklore.computers Date: Sun, 19 Mar 2000 20:32:56 GMT"Carl R. Friend" writes:
... from some quote ... in theory there is no difference between theory and practice ... but in practice there is.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Tysons Corner, Virginia Newsgroups: alt.folklore.computers Date: Sun, 19 Mar 2000 22:37:47 GMTPaul 125 writes:
BAH ... Booz, Allen, Hamilton
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: How many Megaflops and when? Newsgroups: alt.folklore.computers Date: Sun, 19 Mar 2000 22:44:23 GMTAnne & Lynn Wheeler writes:
there was some discussion recently that it may have been the original marriott and on the site of what had been a marriott hot shop.
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: How many Megaflops and when? Newsgroups: alt.folklore.computers Date: Mon, 20 Mar 2000 02:47:13 GMTjvarela@nospam.com (John Varela) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: S-P-F (was Mainframe operating systems) Newsgroups: bit.listserv.ibm-main Date: Mon, 20 Mar 2000 03:23:53 GMTAllan Beatty writes:
slightly related:
http://www.garlic.com/~lynn/2000b.html#20
http://www.garlic.com/~lynn/2000b.html#24
http://www.garlic.com/~lynn/2000b.html#25
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Tysons Corner, Virginia Newsgroups: alt.folklore.computers Date: Tue, 21 Mar 2000 13:48:01 GMTwe had transponders on SBS4 for research activities with privision we could get pre-empted for things like special TV coverage. we got hit for things like the pope's visit to denver (circa '86?, 87?) ... and were out for 3 days on that one. Did get invited to the VIP stands for SBS4's launch.
was part of the backbone we operated ... with clear-channel T1s and some fiber links.
random references:
http://www.garlic.com/~lynn/internet.htm
http://www.garlic.com/~lynn/94.html#33b
and link haven't check recently
http://www.ksc.nasa.gov/shuttle/missions/41-d/mission-41-d.html
http://web.archive.org/web/20040205142514/science.ksc.nasa.gov/shuttle/missions/41-d/mission-41-d.html
now:
http://www.nasa.gov/mission_pages/shuttle/shuttlemissions/archives/sts-41D.html
SBS also had the data aggregator (or aggravator some called trying to get it debugged) ... DES encrypted satellite T3 TDMA channel (i.e. 20 or so TDMA earth stations sharing/multiplexing both uplink and downlink ... real bear .. since different stations injected packets into the uplink packet flow ... and different stations were targeted for the downlink dataflow.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Win32 Memory consumption. Newsgroups: netscape.public.mozilla.general Date: Sat, 25 Mar 2000 18:00:27 GMTon nt4 running netscape 7.2 and then click on 12 different URLs opening them all in different windows ... and it adds about 4mbytes to my memory consumption.
running mozilla 14 and then click on the same 12 URLs opening them all in different windows ... and it adds about 28mbytes to my memory consumption.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 20th March 2000 Newsgroups: comp.lang.rexx,alt.folklore.computers Date: Sun, 26 Mar 2000 02:28:05 GMTMike Cowlishaw writes:
not quite 21 ... but >20 years; earliest reference that I stumble across.
Tuesday, February 26, 1980:
9:00 - W.W. Eggleston - VM/370 ITE Kickoff, Mr. Eggleston is the
President of GPD.
9:30 - Ray Holland - ITE Overview.
9:45 - Forrest Garnett - Dynamic Writable Shared Segment Overview.
10:00 - Jim Gray - System R , An Overview.
10:30 - Break
11:00 - Gene Svenson - Extended Networking.
11:30 - Roy Engehausen - Network management and load balancing tools.
12:00 - Lunch
1:00 - Peter Rocker - Network Response monitoning, Remote Dial
Support, and VM/370 HyperChannel attachment
1:20 - Jeff Barber - CADCOM - Series/1 to VM/370 inter-program
communications.
1:35 - Noah Mendelson - PVM - Pass Through Virtual Machine Facility.
2:00 - Noah Mendelson - EDX on Series/1 as a VNET work station.
2:15 - Tom Heald - Clock - Timer Driven CMS Virtual Machine.
2:30 - Break
3:00 - Vern Skinner - 3540 Diskett Read/Write Support in CMS.
3:30 - Bobby Lie - VM/SP - System Product offering overview
and discussion.
4:30 - Closing - From this point on there can be small
informal sessions of points of interest.
Wednesday, February 27, 1980:
9:00 - Billie Smith - Common System Plans.
modifications and results.
9:30 - Claude Hans - XEDIT Update.
Nagib Badre
10:00 - Graham Pursey - SNATAM - Controlling SNA devices from CMS.
10:30 - Break
11:00 - Mike Cowlishaw - REX Executor.
11:45 - Mark Brown - San Jose File Back-up System.
12:00 - Lunch
1:00 - Albert Hafner - VMBARS - VM/370 Backup and Retrieval System.
1:45 - Chris Bishoff - 6670 Office System Printer and VM/370
Tom Hutton
2:15 - Break
2:45 - Rodger Bailey - VM/370 Based Publication System.
3:15 - Dieter Paris - Photo-composition Support in DCF
3:30 - John Howard - VM Emulator Extensions.
Dave Fritz
3:40 - Tom Nilson - DPPG Interavtive Strategy and VM/CMS.
4:30 - Closing - From this point on there can be small
informal sessions of points of interest.
4:30 - Editor Authors - This will be an informal exchange of
information on the changes comming and
any input from users on edit concepts.
All those wishing to express their opinions
should attend.
Thursday, February 28, 1980:
9:00 - Ed Hahn - VM/370 Mulit-Drop Support
9:30 - Ann Jones - Individual Password System for VM/370.
10:00 - Walt Daniels - Individual Computing based on EM/YMS.
10:30 - Break
11:00 - Chris Stephenson - EM/370 - Extended Machine 370 and EM/YMS
Extended Machine Yorktown Monitor System.
12:00 - Lunch
1:00 - Simon Nash - Extended CMS Performance Monitoring Facility
1:30 - George McQuilken - Distributed Processing Maching Controls.
2:00 - Mike Cassily - Planned Security Extensions to VM/370 at
the Cambridge Scientific Center
2:30 - Break
3:00 - Steve Pittman - Intra Virtual Machine Synchronization
Enqueue/Dequeue Mechanisms.
3:30 - Jeff Hill - Boulder F.E. Source Library Control System.
4:00 - Ray Holland - VMITE Closing.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 20th March 2000 Newsgroups: comp.lang.rexx,alt.folklore.computers Date: Mon, 27 Mar 2000 01:29:34 GMTJohn Ferrell writes:
I never made any statement about mike's dates being incorrect (&/or intended that such a thing would be implied)
I just posted the earliest reference I could find on rex/rexx.
There is implication that since the reference was a talk about rex/rexx that rex/rexx should have predated the talk (i.e. it was in existance before the date of the talk)
If you have a early rex/rexx reference maybe you would care to share it?
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 20th March 2000 Newsgroups: comp.lang.rexx,alt.folklore.computers Date: Mon, 27 Mar 2000 01:31:39 GMTi.e. reference to "not quite 21" had nothing at all to do with Mike's comment about the age of rex/rexx ... it had to do with the antiquity of the reference that I stumbled across.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 20th March 2000 Newsgroups: comp.lang.rexx,alt.folklore.computers Date: Mon, 27 Mar 2000 16:04:56 GMTanother early rex reference:
Newsgroups: alt.folklore.computers
From: lynn@netcom11.netcom.com (Lynn Wheeler)
Subject: REXX
Date: Sun, 27 Mar 1994 01:28:25 GMT
This is a REXX story from the early '80s.
In 1982 REXX was still in its early incarnations and there were
efforts to get it released to the world as a product. Some of the
nay-sayers were claiming that it was just another batch command
language ... which the world already had plenty. Being part of the
true-believers I wanted to do a demonstration that showed that it was
significantly more than another batch command language.
I selected as a demonstration a replacement of a VM product component
that was currently implemented in 370 assembler. The existing product
was called DUMPSCAN and it contained >20k lines of assembler code and
was used to view CP and CMS postmortem storage image dumps (and had a
full-time department of 5-10 people supporting it).
My demonstration was that in 3 months elapsed, working half-time, I
would create a REXX replacement for DUMPSCAN that had 5 the function
and ran 5 faster (REXX is an interpreted language). The initial part
of the demonstration was completed in a little over 2 months ... it
had a very small assembler stub module (couple hundred lines of code)
that provided some low-level primitive functions for "DUMPRX". The
actual replacement was 2200 lines of REXX code that implemented a
large superset of the DUMPSCAN function and would operate 5 faster
(with a side-effect for those familiar with the OCO issue was that
effectively nearly all source code had to be shipped). Some of the
enhancements:
"opcodes" formated storage display
display storage as addresses with respect to
kernel symbol table.
some simple psuedo-assembler code written in REXX could
process source include files and perform "source" formated
display of storage locations
handle not only postmortem storage dumps but also work
against live cp & cms kernel
parse the GML source file for messages&codes manual and
display information of interest.
save/log complete session
sophisticated high-level "help"
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 20th March 2000 Newsgroups: comp.lang.rexx,alt.folklore.computers Date: Thu, 30 Mar 2000 05:36:41 GMTAnne & Lynn Wheeler writes:
"In early spring of 1981, the first release of DUMPRX was made available and also some of the ideas and aspects of the technology were discussed at a SHARE BOF."
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Those who do not learn from history... Newsgroups: alt.folklore.computers Date: Thu, 30 Mar 2000 08:29:49 GMTkfl@saltmine.radix.net (Keith F. Lynch) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: VMS vs. Unix (was: Why are Suns so slow?) Newsgroups: comp.sys.intel,comp.arch,alt.folklore.computers Date: Thu, 30 Mar 2000 16:15:27 GMT"Mike Yankus" writes
The size of the mainframe dumb terminal "upgrade" market (coupled with the rest of the PC business market) made it possible to get the volumes that could drive down the manufacturing costs and make it interesting for clones to enter the market. From that point there was positive feedback with further cost competition opening new market segments as well as attracting both new manufactures as well as software developers. This eventually spilled into the consumer and home market.
misc. ref:
http://www.garlic.com/~lynn/2000.html#6
http://www.garlic.com/~lynn/99.html#28
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: How to learn assembler language for OS/390 ? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Thu, 30 Mar 2000 16:42:55 GMTEd.Long@FMR.COM (Long, Ed) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: How to learn assembler language for OS/390 ? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Thu, 30 Mar 2000 20:13:51 GMTglass2 writes:
the high end machines were water cooled (or at least had heat exhange unit with water on the outboard side). Later machines used TCMs (thermal conduction modules) to improve heat transfer. They were solid blocks inclosing the components and holes drilled thru the blocks with connectors to flow fluid thru the blocks.
random refs:
http://www-mae.engr.ucf.edu/~jtt/heat_transfer.htm
http://web.archive.org/web/20020609182101/http://www-mae.engr.ucf.edu/~jtt/heat_transfer.htm
http://domino.int-evry.fr/IntranetDSI/EuroFret/ibm3090.htm
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: How to learn assembler language for OS/390 ? Newsgroups: bit.listserv.ibm-main,alt.folklore.computers Date: Thu, 30 Mar 2000 19:53:23 GMTpossibly cornell university ... (the requirement for flow sensor on the out-board side of the heat exchanger may have shown up in some earlier scenerios)
another TCM story was that target on the 3081 (or 3090?) was going to be (I believe) six TCMs but it was beginning to look like they would have to add an extra one for addition channel I/O processing.
the problem was the 3880 control unit ... while the 3880 introduced data streaming and 3mbyte/sec channel capacity (i.e. instead of channel/controller handshake on every byte transferred it could transfer 8bytes per handshake ... also allowed doubling the length on the bus&tag cables).
The problem is that 3830->3880 went from a fast horizontal mcode processor to relatively slow vertical mcode jib-prime processor ... with data-path bypass (i.e. control ops went thru jib-prime but data & control data paths were done separate). The problem was that the 3880 control processing significantly increased the "channel busy" time associated with control operations ... enuf so that it would significantly degrade the aggregate data transfer thruput into & out of the processor complex (compared to 3830 controller, even with the change from 3330 disk drives to 3830 3mbyte/sec disk drives).
to maintain aggregate processing thruput required increasing channels which translated into increase in the number of TCMs ... which were the major expense factor in the processor complex.
we had seen something analogous earlier in several complexes where we remoted all the "channel-attached" displays behind HYPERChannel channel extenders. In much of the '70s had display controllers intermixed on same channels with disk controllers. The display controllers also had expensive channel busy control operations ... that implied blocking/delaying disk control access. The internal HYPERChannel project remoted all the display controllers using local HYPERChannel (A220) controllers on the processor channels and remote HYPERChannel (A51x) 370 channel simulators. The A220/A51x processing was asynchronous allowing local A220 to burst the direct mainframe channel activity. Just remoting the display controllers (significantly reducing local channel busy & disk controller interference) resulted in 10-15% overall aggregate system thruput.
random refs:
http://www.garlic.com/~lynn/94.html#23
http://www.garlic.com/~lynn/94.html#24
http://www.garlic.com/~lynn/96.html#18
http://www.garlic.com/~lynn/96.html#19
http://www.garlic.com/~lynn/2000.html#16
http://www.garlic.com/~lynn/96.html#27
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why are Suns so slow? Newsgroups: comp.sys.intel,comp.arch,comp.sys.sun.misc Date: Thu, 30 Mar 2000 21:09:15 GMTwbe @[ubeblock ]psr.com (Winston Edmond) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: general questions on SSL certificates Newsgroups: sci.crypt Date: Fri, 31 Mar 2000 21:00:27 GMTkilgallen@eisner.decus.org (Larry Kilgallen) writes:
The consumer encrypts the credit card number under the payment gateway key ... and sends it to the merchant .. who forwards it to the payment gateway. For a valid merchant/transaction, the payment gateway echos the number back to the merchant in the transaction response (where it goes into the merchant database of credit card numbers).
Also, SET is sensitive to the privacy issues ... not identifying the certificate owner ... just carrying the bare minimum for having some account. This somewhat falls into the category of relying-party-only certificates ... because of both liability & privacy issues.
random other references at
http://www.garlic.com/~lynn/
http://www.garlic.com/~lynn/ansiepay.htm#theory
http://www.garlic.com/~lynn/aepay3.htm#sslset1
http://www.garlic.com/~lynn/aepay3.htm#sslset2
http://www.garlic.com/~lynn/aepay2.htm#aadspriv
http://www.garlic.com/~lynn/aepay2.htm#privrules
http://www.garlic.com/~lynn/aadsmail.htm#comfort
http://www.garlic.com/~lynn/ansiepay.htm#privacy
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: How to learn assembler language for OS/390 ? Newsgroups: bit.listserv.ibm-main Date: Fri, 31 Mar 2000 22:28:58 GMTI used 2321 as undergraduate ... we had ONR grant at the university library and had 2321 data cell and was one of the original CICS beta-test sites. Had problems in both 2321 and CICS.
never worked on the 2321 later ... but worked with some of the engineers that had been responsible for the 2321.
random references:
http://www.garlic.com/~lynn/2000.html#9
http://www.garlic.com/~lynn/94.html#33
http://www.garlic.com/~lynn/96.html#9
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why are Suns so slow? Newsgroups: comp.sys.intel,comp.arch,comp.sys.sun.misc Date: Sat, 01 Apr 2000 03:55:03 GMTDONT.qed.SPAM.ME@pobox.com (Paul Hsieh) writes:
you could get a terminal emulator where you set/tune things like key repeat delay and key repeat rate ... as well as not lock the keyboard if you happen to be typing at the moment the mainframe decided to write to your screen.
random references:
http://www.garlic.com/~lynn/2000b.html#35
http://www.garlic.com/~lynn/99.html#222
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Migrating pages from a paging device (was Re: removal of paging device) Newsgroups: bit.listserv.vmesa-l Date: Fri, 31 Mar 2000 23:41:54 -08001) in late '70s did SYSPAG changes against vm/370 & vm/hpo bases
SYSPAG separated the structure for allocation and deallocation. allocation structure could be multiple portions of device.
page migration then supported specific (whole) device or specific allocation areas on a specific device ... which would scan all tables looking for pages resident on that specific area/device.
it was also possible to remove areas from the allocation control structure to achieve cleaning. The allocation blocks were removed before starting the migration .. with specific allocation areas removed from the allocation structure .. migration would clean off all pages for the specific area(s) ... and no new pages would get reallocated during the process. At the end of the clean/migration process there would be no pages left in the area.
It was then possible to vary off the device.
2) redid the spool file system (SFS) in the early 80s.
spool file infrastructure was modified so that each disk was effectively an independent spool file system. a specific spool file tended to be allocated on a single drive ... although it was possible to "concatenate" spool file segments that crossed volumes. spool file recovery information was unique to each disk.
at CP startup, each spool disk would be mounted separately and its spool file system integrated into the CP infrastructure. It was possible to remove drive from spool file allocation ... although still allow access to files on the disk. It was possible to more/migrate files off a spool file disk. It was possible to vary off a spool file drive whether it contained files or not. Files on a varied off device were just not available.
Spool drive with intact spool files could be varied back on and merged back into the production running system at any time.
A lot of the administrative function for SFS was rewritten in Pascal and moved to a virtual machine. One objective was for SFS to be significantly faster than the existing 370/HPO spool file system (even when kernel had to make upcalls to functions running in virtual address space). Critical to SFS having better performance was that 370&HPO managed the spool file infrastructure with link list structure ... doing linear scans for adding & deleting. This was enormously expensive for reasonably sized system. SFS implemented some things with hash table and other stuff with red/green trees. That performance improvement more than offset degradation associated with moving function out of the kernel into virtual address space.
There was also SFS pascal code support for running on unmodied CP system using the full block spool file interface (used by RSCS) to pull files out of existing spool system. These could be written to tape (similar to spool file to tape) or copy to volume in the new structure. It could also read standard spool file tapes and write to volume in the new structure.
SFS also implemented thruput enhancements for HSDT (high speed data transport). Standard RSCS interface processing 4k spool file block was synchronous .. which resulted in RSCS being blocked (non-runnable) while the 4k spool file block was read or written. WIth spool file checkpointing, lots of small files, and any device contention (for instance other apps doing any spool file activity) ... RSCS thruput could be as low as 20kbytes/sec (and difficult to get any better than 100kbytes/sec in most configurations).
HSDT had multiple full duplex T1 links; 1.5mbits/sec simplex ... about 150kbytes/sec; 300kbytes/sec full duplex per link, 3-4 links needed 1.2mbytes/sec sustained aggregate thruput. SFS provided a asynchronous interface for RSCS and did the spool file logging (checkpoint) completely different to remove it as a bottleneck also.
random URLs:
http://www.garlic.com/~lynn/94.html#22
http://www.garlic.com/~lynn/94.html#29
http://www.garlic.com/~lynn/94.html#31
http://www.garlic.com/~lynn/94.html#33a
http://www.garlic.com/~lynn/94.html#33b
http://www.garlic.com/~lynn/96.html#38
http://www.garlic.com/~lynn/98.html#49
http://www.garlic.com/~lynn/98.html#50
http://www.garlic.com/~lynn/99.html#34
http://www.garlic.com/~lynn/99.html#36
http://www.garlic.com/~lynn/99.html#201
http://www.garlic.com/~lynn/99.html#222
--
Anne & Lynn Wheeler lynn@adcomsys.net, lynn@garlic.com
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 20th March 2000 Newsgroups: alt.folklore.computers Date: Mon, 03 Apr 2000 16:45:31 GMT-- ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
misc. references.
http://www.garlic.com/~lynn/93.html#17
Anne & Lynn Wheeler | lynn@garlic.com http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: OSA-Express Gigabit Ethernet card planning Newsgroups: bit.listserv.ibm-main Date: Mon, 03 Apr 2000 23:02:36 GMTjon.evans@POSTOFFICE.CO.UK (Jon Evans) writes:
The problem was in the ARP implementation in 4.3 on the clients. Normally, ARP is suppose to "age" out the ip->MAC (aka enet or t/r) address and reload the cache with current value. However, the 4.3 code had a performance speedup in the IP code (just before checking the ARP cache) ... if the the current packet has a to-ip-address that is the same as the previous packet ... it had saved the value and bypassed calling ARP. The problem was in client/server or client/router configurations where the client tended to only communicate with the same IP-address for long periods of time. As a result, the "hip-pocket" MAC address would never change ... and wasn't subject to the ARP cache time-out rules (i.e. wasn't a problem with server ip-takeover ... but a bug in all the clients).
We would see instances where we had done the ip-address takeover at the server and 30 minutes later still had clients trying to communicate to the old MAC address. Workaround was to send all discovered clients a PING from a different IP-address. To respond, the clients would have send a packet to the different IP-address ... & would have to actually call ARP ... which would change the hip-pocket ip/MAC address. Then when the client attempted to communicate with the server again ... the ip-address in the hip-pocket had changed so ARP would have to be called ... and the current MAC address would be used.
misc. refs.
http://www.garlic.com/~lynn/96.html#15
http://www.garlic.com/~lynn/96.html#34
http://www.garlic.com/~lynn/99.html#54
http://www.garlic.com/~lynn/99.html#71
http://www.garlic.com/~lynn/99.html#164
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Simple authentication protocol: any good? Newsgroups: sci.crypt Date: Tue, 04 Apr 2000 00:27:23 GMTdaha@best.com (David S. Harrison) writes:
basically uses similar AADS infrastructure proposed for X9.59 financial transactions. Challenge for X9.59 was lightweight protocol for all electronic retail payments (credit, debit, e-check, prepaid, etc) that preserves the integrity of the financial infrastructure with only a digital signature. Assumptions were transaction could flow over an untrusted network and everything was subject to evesdropping ... including the account number.
misc. refs.
http://www.garlic.com/~lynn/aadsm2.htm#inetpki
http://www.garlic.com/~lynn/aadsm2.htm#account
http://www.garlic.com/~lynn/aadsm2.htm#straw
http://www.garlic.com/~lynn/aadsm2.htm#keylength
http://www.garlic.com/~lynn/aadsm2.htm#pkikrb
http://www.garlic.com/~lynn/aadsm3.htm#kiss3
http://www.garlic.com/~lynn/aadsmore.htm#hcrl2
http://www.garlic.com/~lynn/99.html#230
http://www.garlic.com/~lynn/2000b.html#14
http://www.garlic.com/~lynn/8583flow.htm
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Why are Suns so slow? Newsgroups: comp.sys.intel,comp.arch,comp.sys.sun.misc Date: Tue, 04 Apr 2000 16:35:23 GMTthe emerging workstation market had significant better price/performance for hardware that was becoming almost commodity priced parts. the cost profile of doing unix fit the startup/companies doing these sort of hardware products (they could hardly spend more on proprietary operating system development than they were spending on hardware devleopment).
misc refs:
http://www.garlic.com/~lynn/99.html#222
http://vm.marist.edu/~piper/party/jph-12.html#wheeler
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: How to implement doubly link list with only one pointer ? Newsgroups: comp.programming,comp.theory Date: Sun, 09 Apr 2000 16:18:37 GMTAriel Scolnicov writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: VM (not VMS or Virtual Machine, the IBM sort) Newsgroups: alt.folklore.computers Date: Mon, 17 Apr 2000 16:02:31 GMT"Gerard S." writes:
and as indicated also worked on a project that took some interdata hardware (early precursor to box used for one of the non-DEC ports of UNIX) and simulated an ibm mainframe controller (supposedly credited with originating the ibm plug-compatible market).
They were line/print (tty33 & 35) ascii terminals at 110buad ... but not too long afterwards 300 baud line terminals with heat sensitive paper & then screens (like adm3a) that simulated line terminals ... but you could play games with cursor re-positioning
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: VM (not VMS or Virtual Machine, the IBM sort) Newsgroups: alt.folklore.computers Date: Mon, 17 Apr 2000 19:46:34 GMT"Gerard S." writes:
I'm sure it has had numerous modifications & enhancements since then. The basic LPAR is effectively enhanced version of the origianl VM microcode assist or, if you will, the virtual machine SIE infrastructure with some additional configuration wrappers built around it thru service processor support.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: VM (not VMS or Virtual Machine, the IBM sort) Newsgroups: alt.folklore.computers Date: Mon, 17 Apr 2000 23:41:07 GMTjmaynard@thebrain.conmicro.cx (Jay Maynard) writes
The CP/VM kernel code had its own address space and needed to be able to simultaneous switch between priviledge & non-priviledge mode while at the same time switching between the kernel address space and the application address space.
SIE was introduced in XA architecture to support CP operation ... & while they where at it they threw in various VM performance assists i.e. effectively microcode for instructions that would follow the rules for how an instruction operated in virtual machine mode ... as opposed to how it might operate natively. For simulation of a virtual machine ... CP might follow slightly different rules when simulating a priviledge instruction ... effectively those virtual machine "rules" for instruction execution was dropped into the microcode of the machine.
For those things ... it was no longer necessary for CP to simulate a priviledge instruction according to virtual machine rules ... many of the instructions ... if they were in "SIE" mode ... would automatically perform the instruction according to virtual machine rules.
LPARS ... are logical partitions ... a physical processing complex can be partition into multiple "logical" (or virtual) machines. In some sense, a logical partition alwas operates in "SIE" mode ... following the rules for instruuction execution laid down for it. Rather than actually needing VM operating system to manage the machine ... the "microcode" (aka service processor) sets up the configuration operations governing LPAR operation.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: VM (not VMS or Virtual Machine, the IBM sort) Newsgroups: alt.folklore.computers Date: Wed, 19 Apr 2000 16:58:41 GMTjmaynard@thebrain.conmicro.cx (Jay Maynard) writes
The target of a LPSW instruction was an 8byte field that contained the new instruction address, the supervisor/problem mode bit, and the real/virtual address (DAT, or dynamic address translation) mode bit. To start execution of a virtual machine, a LPSW instruction was executed that had a target of a virtual instruction address in the virtual address space, the supervisor/problem mode bit set to problem mode, and the DAT mode bit turned on.
All hardware interrups occured by loading an 8byte PSW field from fixed location in real storage and storing the current PSW (current instruction address & state information) in a separate real storage location . The kernel code had initialized the "new PSW" fields to a real instruction address in the kernel, supervisor/problem mode bit set to supervisor and the DAT mode bit turned off.
Any attempt to execute a "supervisor" instruction while in problem mode would result in storing the current 8byte PSW in the "OLD PSW field" in fixed real storage along with the reason for the interrupt and loading a new PSW from fixed real storage.
CP's kernel was mapped to real storage and not included in the virtual address mapping of any virtual machine. It was possible for CP to switch to virtual machine mode by first loading the appropriate address space table in the address space control register and then executing a LPSW that switched: 1) instruction address, 2) problem mode, and 3) address translation mode. Any interrupt (supervisor, program, exception, page fault, I/O, machine, timer, external, etc) would switch back to 1) cp kernel instruction address, 2) supervisor mode, and 3) non-DAT mode.
370 introduced BC/EC mode (bit 12 ... former ascii/ebcdic bit in 360 mode). in 360/BC mode, the first 8 bits of the PSW were the channel interrupt mask (if the corresponding bit was one, the processor would take I/O interrupts from that channel). In EC/mode, the channel mask was moved to a 32bit control register and replaced with a single summary bit which would disabled all I/O interrupts (or enabled the control register mask).
Following (dated '85) reference contains more detailed description of
interrupts & PSW processing for CMS bc-mode operation (about half-way
down the document):
http://www.geocities.com/SiliconValley/2260/vmcom25.html
http://web.archive.org/web/19961224165411/http://www.geocities.com/SiliconValley/2260/vmcom25.html
SIE stands for "start interpretive execution"
following from:
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/HCSF8A02/3%2e1%2e1%2e2?SHELF=HCSH2A08
3.1.1.2 Interpretive-Execution Facility
One of the key differences between processors that support ESA/370
or ESA/390 architectures and System/370 processors is the
interpretive-execution facility. CP depends on the
interpretive-execution facility to process work for virtual
machines.
A virtual machine currently running under the control of the
interpretive-execution facility is said to be running in
interpretive-execution mode. When the virtual machine runs in
interpretive-execution mode, the interpretive-execution facility:
Handles most privileged and nonprivileged instructions.
Handles the virtual interval timer, the clock comparator, and the
processor timer.
Translates and applies prefixing to storage addresses. For
instance, the facility performs the double-page translation
required to page third-level storage into first-level storage.
Subtopics:
3.1.1.2.1 Assists Supported by the Interpretive-Execution Facility
a listing of CP performance facilities:
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/HCSI1A02/2%2e1%2e4?SHELF=HCSH2A08
The online VM bookshelf is at:
http://www.s390.ibm.com:80/os390/bkserv/vm/
it is possible to select "interpretive execution" text search for
VM/ESA V2 R3.0 bookshelf can be done at:
http://www.s390.ibm.com:80/os390/bkserv/vm/vm23_srch.html#text
which gets the following list:
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/Shelves/HCSH2A08?searchRequest=interpretive+execution&action=Search
and possibly more than anybody wanted to know about LPARs:
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/DA2A8003/CCONTENTS
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/DA2A8004/CCONTENTS
random other refs:
http://www.garlic.com/~lynn/98.html#35a
http://www.garlic.com/~lynn/99.html#71
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Digital Certificates-Healthcare Setting Newsgroups: alt.technology.smartcards Date: Fri, 21 Apr 2000 19:05:32 GMTDPeiser writes:
messages typically carry some unique value in order to preclude "replays" (i.e. either the server that plans on authenticating the message provides the unique value ... or it keeps around previous messages and rejects duplicate messages that it has already processed).
public key certificates have been used in infrastructures for communicating the public key to the authenticating server ... when the authenticating server has no prior (business) relationship with the signing party (patient) &/or when the authenticating server has no local storage for maintaining records of (business) relationships (or patients).
environments where there is an existing relationship and/or the authenticating server has records regarding the requesting party (patient) ... have been able to upgrade password &/or shared-secret infrastructures to record the patient's public key for authentication purposes (i.e. instead of recording a secret password, record the patient's public key and use that public key for authenticating digital signatures ... w/o requiring a public key certificate to be transmitted along with each request).
The analogy in call center/telephone authorized access to patient records involve asking the patient things that might be found in the patient record like mother's maiden name, social security number, patient number, address, birth date, etc.
Some issues with public key certificate infrastructure are who issued the certificate and can they be trusted ... and does the bound information in the certificate correspond to any identity information found in a patient record (i.e. a certificate may be perfectly valid ... but what indicates that a specific certificate in any way correlates to a specific patient). Also, if there is too much identity information carried in the certificate ... the identity information carried in the certificate may represent privacy problems.
On the other hand ... in minimizing privacy exposures with identity certificates, if the patient record institution issued the certificate (with only a patient number), then the patient record has already recorded the patient's public key ... which would be recorded in the patient's record. In that situation, requiring the patient to transmit a copy of the certificate back to the patient record institution (in order to communicate the public key) is redundant and superfluous since the patient record institution would have the public key already record (and in fact would have the original of the public key certificate ... i.e. redundant to send a copy of a public key certificate back to the institution that has the original of the public key certificate).
In any case, the problem with making sure a certificate is not left around (and any exposure involving privacy leakage) is solved by eliminating any requirement to ahve the certificate exist at all.
recent news article on privacy leakage with identity certificates
http://www.zdnet.com/zdnn/stories/news/0,4586,2523596,00.html
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Multics dual-page-size scheme Newsgroups: alt.os.multics Date: Fri, 21 Apr 2000 22:02:48 GMT"Iain McCracken" writes:
used segments and inverted tables. For 32bit addressing ... they limited things to fixed sized large segments; 16 256mbyte (top four bits of the virtual address).
Since there weren't any (segment) page tables ... tables were identified logically with an ID-number (managed by the supervisor) instead of a pointer to the (segment) page tables.
The original design trade-off had
1) early binding of trust at code build time and little or no run-time privilege/non-privilege in a "closed system". Effectively, in-line library code could swap segment pointer/values ... in much the same way generated code is allowed to load storage pointer values into address registers
2) small number of "concurrent" segments ... that could be mapped into efficient segment registers
3) inline code could compensate for the small number of concurrently addressable segments by being able to rapidly change segment register (id) values ... w/o having to go thru supervisor calls needed for authorization access checking (i.e. in much the same way that inline code can change values in address registers).
ROMP has been described as having 40-bit virtual addressing. It is actually 32-bit virtual address ... with the top four bits used to select a segment register. ROMP supported 12-bit segment IDs ... this translates into an aggregate total of 4096 segments for a running system and roughly corresponds to the total number of different (segment) page tables (in a page table hardware architecture ... as opposed to an inverted table architecture).
RIOS/6000/power increased the segment ID field from 12-bits to 24bits (and is sometimes described as having 52bit virtual addressing) ... again the 24bits corresponds to the total system aggregate number of page tables that could exist in a system (that used page tables ... rather than inverted tables).
So the 801/romp/power segments are different in two respects
1) need a segment "id" in an inverted table architecture instead of a page table pointer
2) small number of concurrent segments (16) mapped to hardware registers was a performance/complexity trade-off based on a design point that assumed a closed, proprietary operating system that performed early trust binding and didn't require runtime authorization checking to swap segment values (could be done using inline code as simply as changing values in address registers).
current power approach to supporting open operating system with supervisor calls & runtime authorization checking when changing segment values has been to create composite shared objects (i.e. cram multiple different feature/function/libraries into a single 256mbyte segment object). It overcomes both problem of having large number of different "shared" objects simultaneously and the overhead and (unix/application) complexity that would have been associated with frequent segment switches.
misc. refs:
http://www.garlic.com/~lynn/94.html#47
http://www.garlic.com/~lynn/95.html#5
http://www.garlic.com/~lynn/95.html#6
http://www.garlic.com/~lynn/95.html#11
http://www.garlic.com/~lynn/97.html#5
http://www.garlic.com/~lynn/98.html#25
http://www.garlic.com/~lynn/98.html#26
http://www.garlic.com/~lynn/98.html#27
In '60s, CP/67 (concurrent with Multics but on 4th floor 545 technology sq., running on ibm 360/67) didn't really make use of the 67 segment architecture ... although TSS/360 did. 360/67 had support for one meg segments, only sixteen per address space in 24 bit mode, but 4096 in 32 bit mode.
In early '70s, VM/370 did make use of segments when the ibm 370 came out (initially done 545 tech. sq ... but then moved out to the old SBC building in burlington mall). 370 had both 2k & 4k page options and 64k & 1meg segment options. VM/370 used 4k pages & 64k segments and implemented R/O shared segments for CMS.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Multics dual-page-size scheme Newsgroups: alt.os.multics Date: Sun, 23 Apr 2000 17:50:22 GMTAnne & Lynn Wheeler writes:
misc. refs:
http://www.garlic.com/~lynn/2000.html#18
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: South San Jose (was Tysons Corner, Virginia) Newsgroups: alt.folklore.computers Date: Sun, 23 Apr 2000 22:20:12 GMTanother off-topic
the IBM STL lab (santa teresa lab) and the smithsonian aerospace museum were suppose to open the same week.
normally IBM names their labs for the closest post office ... which in this particular case was coyote (95013) ... and that was what the lab was going to be named until ...
the week before was the kids school spring break so we had taken them to washington dc for the week (along with a lot of the rest of the nation). one of the disappointments was the aerospace museum wouldn't be open until the following week.
on the other hand, the San Francisco based Coyote (aka professional ladies) union was demonstrating that week on the steps of congress ... which appears to have led to a very quick renaming of the new IBM lab from Coyote lab to Santa Teresa lab (which happens to be the closest cross street).
doing zipcode maps at http://www.mapquest.com/
Coyote post office 95013
IBM STL lab 95141 (shown wrong side of bailey av)
south San Jose PO 95123 (actually SE corner blossom hill rd
& blossom av)
IBM San Jose plant site 95193 (actually NE corner of cottle rd & 85)
IBM Almaden Research 95120 (harry rd isn't even on the map shown
for 95120 ... it is about two miles
due east of mapquest's red star ...
or if you extend cottle rd in a straight
line, about 1m due south of cottle rd
& santa teresa intersection).
--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: South San Jose (was Tysons Corner, Virginia) Newsgroups: alt.folklore.computers Date: Sun, 23 Apr 2000 23:08:15 GMTanother facility in south san jose was called the ibm "los gatos lab" even though it was in south san jose at 6450 guadalupe mines rd. It was built in the '60s for ASD (advanced system division) and when built got some sort of architecture award. It sat on a couple hundred acres and one of its distinctive features was a special sawmill run of 5' wide redwood sheeting (over the years as inside was renovated &/or remodeled, they stockpiled the sheets since it wasn't likely they were going to get more). Many people considered it the most scenic IBM lab location (better than newer almaden research up on 55 harry road).
It was common to find a small herd of deer on the front lawn. The back patio had a foot high mesh fence built around it ... referred to as the (rattle) snake fence (which were relatively common in the spring). In the early '90s there was local TV coverage of incidences involving wild boar tearing up the lawn.
From the roof of bldg. 12 (on the san jose plant site) there were T3 collins digital radio microwave dishes going to repeater tower on hill above bldg. 29 (los gatos lab), repeater tower on hill above bldg. 90 (santa teresa lab), and directly to roofs of variouse off-site bldgs. (west of the main plant site). When research moved out of bldg. 28 to the new facility on harry road ... (at least?) six fiber pairs were run from the plant site to the new research bldg.
the los gatos lab facility was sold off a couple years ago, torn down and turned into a housing development.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: South San Jose (was Tysons Corner, Virginia) Newsgroups: alt.folklore.computers Date: Mon, 24 Apr 2000 22:39:56 GMTjcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: 7 layers to a program Newsgroups: comp.programming Date: Tue, 25 Apr 2000 01:01:15 GMTkaz@ashi.footprints.net (Kaz Kylheku) writes:
IEEE80x/lan is physical, link, & much of the network layer (all collapsed together)
IP is the "internetworking" layer between network layer and the transport layer.
ARP is part of service definition for glue between the internetwork layer and the network layer (doing the translation between the internet ddress to the network address). In this respect, OSI pretty much envisioned point-to-point hardware links (link) layer and didn't provide for hardware abstraction that collapsed physical, link & network into single hardware interface.
there was some activity to do a high-speed protocol definition in ansi/iso that would have gone directly from transport interface to the lan interface ... which got "stomped" on by the OSI factions as not preserving exactly all of their OSI layered interfaces. They would have stomped out LAN violating OSI also ... if they could have.
misc. ref:
http://www.garlic.com/~lynn/2000b.html#4
http://www.garlic.com/~lynn/2000b.html#0
http://www.garlic.com/~lynn/2000b.html#1
http://www.garlic.com/~lynn/2000b.html#8
http://www.garlic.com/~lynn/2000b.html#10
http://www.garlic.com/~lynn/internet.htm
http://www.garlic.com/~lynn/subindex.html#network
http://www.garlic.com/~lynn/99.html#201
http://www.garlic.com/~lynn/99.html#202
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: South San Jose (was Tysons Corner, Virginia) Newsgroups: alt.folklore.computers Date: Tue, 25 Apr 2000 17:33:05 GMTseebs@plethora.net (Peter Seebach) writes:
He had also made up a spoof on the position of lab director (for the plant site) ... he had pencils made up "Elect .... Lab Director" with an election slogon "Raises or Promotions, but not both". It goes w/o saying that the position of lab director was not an elected position
I may even have some of the pencils somewhere in storage.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: VM (not VMS or Virtual Machine, the IBM sort) Newsgroups: alt.folklore.computers Date: Sat, 29 Apr 2000 02:20:03 GMTdpeschel@eskimo.com (Derek Peschel) writes:
Normally CP provides a virtual machine that is a replica of the real machine that CP is running on. However, there have been exceptions to that. Early in the development of 370 (which had additional supervisor state instructures and different virtual memory hardware implementation structure than 360/67) ... a copy of CP/67 was modified that provided 370 virtual machines (in place of 360 & 360/67 virtual machines).
This was at 545 tech sq ... and the operation there provided time-sharing services that included access by various MIT personel & students. To not expose & protect the unnounced 370 details ... this modified "CP-H" system was booted in a virtual 360/67 virtual machine (running under CP/67 ... running on the 360/67).
A further modification was then made to CP-H so that it would run on a real 370 machine (instead of 360/67 machine). This CP-I system was then booted in a 370 virtual machine provided by the CP-H system that had been booted in a 360/67 virtual machine provided by CP/67 running on a real 360/67.
Then "CMS" (conversational monitor system) was booted in a virtual machine provided by the CP-I system that had been booted in a 370 virtual machine provided by the CP-H system that had been booted in a 360/67 virtual machine provided ty by the CP/67 system that had been booted on the real 360/67.
This configuration was running and operational a year before the first engineering hardware model was operational. A year later, when the first engineering 370 model was up and running a copy of the "CP-I" system was booted on the machine (boot button on this machine turned out to be a knife switch rather than buttons seen on most 360s & 370s). This boot failed ... it turned out that the hardware engineers had swapped two of the new 370 instructions (the software was correct, but the hardware was wrong). After quick patch to the software, the CP-I system was re-booted on the real 370 and came up succesfully (the engineering machine implementation was eventually corrected to correspond to the hardware specifications).
The common mainframe operating systems that have been run under CP have been CMS, DOS, PCP, MFT, MVT, DOS/VS, VS1, SVS, MVS.
Other operating systems that have run under CP have been TSS/360 & TSS/370, several flavors of Unix ports, PARS/ACP/TPF (airline control program, now called transaction processing facility ... various financial networks make use of TPF in addition to the airline operations), and MTS (michigan terminal system). There were also a variety of card & tape-based "monitors" (code on tape or cards that could be booted).
More recently I believe I saw some reference to thousands of copies of Linux running concurrently under a single CP.
There are also a couple of projects that have "CP" that have been
implemented on i86 architecture platfroms that provide ibm mainframe
virtual machines.
http://www.funsoft.com/
http://jmaynard.home.texas.net/hercos360/
Most current IBM mainframes provide an abbreviated version of "CP" built into the machine itself that provides "LPARS" (i.e. logical partitions).
some information & background of VM/CP
http://www.princeton.edu/~melinda/
misc. other references:
http://www.garlic.com/~lynn/94.html#7
http://www.garlic.com/~lynn/94.html#20
http://www.garlic.com/~lynn/94.html#48
http://www.garlic.com/~lynn/95.html#0
http://www.garlic.com/~lynn/97.html#27
http://www.garlic.com/~lynn/99.html#7
http://www.garlic.com/~lynn/99.html#20
http://www.garlic.com/~lynn/99.html#135
http://www.garlic.com/~lynn/99.html#136a
http://www.garlic.com/~lynn/99.html#197
http://www.garlic.com/~lynn/2000.html#8
http://www.garlic.com/~lynn/2000.html#49
http://www.garlic.com/~lynn/2000b.html#28
http://www.garlic.com/~lynn/2000b.html#43
http://www.garlic.com/~lynn/2000b.html#54
http://www.garlic.com/~lynn/2000b.html#50
http://www.garlic.com/~lynn/2000b.html#51
http://www.garlic.com/~lynn/2000b.html#52
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: VM (not VMS or Virtual Machine, the IBM sort) Newsgroups: alt.folklore.computers Date: Sat, 29 Apr 2000 04:14:38 GMTSome postings from vmesa-l mailing list circa feb this year. This tests running linux images under VM/CP running in a LPAR (logical partition ... subset of the real machine resources).
...
Reason for the question: I want to see just how many Linux images I can cram
onto one CP before it goes casters up.
(BTW, current count: 10,045 concurrent images. I can now duplicate any WWW
hosting facility on the planet in 10x10 square feet. Admittedly, it's
getting a bit sluggish with only 2 real CPUs, but wait until I get on a box
where I have the FULL resources of the setup instead of a capped
LPAR....8-)))
....
My test LPAR finally ran out of gas (no resources available) at:
41,400
separate Linux images. Yes, FORTY-ONE THOUSAND WWW servers on a single
physical system. The last few hundred were painful as CP was fighting for
resources against a LPAR cap, but it did it. I finally ran out of storage
at 41K and change.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: definitions Newsgroups: comp.databases.theory Date: Sat, 29 Apr 2000 17:06:36 GMT"Ken" writes:
row/column is less suited to situations where the population has much more of one-to-one correspondance ... i.e. if relationally normalized rather than having a few tables with millions of rows each ... millions of tables with few rows each.
some examples tend to the data dictionaries themselves or other information populations with complex and hetrogeneous/non-homogeneous structures. when instantiated in relational databases they tend to be non-normalized (i.e. tendency to have columns which are "relationships" ... and one or more fields in each row that give the actual relationship information).
the taxonomy/glossaries at
http://www.garlic.com/~lynn/
are rather trivial ... but would represent interesting problem to do
as a few tables if done as fully normalized relational ... including
consistent maint. of bi-directional relations ...
http://www.garlic.com/~lynn/payment.htm
http://www.garlic.com/~lynn/secure.htm
http://www.garlic.com/~lynn/x9f.htm
http://www.garlic.com/~lynn/financial.htm
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: oddly portable machines Newsgroups: alt.folklore.computers Date: Sun, 07 May 2000 23:18:17 GMTjmaynard@thebrain.conmicro.cx (Jay Maynard) writes:
3081 came with two processors in a single box (wasn't fully redundant as the 370 configurations with two full set of everything).
ACP/TPF didn't have multiprocessor support at the time 3081 was released ... and some the airlines and various financial networks were stressing their configurations to the limit. A Q&D 15% speed up for TPF was obtained by pulling the second cpu & cache out of the 3081 box ... which resulted in the 3083 (although there were some installations where VM was used on a 3081 running two copies of TPF ... effectively one per processor).
3084 was like 370 multiprocessing in the sense that two independent boxes were lashed together using a pair of two 3081s (but resulting in 4-way instead of 2-way ... since each 3081 was integrated 2-way processing).
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: oddly portable machines Newsgroups: alt.folklore.computers Date: Sun, 07 May 2000 23:25:17 GMTMike Orceyre writes:
misc. related refs:
http://www.garlic.com/~lynn/99.html#63
http://www.garlic.com/~lynn/99.html#66
http://www.garlic.com/~lynn/99.html#67
http://www.garlic.com/~lynn/99.html#69
http://www.garlic.com/~lynn/99.html#70
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: oddly portable machines Newsgroups: alt.folklore.computers Date: Sun, 07 May 2000 23:29:43 GMTone of the people at CSC ported spacewar to 1130/2250m4 (aka m4 was the 1130-based 2250 model) in the late '60s ... the 2250 keyboard was split into left & right half for player controls. some of the associated 1130 effort also involved tieing the 1130 to the 360/67 resulting in cpremote, the precursor to vnet, the internal network and bitnet.
misc. references:
http://www.garlic.com/~lynn/99.html#112
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: looking for December 1974 RFC 675, "Specification of Internet Transmission Control Protocol" Newsgroups: alt.folklore.internet,alt.internet Date: Sun, 07 May 2000 23:45:39 GMT"Nathan Burgess" writes:
the pointer to 675 is:
ftp://ftp.isi.edu/in-notes/rfc675.txt
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: oddly portable machines Newsgroups: alt.folklore.computers Date: Mon, 08 May 2000 04:22:43 GMTMike Orceyre writes:
I did get to work on design of new ground station as part of HSDT and was built by completely different companies for straight high performance digital.
misc. other references:
http://www.garlic.com/~lynn/98.html#49
http://www.garlic.com/~lynn/99.html#34
http://www.garlic.com/~lynn/99.html#115
http://www.garlic.com/~lynn/99.html#201
http://www.garlic.com/~lynn/2000b.html#19
http://www.garlic.com/~lynn/2000b.html#27
http://www.garlic.com/~lynn/2000b.html#43
& repost from http://www.garlic.com/~lynn/94.html#33b ... the referenced newsgroup was initiated by the same group associated with the uc.5 decision.
As I mentioned in prior postings ... telecommuting implies that person
location & work becomes distance insensitive (world-wide ... or even
further as some people are found of thinking about). info services
have always been to some extent distance insensitive ... but the
world-wide deployment of newer high-speed data transport (in the early
'80s I ran a project & coined the term HSDT ... high-speed data
transport) technology significantly exacerbates the situation.
should work tho.
--
There were a variety of dataset organizations ... within the
contiguous allocation & extent areas (sequential, partitioned,
indexed, etc).
i could see phone company handsets morphing into datasets ... as well
as computer sets of data morphing into datasets.
--
misc. references:
on the other hand ... somebody claimed that for an extended period,
adventure was responsible for 1/3rd of all activity at the STL data
processing complex (in one of the above references ... it was somebody
from STL that took the fortran version of adventure and did a 450pt
PLI version). There were similar problems at other labs, but i never
heard anybody quote exact numbers (lots of people considered adventure
a virus since it suckered people into invoking it and then consumed
large quantities of their time).
random ref:
--
The thunderstorm lasted an hour in the Chicago area and had reduced
landing capacity/frequency at the airport by about 75% during that
hour. Six hours later, planes schedules were up to 4 hrs late and
delays were increasing. The whole operation appeared to be non-stable
with severe negative feedback.
The only factor that seems to allow the infrastructure to eventually
recover is the midnight to 5am period with little or no scheduled
traffic.
It is possible to create self-repairing, stable, optimized
infrastructures, but frequently such issues are overlooked.
--
the specific ohare issue appeared to be something like 45 minutes or
so of lost landing capacity early in the day ... was not a stable
situation and that problems tended to be magnified during the course
of the day (8-10 hrs later) . I don't think it was just runways
... but gates, gate staff, etc (find the plane diverted to the south
40 parking lot until a gate clears). I don't imagine that runways and
approaches are operating at 100% capacity thru-out the day (the
take-off delay queue at most airports tend to vary during course of
the day ... form zero to long lines).
Infrastructure should at least attempt to eliminate the magnification of
problems over time ... and preferrably somewhat self-repairing.
--
etc.
also
has a keyword/term index for RFCs ... including RFCs related to SMTP.
they aren't all online ... but reasonable selection
--
one of the primary things in late '60s leaving cp/67 up and running
7x24 was redoing telecommunication I/O sequence to include
Prepare. The problem was that if there appeared to an active I/O (even
waiting for keystroke input from a terminal) ... the cpu meter would
continue to run (in the days of rented/leased machines) ... even if
the cpu was idle. Letting the cpu meter stop, even when the system was
available ... made a huge difference in the monthly rental rate for
early 7x24 operation (getting 4th shift billing down to less than 5%
of 1st shift rates).
& tom's reference to automatic re-ipl/boot:
with bug in my TTY support code (and adverse interaction with some
local MIT code) causing 27 crashes in a single day (and multics
comparison taking an hour to reboot after a crash).
--
--
misc. network vis-a-vis SNA discussion
there were all sorts of battles with the communication division ...
starting with telecommunication box clones, peachtree vis-a-vis uc.5,
big fights to prevent any sort of TCP/IP activity, then strenuous
battle to try and divert to OSI (along the lines of some of the GOSIP
stuff), and then some funny things claiming to support TCP/IP (but as
poorly as possible, when they were finally forced to provide
vtam-based tcp/ip implementation ... it had to be rewritten so that
tcp/ip thruput was significantly worse than LU6.2 ... rather than
signficantly better).
for description of some of the tcp/ip stuff
misc. refs:
--
In CMS case, it did metadata shadowing on update and then rewrote the
single master file directory (MFD) record indicating which metadata
was correct. It turned out that there was a specific failure mode
where a problem could occur in the middle of a disk write and leave
the MFD corrupted (not in consistent before state or consistent after
state). The CMS extended filesystem (circa '74) had a pair of MFD
records, with version numbers that it would alternate write to.
One of the specific problems were disk infrastructures that didn't
have sufficient power to guarentee completion of a disk write during a
power failure. If a power failure occured at just exactly the right
moment it was possible for only part of a disk record write to finish.
It was one of those early '70s problems ... fixing software
infrastructure to improve integrity in the scenerio of power failures
resulting in partial disk record writes.
A standard partial disk write would at least would have an error
indication when rereading the disk record (the ECC at the end of the
record wouldn't correspond to the data read for the record). A
pathelogical case involved the whole computer infrastructure. The disk
would have enough power (in the case of a power failure in the middle
of a write) to complete the disk write ... and write the correct disk
ECC, but there wasn't enough power to continue to transfer the record
data from the computer memory to the disk controller (or even to
continue to power the computer memory). In this pathelogical case, the
disk write would complete & a correct ECC would be written ... but the
trailing part of the record would consist of all zeros (i.e. the disk
controller would just fill in zeros if it stopped receiving data from
the computer memory during power failure for a disk record write in
progress). In this case, there wouldn't even be an error indication
reading the record during recovery.
Many/most disk drives today guarentee correct record write completion
(or a read error indication), individual records cached locally.
--
--
I don't know of any of these complexes being battery configured
(possibly the FAA systems were/are?).
I know some current complexes with sophisticated PDUs and large diesel
generators. They have very large basement room somewhere that can
cover from the power interruption until the diesel kicks in.
--
--
--
diverse routing is common for both power & telco ... also making sure
access is from opposite sides of the building ... backhoes can cause
all sorts of problems.
when we were doing ha/cmp ... we talked to somebody that had found a
building in manhatten that had telco from four different central
exchanges entering the building from four different directions, two
separate water mains into different sides of the building, two
separate power from different power grids entering the building from
different directions. They considered it quite a find. THey actually
wanted two of these in different parts of the city.
--
--
The EDX folklore, it was done by a summer intern for a couple
physicists doing lab stuff at san jose research.
random other refs:
--
--
There was some speculation that a lot of SNA was motivated by some
work that I had done as an undergraduate.
misc. ref.
--
if this information is pre-loaded ... then there is no need to
transfer certificate(s) as part of each transaction.
a simple version of this was demonstrated at PC/EXPO a couple years
ago as "AADS" Radius ... i.e. Radius upgraded so that public key was
registered in the Radius id database ... and a signed transaction
(containing userid, time, & a couple other pieces) ... in place of
userid/password sequence.
the pre-loading can even be done w/o certificates of any kind ... in
the Radius case ... basically substitute the password registration
process with a public key registration process. it has the advantage
of eliminating shared-secret ... vis-a-vis existing userid/passwords.
misc. references:
--
the symptons wasn't that anybody was trying to undercut top management
goals ... but RDBMS normalization appears to be non-linear complexity
problem ... past some threshold ... the process exceeded the
organization's aggregate intellectual capacity. The executives weren't
going to give anybody the time, funding &/or resources to address the
complexity problems.
Even the concept of trying to integrate possibly a hundred
applications per database across the 6000 databases and hundreds of
business units also is a major complexity effort ... having an
organization that could have managed the complexity issues of
single integrated environment rather than the divide and conquer
solution.
More recently had a project to do data-cleaning on large production
database. Part of the database was a large number of fields that the
executives and product owners required to represent hierarchical
relationships between large number of different entities. When it was
set-up ... there wasn't an application that was actually dependent on
the values representing hierarchical organization. However, sometime
later a new application was developed that was actually dependent on
having a hierarchical relationships ... only to find out the
executives, business owners, product managers, and account
representatives ... when they had a need to represent a mesh
infrastructure perverted the field values to their own business use
... and those nasty MIS bureaucracies didn't prevent them.
--
The AADS model somewhat grew out of situation involving existing
business and supporting infrastructures that are already in place for
authentication ... but may have been shared-secret based (ISP password
login, radius password , PIN debit financial transaction, web server
password login, call-center asking for mother's maiden name &/or SSN,
datacenter password login, etc). These environments also tended to
have business infrastructures that dealt primarily with other entities
for which they had existing &/or prior business relationships (you
logged into an established userid, signed in as an employee, accessed
existing financial account).
In this scenerio, a certificate attached to every message &
transaction represented stale, redundant and superfluous copy of
information that was being maintained in the businesses account
records (or business equivalent that represented established
relationship between the parties).
Some of the situations also had other business requirements, like
existing message traffic was in 60-80 byte range in a network
operating at near capacity. Appending a 1000+byte certicate to a large
number of such messages not only represented stale, redundant and
superfluous information transfer ... but also a heavy infrastructure
traffic burden.
An certificate analogy is letters of credit/introduction in the days
of sailing ships prior to telephones, faxes, and online environments
(i.e. the stale, redundant information in a certificate can enable
distributed, offline authentication for environments that don't have
online realtime access to the original copy of the information).
X9.59 is an ANSI financial industry draft standard for all
account-based electronic retail payments that can be deployed using an
AADS model ... i.e. existing business relationships, online realtime
access to the database processing factilities that instantiate the
business relationships, existing relatively small messages sizes with
high capacity existing networks than periodically operate near
saturation where certificate represents stale, redundant and
superfluous information transmission as well as several hundred
percent message size bloat.
--
in any case the other way of looking at it is basd on X9F1 work on
x9.68 certificate compression, i.e. if the receiving/relying party
already has the information, the field can be compressed out of the
certificate. AADS with knowledge analysis of the business process
shows 100% field compression resulting in zero byte certificates
(i.e. certificates aren't eliminated, they are reduced to zero bytes).
The other scenerio is the certificate chain attachment. Certificates
that the receiving/relying party can reasonably be expected to
have/obtain, can be eliminated from the certificate chain (say in SSL
protocol where the browser already has database of self-signed root
certificates). If various AADS scenerios, where the receiving/relying
party can be shown to already have all the certicates ... then the
certificate chain can be compressed to zero certificates.
misc. refs
--
Speaking of HSDT, in the mid-80s we were contracting for equipment for
parts of the HSDT project from some companies in Japan. On the Friday
before I was to leave for a meeting, somebody (in the US) announced a
new newsgroup on high-speed data communication including in the
posting the following definitions:
low-speed <9.6kbits
medium-speed 19.2kbits
high-speed 56kbits
very high-speed 1.5mbits
On Monday morning on the wall of a conference room in Japan was:
low-speed <20mbits
medium-speed 100mbits
high-speed 200-300mbits
very high-speed >600mbits
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Maximum Length of an URL
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Maximum Length of an URL
Newsgroups: comp.infosystems
Date: Mon, 08 May 2000 15:57:09 GMT
CAM writes:
A clue regarding enterprise servers is at:
http://help.netscape.com/kb/corporate/19971110-3.html
A further clue is at:
http://www.forwiss.uni-passau.de/~englmait/html4/types.html#type-cdata
Which leads to "Uniform Resource Locators", by T. Berners-Lee, L.
Masinter, and M. McCahill, December 1994.
Available at http://ds.internic.net/rfc/rfc1738.txt.
Normative References are at
http://www.forwiss.uni-passau.de/~englmait/html4/references.html#h-1.1
Default User wrote:
> I having been trying to find out whether or not there is a maximum
> length of an URL. The only things I could find in the RFC's were the
> allowable character sets.
>
> Thanks,
>
> Ian
> butt@nortelnetworks.com
it has been quite awhile since ds.internic.net (at&t) has been funded,
plain internic.net is still around (rs.internic.net, registration).
ftp://ftp.isi.edu/in-notes/rfc1738.txt
http://www.garlic.com/~lynn/rfcietff.htm
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
"Database" term ok for plain files?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Database" term ok for plain files?
Newsgroups: alt.folklore.computers
Date: Mon, 08 May 2000 18:54:55 GMT
lwinson@bbs.cpcn.com (lwin) writes
We used "dataset" for both, and it was confusing. The Bell supplied
modems were called "datasets", and IBM JCL then and NOW uses the
term to mean a file.
i don't know the early reasons ... disk had VTOCs (volume table of
contents) which pointed to datasets (sets of data?) which could be
primary (contiquous) allocation & possibly some number of extents
(secondary allocations).
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Microsoft boss warns breakup could worsen virus problem
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Microsoft boss warns breakup could worsen virus problem
Newsgroups: alt.folklore.computers
Date: Tue, 09 May 2000 02:06:46 GMT
ab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
Way back in in the early '70s, I argued that employees should be given
computer time for learning. In those days, a service bureau could
charge $1,200 Cdn per hour for CPU time plus I/O etc. on a 360-85!
My account was SHPD1, SoftwareHouse Personal Development 1.
I had gotten copy of adventure within a couple months of it appearing
... & made it available for the internal network ... and then succesfully
argued that lots of people should be exposed to it since it
represented an improved user interface (compared to many of the
..business.. applications of the day).
http://www.garlic.com/~lynn/98.html#56
http://www.garlic.com/~lynn/99.html#52
http://www.garlic.com/~lynn/99.html#83
http://www.garlic.com/~lynn/99.html#112
http://www.garlic.com/~lynn/2000b.html#56
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Scheduling aircraft landings at London Heathrow
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Scheduling aircraft landings at London Heathrow
Newsgroups: sci.op-research,comp.ai.genetic
Date: Tue, 09 May 2000 16:24:49 GMT
Robin Becker writes:
Since optimality is generally the enemy of robustness/stability do these
traffic improvement models have constraints to guarantee levels of
safety?
tightly scheduled may not allow for self-repairing. I remember being
scheduled to go from San Jose to Boston with a connection at
Ohare. The flight was due to leave San Jose at 7am (pst) ... but we
were delayed on the ground for an hour (after we were on the plane)
because of a thunderstorm that had just gone thru the Ohare airport
area.
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Scheduling aircraft landings at London Heathrow
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Scheduling aircraft landings at London Heathrow
Newsgroups: sci.op-research,comp.ai.genetic
Date: Wed, 10 May 2000 03:50:48 GMT
"Jerry Harder" writes:
Airports are extremely expensive to build so duplication would be an
extremely expensive solution. Chicago is a good example, since Midway
handles many domestic flights. However, Midway cannot handle the larger jets
and has no facilities, at least as far as I remember, to handle
international flights with their requirements on landing to process
passengers through Customs and Immigration. In addition, if the weather is
bad in one part of a metropolitan area, the odds are high that it is bad in
all other parts.
i have worked on some of the associated issues ... misc. ref:
http://www.garlic.com/~lynn/2000.html#61
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
BASIC SMTP questions
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: BASIC SMTP questions
Newsgroups: bit.listserv.vmesa-l
Date: Mon, 8 May 2000 14:26:03 -0700
At 12:01 AM 5/3/2000 -0500, Automatic digest processor wrote:
I am over the hurdle of the '@' problems. By the way both the backslash
and double quote work- I forgot to change my escape character to
something other than double quote (DUH).I do have some very basic SMTP
mail questions.
(1) Where are the RFC's (RFC821, RFC822, etc.) documented?
check
ftp://ftp.isi.edu/in-notes/rfc821.txt
ftp://ftp.isi.edu/in-notes/rfc822.txt
http://www.garlic.com/~lynn/rfcietff.htm
(2) How do I get the SUBJECT: put into the mail as a subject
recognizable to the receiving mail server? I didn't see anything in the
sendfile help.
--
Anne & Lynn Wheeler lynn@adcomsys.net, lynn@garlic.com
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
Rainbow Series (a hard item to find..)
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Rainbow Series (a hard item to find..)
Newsgroups: comp.security.misc
Date: Wed, 10 May 2000 16:33:53 GMT
"Coy" writes:
Looking for original hardback copies of the Rainbow Series.
(Trusted Computer System Evaluation Criteria | TCSEC )
As I'm sure most of you know, these books have stopped publication
back in Feb of 1997.
However, I am in search for anyone who is selling or giving theirs away =D
or if they know anyone who is still publishing these books.
Any helpful info would be appreciated
Thanks again..
Coy.
have you tried:
http://www.radium.ncsc.mil/tpep/library/rainbow/index.html
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
write rings
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: write rings
Newsgroups: alt.sys.pdp10,alt.folklore.computers
Date: Wed, 10 May 2000 21:08:00 GMT
ehrice@his.com (Edward Rice) writes:
Most Multics systems, and many GECOS/GCOS systems, were left running
unattended for weekends and holidays. Unit record and dismountable devices
were set to be unavailable, and the system just kept cranking. That was my
reference. Loading or unloading timesharing (or varying its size) because
of the number of users isn't something that has to be an operator function.
Starting and stopping batch job queues doesn't have to be done by human
hands. For that matter, neither does rebooting if the system crashes.
misc refernces:
http://www.garlic.com/~lynn/99.html#17
http://www.garlic.com/~lynn/99.html#44
http://www.garlic.com/~lynn/99.html#71
http://www.garlic.com/~lynn/99.html#72
http://www.garlic.com/~lynn/99.html#86
http://www.garlic.com/~lynn/99.html#87
http://www.garlic.com/~lynn/99.html#107
http://www.garlic.com/~lynn/99.html#137
http://www.lilli.com/360-67 (corrected) http://www.multicians.org/thvv/360-67.html
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
"Database" term ok for plain files?
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Database" term ok for plain files?
Newsgroups: alt.folklore.computers
Date: Wed, 10 May 2000 21:13:37 GMT
ehrice@his.com (Edward Rice) writes:
"Disks"? Don't you mean DASD, Direct Access Storage Devices, Lynn? IBM
never had "disks," did they?
ehr
so they created syntactic confusion ... inventing different words for
common stuff ... and using other words to mean completely different
things; like SNA ... an acronym for System Network Architecture
... applied to a telecommunication control program ... and was not a
System, was not a Network, and was not an Architecture (can you have a
triple oxymoron?).
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
"Database" term ok for plain files?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Database" term ok for plain files?
Newsgroups: alt.folklore.computers
Date: Thu, 11 May 2000 00:17:53 GMT
lwinson@bbs.cpcn.com (lwin) writes:
I thought SNA was the type of data communication hook up. It was
sychronous (as opposed to async which what we use to dial up from home),
but different than the older "bi-sync" they used. In that sense, I
would think it was a 'network architecture' which is about the same
thing as 'communications protocol'.
In other words, you had an "SNA" box at one end, and another SNA box
at the other end.
there really wasn't much of anything that could be considered SNA box
... there were boxes that spoke bi-sync & sdlc and some other
stuff. There was VTAM & NCP ... and much of the rest was hype of one
sort or another.
http://www.garlic.com/~lynn/2000.html#53
http://www.garlic.com/~lynn/2000.html#51
http://www.garlic.com/~lynn/2000.html#85
http://www.garlic.com/~lynn/99.html#12
http://www.garlic.com/~lynn/99.html#36
http://www.garlic.com/~lynn/99.html#44
http://www.garlic.com/~lynn/99.html#66
http://www.garlic.com/~lynn/99.html#67
http://www.garlic.com/~lynn/99.html#70
http://www.garlic.com/~lynn/99.html#195
http://www.garlic.com/~lynn/2000.html#7
http://www.garlic.com/~lynn/2000b.html#66
http://www.garlic.com/~lynn/2000b.html#69
http://www.garlic.com/~lynn/internet.htm
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
write rings
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: write rings
Newsgroups: alt.sys.pdp10,alt.folklore.computers
Date: Thu, 11 May 2000 16:09:42 GMT
jmfbahciv writes:
An _hour_ to reboot? You're joking, aren't you?
check-out URL ... basically filesystem integrity checking ... I've seen
some large Unix filesystems that could also take an hour to check (also
remember Unix is a take-off on Multix).
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
write rings
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: write rings
Newsgroups: alt.sys.pdp10,alt.folklore.computers
Date: Thu, 11 May 2000 17:16:33 GMT
Anne & Lynn Wheeler writes:
controller would just fill in zeros if it stopped receiving data from
the computer memory during power failure for a disk record write in
progress). In this case, there wouldn't even be an error indication
reading the record during recovery.
the version number for logical records would be in the very last bytes
of the record ... any situation involving zeros propagated disk write
would result in the same or lower version number. If it was the same
version number (because of zeros propagation just involving part of
the version number part of the record), then the rest of the record
would be correct and consistency would be preserved regardless of
which record was chosen (although the latest changes might available
but possibly discarded).
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
write rings
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: write rings
Newsgroups: alt.sys.pdp10,alt.folklore.computers
Date: Thu, 11 May 2000 21:41:59 GMT
westinnospam@graphics.cornell.edu (Stephen H. Westin) writes:
Well, the VAX with battery memory backup was able to retry all disk
I/O that was in progress when power failed. Which seems like a pretty
reliable mechanism.
in the 60s where typical computer room may have spanned more than a
football field ... and core memory was so expensive there was no local
caching ... data was transferred directly from processor memory thru
the cable infrastructure to the disk controller thru its cable
infrastructure to the actual disk. Processor complex in the center of
the room could have 150'-200' cable stretching out in various
directions. CSC's complex was rather modest 360/67 with 45 2314 disk
drives and took up about 1/2 the 2nd floor at 545 tech. sq. Even the
PDUs and the chillers were quite large boxes ... along the
walls. Complex had a huge power draw.
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
write rings
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: write rings
Newsgroups: alt.sys.pdp10,alt.folklore.computers
Date: Thu, 11 May 2000 23:02:13 GMT
don@news.daedalus.co.nz (Don Stokes) writes:
You said core memory. Core doesn't need battery backup to do
powerfail recovery. BBUs on MOS memory machines were largely to emulate
the behaviour of systems with core memory...
this is for disk write in progress ... you needed power to read the
memory ... dump it down 200' of cable to disk controller and then the
disk controller down the cable to the disk. In Power drop there was
enuf power for the disk to complete the write ... but there were
situations where there wasn't enuf power to continue reading the data
from memory and sending down the cable (to the disk) ... so the disk
write would complete with just propagating zeros until the end of the
write.
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
write rings
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: write rings
Newsgroups: alt.sys.pdp10,alt.folklore.computers
Date: Fri, 12 May 2000 01:45:58 GMT
albaugh@agames.com (Mike Albaugh) writes:
Another of my "favorite" mis-features was a mini we had
at school (U.C. Berkeley). I _think_ it was a DG Nova, but I
another UCB story i've heard was the 10am(?) tuesday failures of the
cdc6600. they supposedly eventually figured out that the grass was
being watered at that time which coincided with a class break and lots
of things flushing ... which dropped water pressure to the computer
room cooling units.
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Mainframe power failure (somehow morphed from Re: write rings)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Mainframe power failure (somehow morphed from Re: write rings)
Newsgroups: alt.sys.pdp10,alt.folklore.computers
Date: Fri, 12 May 2000 15:24:20 GMT
jcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:
Glossary: PDU := Power (and sometimes coolant also) Distribution Unit. A
PDU could be the size of a very large home refrigerator.
about a year ago i toured a large datacenter. they made a point of
pointing out the PDUs. I don't remember all the details but this was
apparently the top of the line model and that a couple years ago they
had some problems in slight fluctuations (tens of milliseconds?) with
cut-over during power failure. They hired two engineering firms to
redesign the PDU & work with the PDU manufacturer. When it was done they
turned over all rights to the PDU manufacturer. There was some statement
that there were then on the order of 1000 of the new PDUs installed in
the WashDC area alone. These PDUs were more like 4'-6' wide.
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
write rings
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: write rings
Newsgroups: alt.sys.pdp10,alt.folklore.computers
Date: Fri, 12 May 2000 20:55:43 GMT
jcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:
The one scenario I can think of would be if the cooling system was
monitoring the pressure of the lines used for make-up water (the same
lines used for flushing) and went into alarm state when the pressure
there dropped.
i know that the units for 360/67 machine room on 2nd floor of 545 tech
sq. had a 6inch pipe that dumped water directly into cambridge sewer
system well into the mid-70s. When they started looking at closed
system there was some issue whether the roof at 545 tech sq could take
the weight of the water tank. I'm not sure if they ever did put a tank
on that roof for a closed system .. they may have moved down to new
bldg. at 101 main before getting a closed system.
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Motorola/Intel Wars
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Motorola/Intel Wars
Newsgroups: alt.folklore.computers
Date: Sat, 13 May 2000 00:36:54 GMT
"Robert J. Stevens" writes:
Now Your Talking My Language. Just a few Yearsd ago I got intp consulting
and two Places were looking for an EDL/EDX Programmer and my Name kept
coming up. Made enough to be able to retire. Loved it but some people just
couldn't get it. The S/1 could run rings around any computer made if you
knew how to program it. In fact the Series/1 is still being used overseas
and ther is an emulator that runs on the RISC 6000. I still have two
machines in the Basement which I have to get fired up this summer. Both of
them are wired for 110v so that should not be to difficult.
Bob in Wisconsin
There was the joke about "official" RPS system S/1 was done by 360/MFT
refugees that moved from Kingston to Boca ... who were trying to
recreate MFT on a 16bit machine.
http://www.garlic.com/~lynn/2000b.html#66
http://www.garlic.com/~lynn/2000b.html#79
http://www.garlic.com/~lynn/2000.html#64
http://www.garlic.com/~lynn/2000.html#71
http://www.garlic.com/~lynn/99.html#63
http://www.garlic.com/~lynn/99.html#66
http://www.garlic.com/~lynn/99.html#67
http://www.garlic.com/~lynn/99.html#69
http://www.garlic.com/~lynn/99.html#70
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
write rings
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: write rings
Newsgroups: alt.sys.pdp10,alt.folklore.computers
Date: Sat, 13 May 2000 16:05:15 GMT
ehrice@his.com (Edward Rice) writes:
> http://www.garlic.com/~lynn/99.html#137
Uh, Lynn? You want to narrow that down just a little? I do love reading
your archives, it's almost always educational and fun, but that reference
is to a list of hundreds of links to articles, and I do have /some/ life
outside of answering this one article of yours.
finger slip (no such reference, so you got the start of the archive), try
http://www.garlic.com/~lynn/99.html#137
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
"Database" term ok for plain files?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Database" term ok for plain files?
Newsgroups: alt.folklore.computers
Date: Sat, 13 May 2000 17:56:42 GMT
Brian Inglis writes:
I think the intent of the name SNA may have been to indicate that
it was dependent on a central host system for operation. It was
the set of protocols used by IBM comm gear to talk to the host.
Later relaxed to allow some peer-to-peer functions with LU6.2
APPC then APPN.
The SNA group non-concurred with APPN announcement and support for
peer-to-pear and networking. The original APPN announcement was
delayed 6 weeks while the dispute was resolved and the announcement
letter was rewritten so there would be no confusion whether APPN was
part of SNA.
http://www.garlic.com/~lynn/93.html#2
http://www.garlic.com/~lynn/95.html#14
http://www.garlic.com/~lynn/2000.html#51
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Question regarding authentication implementation
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Question regarding authentication implementation
Newsgroups: sci.crypt
Date: Sat, 13 May 2000 19:07:03 GMT
Abid Farooqui writes:
A colleague of mine has developed using BSAFE libraries a security
application that does authentication at connection startup and
encryption when data is transferred. The client certificates, Root
certificates and client or partner certificates are stored in so called
queue. When you load a client/partner certificate you can VERIFY that
certificate against a list of available CA Root certificates that you
already have in the queue. This is a completely separate step and is
done in a non-active manner, meaning this happens way before the
client/partner is establishing any kind of connection to you.
Now, that you have a clinet/partner certificate loaded into a queue ...
when the client/partner establishes connection to you, he/she will send
a NONCE(Dummy message) signed with his/her private key to prove his
identity to you. When you receive the NONCE, you can try and decrypt it
using this partner's Public Key that you have already loaded into the
queue, if it decrypts etc. etc. then it must be the partner because only
note that a certificate queue can be viewed as an account database ...
and the public key and the associated id information represents an
account record.
http://www.garlic.com/~lynn/aadsm3.htm#kiss3
http://www.garlic.com/~lynn/2000b.html#14
http://www.garlic.com/~lynn/draft-wheeler-ipki-aads-01.txt
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
A note on the culture of database
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: A note on the culture of database
Newsgroups: alt.folklore.computers
Date: Sun, 14 May 2000 19:18:38 GMT
-- spinoza9999 writes:
However, in actual practice, MIS bureaucracies systematically and
silently undercut top management goals in actually implementing this
vision in order to preserve their position. This will typically be at
key chokepoints of the data base system.
we worked with several large corporations ... typical was that once
the complexity of a RDBMS reached some treshold ... it was cloned. One
organization figured that they had >6000 different RDBMS with
approx. 90% of the data common. This led to all sorts of data
integrity problems (i.e. mailing address might occur in hundred
different databases).
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Question regarding authentication implementation
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Question regarding authentication implementation
Newsgroups: sci.crypt
Date: Sun, 14 May 2000 21:11:03 GMT
Abid Farooqui writes:
My colleague is certainly not doing this because when the certificate
queue is loaded, he strips off everything from the certificate and
only the public key is loaded and hence there is little chance that he
is verifying the validity of the digital signature by referring to the
contents of the accompanying certificate as he does not actually have
the whole certificate loaded into the queue, only the public keys.
Also keep in mind that we are selling this product and claiming that
it uses CADS model (Certificate Authority Digital Signature model) and
not AADS (Account Authority Digital Signature model) whose draft I
believe is submitted to IEEE by First Data Corp and I am not sure of
the status of the draft at this point. Anyway my question remains, is
my colleagues practices and logic in accordance with the traditional
PKI practices and procedures (CADS model). If not then I have to raise
a red flag. Any input in this regard is appreciated. Sincerely, Abid
Farooqui
The CADS model has been considered to have grown out of offline email
requirement in the early to mid 80s where an end-user connected to the
network, downloaded their email, and disconnected. They then was left
with the opportunity of validating the email in a standalone, end-user
environment with little or no business and supporting infrastructure.
There was also high possibility that the incoming email was from
source that the receiver had no little or prior business knowledge.
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Question regarding authentication implementation
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Question regarding authentication implementation
Newsgroups: sci.crypt
Date: Sun, 14 May 2000 21:52:32 GMT
as an aside, NIST in the past has written standards from scratch like
FIPS-186 for authentication, digital signatures standards. NIST has a
statement someplace that says that it will be considering the direct
adoption of industry standards for FIPS. FIPS-186-2 and X9.62 had a
lot of work done in common.
http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2
http://www.garlic.com/~lynn/2000.html#36
http://www.garlic.com/~lynn/2000.html#37
http://www.garlic.com/~lynn/2000.html#39
http://www.garlic.com/~lynn/2000.html#40
http://www.garlic.com/~lynn/2000.html#41
http://www.garlic.com/~lynn/2000.html#42
http://www.garlic.com/~lynn/2000.html#45
http://www.garlic.com/~lynn/2000.html#46
http://www.garlic.com/~lynn/2000.html#47
http://www.garlic.com/~lynn/2000.html#48
http://www.garlic.com/~lynn/2000b.html#40
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
next, previous, subject index - home