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
https://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:
https://www.garlic.com/~lynn/99.html#37b
https://www.garlic.com/~lynn/99.html#38b
https://www.garlic.com/~lynn/99.html#38d
in the diagram taken from IEN-166 at:
https://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
https://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
https://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
https://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
https://web.archive.org/web/20041118002130/www.winlab.rutgers.edu/~pravin/presentations/splice-talk/Splice-Talkl17.htm
http://www.ca.sandia.gov/xtp/xtpintro.html
https://web.archive.org/web/20040404113457/http://www.ca.sandia.gov/xtp/xtpintro.html
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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
https://web.archive.org/web/20000302235907/http://users.ticnet.com/davea/greencard/start.htm
http://www.cwi.nl/people/dik/english/codes/80col.html
https://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
https://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
https://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
https://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
https://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
https://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
https://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
https://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
https://www.garlic.com/~lynn/internet.htm
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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:
https://www.garlic.com/~lynn/99.html#217
https://www.garlic.com/~lynn/99.html#224
https://www.garlic.com/~lynn/aadsm2.htm#straw
http://lists.commerce.net/archives/ansi-epay/199912/msg00008.html
https://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
https://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
https://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
https://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
https://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
https://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
https://www.garlic.com/~lynn/99.html#30
https://www.garlic.com/~lynn/99.html#85
https://www.garlic.com/~lynn/99.html#163
https://www.garlic.com/~lynn/99.html#219
https://www.garlic.com/~lynn/2000.html#25
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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)
https://www.garlic.com/~lynn/93.html#28
https://www.garlic.com/~lynn/94.html#00
https://www.garlic.com/~lynn/94.html#16
https://www.garlic.com/~lynn/94.html#33a
https://www.garlic.com/~lynn/94.html#44
https://www.garlic.com/~lynn/95.html#1
https://www.garlic.com/~lynn/96.html#18
https://www.garlic.com/~lynn/96.html#27
https://www.garlic.com/~lynn/96.html#28
https://www.garlic.com/~lynn/96.html#31
https://www.garlic.com/~lynn/96.html#32
https://www.garlic.com/~lynn/96.html#33
https://www.garlic.com/~lynn/96.html#41
https://www.garlic.com/~lynn/97.html#11
https://www.garlic.com/~lynn/97.html#12
https://www.garlic.com/~lynn/97.html#13
https://www.garlic.com/~lynn/97.html#14
https://www.garlic.com/~lynn/97.html#15
https://www.garlic.com/~lynn/99.html#16
https://www.garlic.com/~lynn/99.html#17
https://www.garlic.com/~lynn/99.html#31
https://www.garlic.com/~lynn/99.html#47
https://www.garlic.com/~lynn/99.html#49
https://www.garlic.com/~lynn/99.html#53
https://www.garlic.com/~lynn/99.html#71
https://www.garlic.com/~lynn/2000.html#21
https://www.garlic.com/~lynn/2000.html#22
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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
https://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:
https://www.garlic.com/~lynn/93.html#0
https://www.garlic.com/~lynn/93.html#31
https://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):
https://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
https://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
https://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
https://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
https://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
https://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:
https://www.garlic.com/~lynn/2000b.html#20
https://www.garlic.com/~lynn/2000b.html#24
https://www.garlic.com/~lynn/2000b.html#25
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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:
https://www.garlic.com/~lynn/internet.htm
https://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
https://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
https://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
https://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
https://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
https://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
https://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
https://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
https://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:
https://www.garlic.com/~lynn/2000.html#6
https://www.garlic.com/~lynn/99.html#28
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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
https://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
https://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
https://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:
https://www.garlic.com/~lynn/94.html#23
https://www.garlic.com/~lynn/94.html#24
https://www.garlic.com/~lynn/96.html#18
https://www.garlic.com/~lynn/96.html#19
https://www.garlic.com/~lynn/2000.html#16
https://www.garlic.com/~lynn/96.html#27
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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
https://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
https://www.garlic.com/~lynn/
https://www.garlic.com/~lynn/ansiepay.htm#theory
https://www.garlic.com/~lynn/aepay3.htm#sslset1
https://www.garlic.com/~lynn/aepay3.htm#sslset2
https://www.garlic.com/~lynn/aepay2.htm#aadspriv
https://www.garlic.com/~lynn/aepay2.htm#privrules
https://www.garlic.com/~lynn/aadsmail.htm#comfort
https://www.garlic.com/~lynn/ansiepay.htm#privacy
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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:
https://www.garlic.com/~lynn/2000.html#9
https://www.garlic.com/~lynn/94.html#33
https://www.garlic.com/~lynn/96.html#9
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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:
https://www.garlic.com/~lynn/2000b.html#35
https://www.garlic.com/~lynn/99.html#222
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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:
https://www.garlic.com/~lynn/94.html#22
https://www.garlic.com/~lynn/94.html#29
https://www.garlic.com/~lynn/94.html#31
https://www.garlic.com/~lynn/94.html#33a
https://www.garlic.com/~lynn/94.html#33b
https://www.garlic.com/~lynn/96.html#38
https://www.garlic.com/~lynn/98.html#49
https://www.garlic.com/~lynn/98.html#50
https://www.garlic.com/~lynn/99.html#34
https://www.garlic.com/~lynn/99.html#36
https://www.garlic.com/~lynn/99.html#201
https://www.garlic.com/~lynn/99.html#222
--
Anne & Lynn Wheeler lynn@adcomsys.net, lynn@garlic.com
https://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.
https://www.garlic.com/~lynn/93.html#17
Anne & Lynn Wheeler | lynn@garlic.com
https://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 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.
https://www.garlic.com/~lynn/96.html#15
https://www.garlic.com/~lynn/96.html#34
https://www.garlic.com/~lynn/99.html#54
https://www.garlic.com/~lynn/99.html#71
https://www.garlic.com/~lynn/99.html#164
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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.
https://www.garlic.com/~lynn/aadsm2.htm#inetpki
https://www.garlic.com/~lynn/aadsm2.htm#account
https://www.garlic.com/~lynn/aadsm2.htm#straw
https://www.garlic.com/~lynn/aadsm2.htm#keylength
https://www.garlic.com/~lynn/aadsm2.htm#pkikrb
https://www.garlic.com/~lynn/aadsm3.htm#kiss3
https://www.garlic.com/~lynn/aadsmore.htm#hcrl2
https://www.garlic.com/~lynn/99.html#230
https://www.garlic.com/~lynn/2000b.html#14
https://www.garlic.com/~lynn/8583flow.htm
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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:
https://www.garlic.com/~lynn/99.html#222
http://vm.marist.edu/~piper/party/jph-12.html#wheeler
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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
https://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
https://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
https://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
https://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 occurred 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
https://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:
https://www.garlic.com/~lynn/98.html#35a
https://www.garlic.com/~lynn/99.html#71
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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
https://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:
https://www.garlic.com/~lynn/94.html#47
https://www.garlic.com/~lynn/95.html#5
https://www.garlic.com/~lynn/95.html#6
https://www.garlic.com/~lynn/95.html#11
https://www.garlic.com/~lynn/97.html#5
https://www.garlic.com/~lynn/98.html#25
https://www.garlic.com/~lynn/98.html#26
https://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
https://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:
https://www.garlic.com/~lynn/2000.html#18
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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
https://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
https://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:
https://www.garlic.com/~lynn/2000b.html#4
https://www.garlic.com/~lynn/2000b.html#0
https://www.garlic.com/~lynn/2000b.html#1
https://www.garlic.com/~lynn/2000b.html#8
https://www.garlic.com/~lynn/2000b.html#10
https://www.garlic.com/~lynn/internet.htm
https://www.garlic.com/~lynn/subindex.html#network
https://www.garlic.com/~lynn/99.html#201
https://www.garlic.com/~lynn/99.html#202
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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
https://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 successfully (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.
https://web.archive.org/web/20240130182226/https://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
https://www.leeandmelindavarian.com/Melinda#VMHist
misc. other references:
https://www.garlic.com/~lynn/94.html#7
https://www.garlic.com/~lynn/94.html#20
https://www.garlic.com/~lynn/94.html#48
https://www.garlic.com/~lynn/95.html#0
https://www.garlic.com/~lynn/97.html#27
https://www.garlic.com/~lynn/99.html#7
https://www.garlic.com/~lynn/99.html#20
https://www.garlic.com/~lynn/99.html#135
https://www.garlic.com/~lynn/99.html#136a
https://www.garlic.com/~lynn/99.html#197
https://www.garlic.com/~lynn/2000.html#8
https://www.garlic.com/~lynn/2000.html#49
https://www.garlic.com/~lynn/2000b.html#28
https://www.garlic.com/~lynn/2000b.html#43
https://www.garlic.com/~lynn/2000b.html#54
https://www.garlic.com/~lynn/2000b.html#50
https://www.garlic.com/~lynn/2000b.html#51
https://www.garlic.com/~lynn/2000b.html#52
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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
https://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 correspondence ... 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
https://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 ...
https://www.garlic.com/~lynn/payment.htm
https://www.garlic.com/~lynn/secure.htm
https://www.garlic.com/~lynn/x9f.htm
https://www.garlic.com/~lynn/financial.htm
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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
https://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:
https://www.garlic.com/~lynn/99.html#63
https://www.garlic.com/~lynn/99.html#66
https://www.garlic.com/~lynn/99.html#67
https://www.garlic.com/~lynn/99.html#69
https://www.garlic.com/~lynn/99.html#70
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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:
https://www.garlic.com/~lynn/99.html#112
--
Anne & Lynn Wheeler | lynn@garlic.com
https://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
https://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:
https://www.garlic.com/~lynn/98.html#49
https://www.garlic.com/~lynn/99.html#34
https://www.garlic.com/~lynn/99.html#115
https://www.garlic.com/~lynn/99.html#201
https://www.garlic.com/~lynn/2000b.html#19
https://www.garlic.com/~lynn/2000b.html#27
https://www.garlic.com/~lynn/2000b.html#43
& repost from
https://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.
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.5mbitsOn 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--
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 GMTCAM writes:
should work tho.
https://www.garlic.com/~lynn/rfcietff.htm
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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 GMTlwinson@bbs.cpcn.com (lwin) writes
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.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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 GMTab528@FreeNet.Carleton.CA (Heinz W. Wiggeshoff) writes:
misc. references:
https://www.garlic.com/~lynn/98.html#56
https://www.garlic.com/~lynn/99.html#52
https://www.garlic.com/~lynn/99.html#83
https://www.garlic.com/~lynn/99.html#112
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:
https://www.garlic.com/~lynn/2000b.html#56
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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 GMTRobin Becker writes:
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.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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:
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.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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 -0700At 12:01 AM 5/3/2000 -0500, Automatic digest processor wrote:
etc.
also
https://www.garlic.com/~lynn/rfcietff.htm
has a keyword/term index for RFCs ... including RFCs related to SMTP.
(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
https://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
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:
they aren't all online ... but reasonable selection
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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 GMTehrice@his.com (Edward Rice) writes:
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:
http://www.lilli.com/360-67 (corrected)
https://www.multicians.org/thvv/360-67.html
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).
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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 GMTehrice@his.com (Edward Rice) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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 GMTlwinson@bbs.cpcn.com (lwin) writes:
misc. network vis-a-vis SNA discussion
https://www.garlic.com/~lynn/2000.html#53
https://www.garlic.com/~lynn/2000.html#51
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
https://www.garlic.com/~lynn/2000.html#85
misc. refs:
https://www.garlic.com/~lynn/99.html#12
https://www.garlic.com/~lynn/99.html#36
https://www.garlic.com/~lynn/99.html#44
https://www.garlic.com/~lynn/99.html#66
https://www.garlic.com/~lynn/99.html#67
https://www.garlic.com/~lynn/99.html#70
https://www.garlic.com/~lynn/99.html#195
https://www.garlic.com/~lynn/2000.html#7
https://www.garlic.com/~lynn/2000b.html#66
https://www.garlic.com/~lynn/2000b.html#69
https://www.garlic.com/~lynn/internet.htm
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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 GMTjmfbahciv writes:
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 guarantee completion of a disk write during a power failure. If a power failure occurred 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 guarantee correct record write completion (or a read error indication), individual records cached locally.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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 GMTAnne & Lynn Wheeler writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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 GMTwestinnospam@graphics.cornell.edu (Stephen H. Westin) writes:
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.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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 GMTdon@news.daedalus.co.nz (Don Stokes) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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 GMTalbaugh@agames.com (Mike Albaugh) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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 GMTjcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:
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.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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 GMTjcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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:
The EDX folklore, it was done by a summer intern for a couple physicists doing lab stuff at san jose research.
random other refs:
https://www.garlic.com/~lynn/2000b.html#66
https://www.garlic.com/~lynn/2000b.html#79
https://www.garlic.com/~lynn/2000.html#64
https://www.garlic.com/~lynn/2000.html#71
https://www.garlic.com/~lynn/99.html#63
https://www.garlic.com/~lynn/99.html#66
https://www.garlic.com/~lynn/99.html#67
https://www.garlic.com/~lynn/99.html#69
https://www.garlic.com/~lynn/99.html#70
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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 GMTehrice@his.com (Edward Rice) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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 GMTBrian Inglis writes:
There was some speculation that a lot of SNA was motivated by some work that I had done as an undergraduate.
misc. ref.
https://www.garlic.com/~lynn/93.html#2
https://www.garlic.com/~lynn/95.html#14
https://www.garlic.com/~lynn/2000.html#51
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Question regarding authentication implementation Newsgroups: sci.crypt Date: Sat, 13 May 2000 19:07:03 GMTAbid Farooqui writes:
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:
https://www.garlic.com/~lynn/aadsm3.htm#kiss3
https://www.garlic.com/~lynn/2000b.html#14
https://www.garlic.com/~lynn/draft-wheeler-ipki-aads-01.txt
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
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:
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.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Question regarding authentication implementation Newsgroups: sci.crypt Date: Sun, 14 May 2000 21:11:03 GMTAbid Farooqui writes:
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.
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Question regarding authentication implementation Newsgroups: sci.crypt Date: Sun, 14 May 2000 21:52:32 GMTas 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.
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
https://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2
https://www.garlic.com/~lynn/2000.html#36
https://www.garlic.com/~lynn/2000.html#37
https://www.garlic.com/~lynn/2000.html#39
https://www.garlic.com/~lynn/2000.html#40
https://www.garlic.com/~lynn/2000.html#41
https://www.garlic.com/~lynn/2000.html#42
https://www.garlic.com/~lynn/2000.html#45
https://www.garlic.com/~lynn/2000.html#46
https://www.garlic.com/~lynn/2000.html#47
https://www.garlic.com/~lynn/2000.html#48
https://www.garlic.com/~lynn/2000b.html#40
--
Anne & Lynn Wheeler | lynn@garlic.com
https://www.garlic.com/~lynn/