List of Archived Posts
2000 Newsgroup Postings (3/6 - 5/14)
- "Mainframe" Usage
- "Mainframe" Usage
- "Mainframe" Usage
- "Mainframe" Usage
- "Mainframe" Usage
- ascii to binary
- ascii to binary
- "Mainframe" Usage
- "Mainframe" Usage
- "Mainframe" Usage
- "Mainframe" Usage
- Fairshare scheduling
- Proletarians of the World Wide Web, unite against ICANN!
- Will Radius be obsolute if implement 2-token authentications?
- How many Megaflops and when?
- How many Megaflops and when?
- ooh, a real flamewar :)
- ooh, a real flamewar :)
- Tysons Corner, Virginia
- How many Megaflops and when?
- How many Megaflops and when?
- ooh, a real flamewar :)
- Tysons Corner, Virginia
- How many Megaflops and when?
- How many Megaflops and when?
- S-P-F (was Mainframe operating systems)
- Tysons Corner, Virginia
- Win32 Memory consumption.
- 20th March 2000
- 20th March 2000
- 20th March 2000
- 20th March 2000
- 20th March 2000
- Those who do not learn from history...
- VMS vs. Unix (was: Why are Suns so slow?)
- How to learn assembler language for OS/390 ?
- How to learn assembler language for OS/390 ?
- How to learn assembler language for OS/390 ?
- Why are Suns so slow?
- general questions on SSL certificates
- How to learn assembler language for OS/390 ?
- Why are Suns so slow?
- Migrating pages from a paging device (was Re: removal of paging device)
- 20th March 2000
- OSA-Express Gigabit Ethernet card planning
- Simple authentication protocol: any good?
- Why are Suns so slow?
- How to implement doubly link list with only one pointer ?
- VM (not VMS or Virtual Machine, the IBM sort)
- VM (not VMS or Virtual Machine, the IBM sort)
- VM (not VMS or Virtual Machine, the IBM sort)
- VM (not VMS or Virtual Machine, the IBM sort)
- Digital Certificates-Healthcare Setting
- Multics dual-page-size scheme
- Multics dual-page-size scheme
- South San Jose (was Tysons Corner, Virginia)
- South San Jose (was Tysons Corner, Virginia)
- South San Jose (was Tysons Corner, Virginia)
- 7 layers to a program
- South San Jose (was Tysons Corner, Virginia)
- VM (not VMS or Virtual Machine, the IBM sort)
- VM (not VMS or Virtual Machine, the IBM sort)
- definitions
- oddly portable machines
- oddly portable machines
- oddly portable machines
- looking for December 1974 RFC 675, "Specification of Internet Transmission Control Protocol"
- oddly portable machines
- Maximum Length of an URL
- "Database" term ok for plain files?
- Microsoft boss warns breakup could worsen virus problem
- Scheduling aircraft landings at London Heathrow
- Scheduling aircraft landings at London Heathrow
- BASIC SMTP questions
- Rainbow Series (a hard item to find..)
- write rings
- "Database" term ok for plain files?
- "Database" term ok for plain files?
- write rings
- write rings
- write rings
- write rings
- write rings
- Mainframe power failure (somehow morphed from Re: write rings)
- write rings
- Motorola/Intel Wars
- write rings
- "Database" term ok for plain files?
- Question regarding authentication implementation
- A note on the culture of database
- Question regarding authentication implementation
- Question regarding authentication implementation
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
Marco S Hyman writes:
Not protocol, profile. The real problem with OSI was that it was
too general... there were n ways for doing everything where conformant
implementations could not inter-operate because they used different,
conformant, options.
oops, braincheck & slip of the fingers
U. S. Government Open Systems Interconnection Profile (GOSIP) VERSION 2.0
This is a Federal Government procurement profile for open systems
computer network products. Section 1 contains introductory material,
the purpose and scope of the profile, and the sources of the protocol
specifications contained in the profile. Section 2 contains general
statements on conformance, interoperation and performance of network
systems covered by this profile. Section 3 contains a brief
description of the OSI architecture and protocols that apply to this
profile. The network protocols are specified in section 4, the
principal part of this profile. Accompanying each protocol
implementation reference is a statement of conformance identifying the
required functional units of that protocol. section 5, Addressing
Requirements, is also an integral and mandatory part of this profile.
Technical Support Personnel to Acquisition Authorities must be
familiar with the terminology and ideas expressed in sections 4 and 5.
Section 6 defines security options that, if needed, must be explicitly
requested in Requests For Proposals.
This profile will change with improvements in technology and with the
evolution of network protocol standards. Appendices specify future
work items needed to enrich the profile, and thus, improve its utility
to the agencies.
Both the government and the private sector recognize the need to
develop a set of common data communication protocols based on the
International Organization for Standardization's seven-layer Open
Systems Interconnection (OSI) Basic Reference Model [ISO 1]. In the
past, vendor-specific implementations of data communication protocols
led to isolated domains of information, very difficult and expensive
to bridge. Recent advances in communication technology based on the
OSI model offer alternatives to vendor-specific network solutions.
Most significantly, advances in open systems allow the interoperation
of end systems of different manufacture, when required.
This Government Open Systems Interconnection Profile (GOSIP) is based
on agreements reached at the National Institute of Standards and
Technology (NIST) Workshop for Implementors of Open Systems
Interconnection. Each new version of GOSIP will reference the latest
appropriate version of the Stable Implementation Agreements for Open
Systems Interconnection Protocols [NIST 1], hereafter referred to as
the Workshop Agreements. The Workshop Agreements record stable
implementation agreements of OSI protocols among the organizations
participating in the NIST Workshop for Implementors of OSI.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
another side-subject was trying to get High Speed Protocol definition
thru ANSI/ISO.
Basically anything that violated the 7-layer "rule" got stomped on.
Overview of the OSI model's layers
Physical
Data Link
Network
Transport
Session
Presentation
Application
TCP/IP itself, violates the OSI 7-layer model.
LANs violated the 7-layer model (effectively combining layers 1, 2,
and part of 3 ... i.e. physical, data link, and part of network layer)
into single piece. In some respect, LAN got done by going thru IEEE as
a hardware standard and bypassing the ANSI/ISO networking politics.
HSP effectively would collapse the remaining pieces of 3 (not already
in LANs) and layer 4 (transport) into a single layer; which in the
optimal case would have two layers (LAN & HSP) below session.
HSP attempted to address a number of issues ... including high
thruput, low latency, and transactions. In the transaction relm, HSP
attempted to do a 3-packet exchange reliable protocol (compared to
7-packet minimum exchange for current TCP, and 5-packet minimum
exchange for VMTP/RFC1045).
One of the issues in high thruput was being able to stream/pipeline
data ... packets with (IP) header checksums were a big thing (i.e. you
couldn't send the header out until the full message was processed, its
checksum calculated and the value stuffed in the header ... so needed
intermediate buffering equal to the largest possible message ... or
direct addressing to the original message).
from: rfc1122:
3.2.1.2 Checksum: RFC-791 Section 3.1
A host MUST verify the IP header checksum on every received
datagram and silently discard every datagram that has a bad
checksum.
========
these days, LANs, modems, adapters, etc ... most transmission
methodologies all have extensive built-in error detecting & even
forward error correction.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Mainframe" Usage
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 07 Mar 2000 01:29:26 GMT
don@news.daedalus.co.nz (Don Stokes) writes:
I don't understand. The IP header checksum just sums the header.
Network layer devices only need to check 20 bytes of header to make sure
the packet doesn't turn left instead of right before starting to put the
thing on the wire for its next hop. It's up to the transport layer
protocol to sort out whether the payload actually arrived with the
header when it gets to its final destination
I'm sorry slipped up and met tcp checksum not ip checksum and quoted
the wrong reference.
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]
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
don@news.daedalus.co.nz (Don Stokes) writes:
>Physical
>Data Link
>Network
>Transport
>Session
>Presentation
>Application
>
>TCP/IP itself, violates the OSI 7-layer model.
Huh? Last time I looked, IP slotted exactly into the Network layer,
and TCP into Transport.
by definition IP is the internetworking layer ... not the network
layer (fitting between layers 3 & 4) ... although the semantics of the
TCP<->IP interchange appears similar to a l4<->l3 semantics.
IP is designed to fit between network layer and transport layer and
provide an additional network abstraction (not provided for in the OSI
model).
misc. other refs.
IEN32
IEN111
IEN166
... from ien111:
For example, a TCP module would call on the internet module to take a
TCP segment (including the TCP header and user data) as the data
portion of an internet datagram. The TCP module would provide the
addresses and other parameters in the internet header to the internet
module as arguments of the call. The internet module would then
create an internet datagram and call on the local network interface to
transmit the internet datagram.
===============
which places IP above the network layer ... but below the transport
layer. In the case of LAN network, the IP module would call the LAN
network interface ... which would prefix a LAN network header in front
of the IP internet header (which had been prefixed in front of the TCP
transport header)
random references:
http://www.garlic.com/~lynn/99.html#37b
http://www.garlic.com/~lynn/99.html#38b
http://www.garlic.com/~lynn/99.html#38d
in the diagram taken from IEN-166 at:
http://www.garlic.com/~lynn/2000.html#72
The transport TCP intefaced to the internet IP layer
The internet IP layer interfaced to the network 1822/IMP layer
The network 1822/IMP layer (actually IMP) handled the data link &
physical layer.
In the case of LANs today
THe transport TCP layer interface to the internet IP layer (& the
internet ip layer adds a IP header in front of the TCP header)
The internet IP layer interface to the network LAN layer (& the
network LAN layer adds a network header in front of the internet
IP header)
The network LAN layer then handles the two lower levels.
In the case of most point-to-point links
The transport TCP layer interface to the internet IP layer (& the
internet ip layer adds a IP header in front of the TCP header)
The internet IP layer interface ot the network PPP layer (& the
network PPP layer adds a network header in front of the internet
IP header)
The network PPP layer then handles the two lower levels.
Four layer TCP/IP would looks something like
1 physical/data link (osi 1&2)
2 network layer (osi 3)
3 IP/internet layer (osi ???)
4 transport TCP layer (osi 4)
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
don@news.daedalus.co.nz (Don Stokes) writes
OK, I see the point, although I don't see it as being much of an issue.
It would be an issue if the TCP checksum computation was in hardware:
you could assemble the packet in a buffer and submit it to the output
device with a flag saying "compute TCP checksum please" (or even "do TCP
stuff with this", and if the checksums were trailing instead of in the
header, that could be done as the packet was clocked onto the wire.
misc. references:
http://www.3com.com/technology/tech_net/white_papers/503003.html
CPU Utilization at Gigabit Speeds
At gigabit speeds, routine networking tasks such as TCP/IP checksum
calculations can easily tie up the processor, resulting in 100 percent
CPU utilization. This leaves no processing power for running other
applications. Therefore, well-designed Gigabit Ethernet NICs offload
such tasks from the host processor, performing them in the NIC
hardware. These Gigabit Ethernet NICs also consolidate interrupts,
interrupting the CPU less frequently and for multiple tasks each
time. This reduces the number of times the processor has to save
context to service interrupts, and results in lower CPU utilization
for better application performance.
====================
the following from:
http://www.dec.com/info/DTJS05/
http://www.digital.com/info/DTJS05/DTJS05SC.TXT
A traditional system follows the networking subsystem model
implemented within the BSD releases of UNIX, shown in Figure 2. An
application uses the CPU to create data (1), the socket portion of the
system call interface copies the data into operating system buffers (2
and 3), the network transport protocol checksums the data for error
detection purposes (4), and the device driver uses programmed
input/output (I/O) or direct memory access (DMA) to move the data to
the network (5). Graphs showing the dominant costs of checksumming and
kernel buffer copies are presented in Reference 6.
===================
misc. references from around the net on HSP issues
http://www-tkn.ee.tu-berlin.de/html/lehre/bla/tcp_hs.html
http://www.cis.ohio-state.edu/~jain/cis788-95/transport/index.html
http://www.cs.umd.edu/~pravin/presentations/splice-talk/Splice-Talkl17.htm
http://www.ca.sandia.gov/xtp/xtpintro.html
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ascii to binary
Newsgroups: sci.crypt
Date: Tue, 07 Mar 2000 06:01:07 GMT
John Wingate writes:
I have a stack of blank cards too. (They make good bookmarks.) Only
10 rows are labeled, but 12 rows were used for punching. CDC binary
files were punched with each 60-bit word taking up five columns--
16 words per card.
discussed sporadically on alt.folklore.computers.
709/709x/1401/etc binary could have all 12x80 holes punched & used BCD
for character codes. with 360s & ebcdic (a superset of bcd)
... allowed for 256 codes (8bit bytes, four? holes per column was the
most used & would generate hardware errors for columns with invalid
hole combinations, my green card is in storage).
360s could interface to card reader/punch using something called
column binary for processing 709/709x/1401/etc binary cards using
160bytes ... effectively each column had pairs of 6bit codes mapped to
pairs of 360 (8bit) bytes
table that use to give punch codes:
http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/DZ9AR004/I%2e0
random reference:
http://users.ticnet.com/davea/greencard/start.htm
http://www.cwi.nl/people/dik/english/codes/80col.html
http://tronweb.super-nova.co.jp/characcodehist.html
http://www.fourmilab.ch/documents/univac/fieldata.html
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ascii to binary
Newsgroups: sci.crypt,alt.folklore.computers
Date: Tue, 07 Mar 2000 06:53:35 GMT
... oops, a little too quick on the send.
url with complete bcd & ebcdic card codes (26key punch, 29key punch)
http://www.cs.uiowa.edu/~jones/cards/codes.html
it also has proprietary 026 varients by control data, dec, GE, &
univac
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
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 GMT
Floyd Davidson writes:
The OSI 7-layer _model_ is just that, a model. It does not define
seven protocol layers, it defines seven sets of functional concepts
that exist in the provision of network services.
The TCP/IP protocol _architecture_ does not "violate" the OSI
model. It is a set of protocols. The functionality of that set
can be described in various ways, some of which conveniently use
3 layers, 4 layers, or 5 layers.
the discussion started out that the ISO&ANSI networking standards
bodies (responsible for the OSI model) in the 80s and early 90s didn't
care for protocol implementations that didn't exactly
implement/correspond to the OSI 7 layer model ... trying to do HSP
which collapsed layers 3&4 into single layer was objected to by the
members of the standards bodies because it didn't exactly
implement/preserve/correspond to OSI layers (aka they asserted that
HSP violated OSI model).
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
don@news.daedalus.co.nz (Don Stokes) writes:
True, but there's nothing stopping the card from doing the TCP checksum
and putting it in the buffered header before starting to clock the
packet onto the wire. That solves the CPU time time problem without
needing trailing checksums. The checksum still needs to be computed.
that is also what the gigabit testbed final report stated (circa '96)
http://www.cnri.reston.va.us/gigafr/noframes/section-4-16.htm
basically asserting that the extra memory was reasonable trade-off
given the problem of changing installed TCP implementations to support
trailer checksums.
however, the discussion started out as to what issues was HSP trying
to address. HSP wouldn't have the trade-offs of implementations
already in the field. The issue for HSP was did the aggregate benefit
from HSP justify the new protocol.
some HSP issues
more efficient checksum processing
better congestion control & pacing
possibly zero data copies, pipelining from transport interface
directly into protocol engine
easier use of larger MTUs
3 packet minimum exchange (compared to TCP 7 packet minimum exchange,
improved latency
reliable multicast
more efficient error handling
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
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 GMT
Floyd Davidson writes:
Virtually nobody, except with the OSI protocol suite, has
followed it. And of course TCP/IP which predates the OSI
7-layer model has become the protocol of choice, which
emphasizes the OSI effort's value as the model and not the
protocol suite.
i also would sometimes needle in ANSI/ISO meetings that IETF at least
required a sanity check in the form two interoperable models for
standardization candidates ...
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
don@news.daedalus.co.nz (Don Stokes) writes:
Which can be "solved" by the simple expedient of keeping the TCP session
opening and closing procedures out of the critical path, ie by opening
a TCP session at the start of an operation and leaving it open until
finished. This is an issue for much more than high-speed comms; with
slow-start congestion control, multiple small TCP connections perform
really badly in high latency environments[1]. Protocols like HTTP already
use persistent connections for this reason.
(Living in .nz means you get to notice things like this -- simple
physics tells you that the minimum round-trip time to the US from here
is >100 ms, and that's without taking other ugly real-world factors into
account, not the least of them being that the terrestrial cables into
the country are full -- 100 x bandwidth improvement due in September ...
8-)
-- don
slow-start in typical bursty real-world is also non-stable. I think
there was a paper in SIGCOMM proceedings giving details (this shortly
after some slow-start became available .. 89 or 89 ... they are in
storage at the moment) ... it was just better than nothing.
we had run into similar problem using any sort of windowing based
infrastructure in high-speed real-world bursty environment in the
mid-80s and had gone to rate-based pacing (not only needing to react
to changes in congestion but also that ACKs can clump on the return
and all of a sudden you have all of your buffers wide open).
while long-lived HTTP gives some better prediction of pending
activity ... it is also prone to non-stable slow start.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Fairshare scheduling
Newsgroups: comp.programming,comp.programming.threads
Date: Sat, 11 Mar 2000 20:10:54 GMT
Justin Liew writes:
Anyone have any idea what a fairshare scheduling regime is? I've
searched the Net and newsgroups, but have come up short. Are there any
links or textbooks that describe this?
Thanks,
J
random references from old & not so old newsgroup postings ....
http://www.garlic.com/~lynn/93.html#5
http://www.garlic.com/~lynn/93.html#23
http://www.garlic.com/~lynn/93.html#31
http://www.garlic.com/~lynn/94.html#2
http://www.garlic.com/~lynn/94.html#3
http://www.garlic.com/~lynn/94.html#4
http://www.garlic.com/~lynn/94.html#5
http://www.garlic.com/~lynn/2000.html#86
http://www.garlic.com/~lynn/2000.html#92
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Proletarians of the World Wide Web, unite against ICANN!
Newsgroups: alt.culture.internet,alt.folklore.computers,alt.internet.media-coverage
Date: Fri, 17 Mar 2000 04:15:53 GMT
jmfbahciv writes:
Lookup anything that she posted in this newsgroup
(alt.folklore.computers) throughout the last five years. And
I'm saying five years because that only how long I've been
on-line. If she posted before that, I'm sure people tried
to correct her reality filter. I have often (actually, it's
probably more like _always_) told her to go read the old
specs, proposals, etc. which she never does.
ditto
random URL
http://www.garlic.com/~lynn/internet.htm
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
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:
hi
My current setup includes Cisco PIX and CiscoSecure for AAA. We use basic
userid and password for authentication. The Radius get the userinfo from
Windows NT domain.
We are going to implement 2-token authentication such as RSA SecurID or
certificate based smart-card. Will the token based authentication make the
CiscoSecure redundant?
Thanks
there have been AADS upgrades to radius where the userinfo/password is
optionally a public key and authentication is via digital signatures
using an AADS smartcard.
random refs:
http://www.garlic.com/~lynn/99.html#217
http://www.garlic.com/~lynn/99.html#224
http://www.garlic.com/~lynn/aadsm2.htm#straw
http://lists.commerce.net/archives/ansi-epay/199912/msg00008.html
there have also been demos of webserver upgrades to utilize radius
protocol in a similar manner (in place of ROI userid/password for web
site authentication).
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many Megaflops and when?
Newsgroups: alt.folklore.computers
Date: Fri, 17 Mar 2000 19:25:25 GMT
cronology of machines ... 6600 63/08 ann, 64/09 first customer ship
http://www.isham-research.freeserve.co.uk/chrono.txt
some references to 360/91 (1967)
http://emess.mscd.edu/~csi3060/Tomasulo/tsld002.htm
http://www.cs.herts.ac.uk/~comrrdp/pipeline/p_4_4.html
parallel computing reference
http://ei.cs.vt.edu/~history/Parallel.html
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many Megaflops and when?
Newsgroups: alt.folklore.computers
Date: Sun, 19 Mar 2000 07:31:14 GMT
dpeschel@sumatra.cs.washington.edu (Derek Peschel) writes:
The I/O controllers on both CDC and IBM machines are (were?) reprogrammable.
On the CDC controllers, I think the instruction set was Turing-complete.
The IBM controllers have a more limited instruction set (I'm not sure if it
is Turing-complete or not).
Granted, no sane person would reprogram them normally (or had the privileges)
but it could be done.
misc. ref:
http://www.garlic.com/~lynn/96.html#4
http://www.garlic.com/~lynn/96.html#5
http://www.garlic.com/~lynn/2000.html#9
http://www.garlic.com/~lynn/2000.html#16
http://www.garlic.com/~lynn/2000.html#17
http://www.garlic.com/~lynn/93.html#16
http://www.garlic.com/~lynn/94.html#15
http://www.garlic.com/~lynn/94.html#33a
http://www.garlic.com/~lynn/95.html#3
http://www.garlic.com/~lynn/95.html#14
http://www.garlic.com/~lynn/96.html#18
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
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 GMT
i asserted starting back around '89 that a large portion of the
exploits were symptomatic of C convention of null terminated implicit
lengths ... contributing to large number of buffer overrun scenerios
(which continues today).
I also believe that somewhere in the early '90s there was report &/or
press release from the austin tandem labs about contributing changes
back to the system V base a set of changes that were specifically
reliability oriented (including hundreds ... if not thousands of
panics removed from the kernel, etc).
misc. refs
http://www.garlic.com/~lynn/99.html#30
http://www.garlic.com/~lynn/99.html#85
http://www.garlic.com/~lynn/99.html#163
http://www.garlic.com/~lynn/99.html#219
http://www.garlic.com/~lynn/2000.html#25
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ooh, a real flamewar :)
Newsgroups: alt.folklore.computers,comp.unix.advocacy
Date: Sun, 19 Mar 2000 18:32:04 GMT
identifying and removing panics isn't necessarily trivially
straight forward
some of the panics are things like hard disk errors ... so to pull the
panic wasn't just a matter of removing the panic ... but replacing it
with some detailed error recovery logic
other panics may be recognizable memory pointer problems ... which if
system were left running might result in propagating the error into
things like file system corruption &/or other integrity problems.
frequently the error & failure recovery logic ... can be four times
as much code as the base non-recovery code.
random refs (including pieces of 'mainframe & unix' thread from '96 &
"OSes commercial, history" thread from 97 ... both in comp.arch)
http://www.garlic.com/~lynn/93.html#28
http://www.garlic.com/~lynn/94.html#00
http://www.garlic.com/~lynn/94.html#16
http://www.garlic.com/~lynn/94.html#33a
http://www.garlic.com/~lynn/94.html#44
http://www.garlic.com/~lynn/95.html#1
http://www.garlic.com/~lynn/96.html#18
http://www.garlic.com/~lynn/96.html#27
http://www.garlic.com/~lynn/96.html#28
http://www.garlic.com/~lynn/96.html#31
http://www.garlic.com/~lynn/96.html#32
http://www.garlic.com/~lynn/96.html#33
http://www.garlic.com/~lynn/96.html#41
http://www.garlic.com/~lynn/97.html#11
http://www.garlic.com/~lynn/97.html#12
http://www.garlic.com/~lynn/97.html#13
http://www.garlic.com/~lynn/97.html#14
http://www.garlic.com/~lynn/97.html#15
http://www.garlic.com/~lynn/99.html#16
http://www.garlic.com/~lynn/99.html#17
http://www.garlic.com/~lynn/99.html#31
http://www.garlic.com/~lynn/99.html#47
http://www.garlic.com/~lynn/99.html#49
http://www.garlic.com/~lynn/99.html#53
http://www.garlic.com/~lynn/99.html#71
http://www.garlic.com/~lynn/2000.html#21
http://www.garlic.com/~lynn/2000.html#22
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tysons Corner, Virginia
Newsgroups: alt.folklore.computers
Date: Sun, 19 Mar 2000 19:48:29 GMT
my wife did tour thru SBS late 70s and came back when it was turned
over to MCI. Building was (essentially) across the back parking lot of
the best western (which faces on turnpike/7). MCI unloaded the bldg.
and now occupied by BAH ... which built a matching bldg slightly
downhill and put in a lobby/auditorium between the two.
had an array of dishes on top of the bldg. for quite some time.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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:
If it weren't for the VS/1 and ACP systems, we could have got by on 1 or 2
Megabytes, easy. And this was on a 1/2 MIPS CPU engine. Response times were
excellant, all sub 1/10 second for full-screen channel attached terminals.
Gerard S.
there was a (internal) symposium held at tower bridge marriott about
'71. harlen mills talked about super programmer.
there was a human response paper on response time & people's
perception. Study of large body of people showed a distribution of
what people could perceive ... between about .25 seconds and .10
seconds i.e. what threshold could they not decern different in
response times ... for some the threshold was .25 seconds (they didn't
notice the difference between .25seconds and .24 seconds). For some
the threshold was as low as .10 seconds (i.e. would notice the
difference between .11 seconds and .10 seconds).
Another study indicated that unexpected delays in response had a
downside doubling of impact on productivity. If person was expecting a
one second response ... and it was actually 2 seconds ... the person's
attention would effectively start wandering and there would be a delay
in the person refocusing their attention (delay approximately
proportional between the difference between the actual response and
the expected response). An unexpected 1 second delay in response
actually resulted in a 2 second impact on productivity.
random refs:
http://www.garlic.com/~lynn/93.html#0
http://www.garlic.com/~lynn/93.html#31
http://www.garlic.com/~lynn/98.html#46
in the above "Big I/O or Kicking the Mainframe out the Door"
response was for 90th percentile and for large mix-mode workload ..
users doing complex combination of trivial interactive as well as
compile, test, and various batch work.
in the following (acp/tpf related):
http://www.garlic.com/~lynn/2000.html#61
infrastructure had >100,000 terminals & displays w/nominal workload
generating 3500-4000 I/O interrupts/second (120,000/min)
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How many Megaflops and when?
Newsgroups: alt.folklore.computers
Date: Sun, 19 Mar 2000 20:17:01 GMT
Anne & Lynn Wheeler writes:
infrastructure had >100,000 terminals & displays w/nominal workload
generating 3500-4000 I/O interrupts/second (120,000/min)
the I/O interrupt rate was just for the communication devices,
terminals, and displays ... didn't include any of the disks or other
system devices.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
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:
There is absolutely _nothing_ in the "C" language that makes the
production of robust software "unthinkable" any more than it's not
possible to write decent code in assembler, COBOL, ADA, or whatever
other language one chooses to write in. The attention to detail is
the important bit, _not_ the language one writes in.
i've claim that the C convention of null-terminated strings obscured
the requirement for explicitly handling lengths and has lead to large
percentage of infrastructure exploits (buffer overrun/overflow). The
frequency of problems is significantly higher compared to evironments
w/conventions requiring explicit length handling.
... from some quote ... in theory there is no difference between
theory and practice ... but in practice there is.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tysons Corner, Virginia
Newsgroups: alt.folklore.computers
Date: Sun, 19 Mar 2000 22:37:47 GMT
Paul 125 writes:
OK, I know what MCI, PRC, and even AAA stand for..., but please help:
SBS? and BAH? Thanks in advance.
SBS ... satellite business systems, equally owned by IBM, Comsat, and
Aetna ... before various pieces sold off to MCI, Hughes, etc.
BAH ... Booz, Allen, Hamilton
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
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 GMT
Anne & Lynn Wheeler writes:
there was a (internal) symposium held at tower bridge marriott about
'71. harlen mills talked about super programmer.
oops, finger check .. that was key bridge marriott not tower bridge.
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.
Refed: **, - **, - **, - **, - **, - **
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 GMT
jvarela@nospam.com (John Varela) writes:
The original Marriott was a lunchroom called the Hot Shoppe that
became a Washington-area chain. I think the original Marriott motel
was the one that used to be at the Virginia end of the 14th Street
Bridge, near the Pentagon between (what is now) I-395 and the
railroad. It disappeared sometime in the 70s or early 80s I'm not
sure why. I stayed there in 1973. The Key Bridge Marriott is also
quite old -- I recall having lunch there in 1961 or 62 -- and is still
there much modified over the years.
now that you mentioned it ... the 14th street bridge marriott was
probably where the conference in '71 was also.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S-P-F (was Mainframe operating systems)
Newsgroups: bit.listserv.ibm-main
Date: Mon, 20 Mar 2000 03:23:53 GMT
Allan Beatty writes:
Skip Robinson wrote:
> 'Structured Programming Facility' was an poignant example of riding the
> buzzword band wagon. Structured Programming was a favorite hot button in
> the late 70s. As much as I've always loved the product, I never could see
> how it contributed much in the way structure to an amorphous program.
As I recall from 20 years ago, the "structured programming"
aspect meant that there were indent commands, and you could
suppress groups of lines from displaying in order to show your
DO and ENDDO next to each other.
--
Allan Beatty
allan dot beatty at donnelley dot infousa dot com
how 'bout the big "goto-less" thing and super programmer also.
slightly related:
http://www.garlic.com/~lynn/2000b.html#20
http://www.garlic.com/~lynn/2000b.html#24
http://www.garlic.com/~lynn/2000b.html#25
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tysons Corner, Virginia
Newsgroups: alt.folklore.computers
Date: Tue, 21 Mar 2000 13:48:01 GMT
we had transponders on SBS4 for research activities with privision
we could get pre-empted for things like special TV coverage. we got
hit for things like the pope's visit to denver (circa '86?, 87?)
... and were out for 3 days on that one. Did get invited to the VIP
stands for SBS4's launch.
was part of the backbone we operated ... with clear-channel T1s and
some fiber links.
random references:
http://www.garlic.com/~lynn/internet.htm
http://www.garlic.com/~lynn/94.html#33b
and link haven't check recently
http://www.ksc.nasa.gov/shuttle/missions/41-d/mission-41-d.html
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 debuged) ... DES encrypted satellite T3 TDMA channel (i.e. 20
or so TDMA earth stations sharing/multiplexing both uplink and
downlink ... real bear .. since different stations injected packets
into the uplink packet flow ... and different stations were targeted
for the downlink dataflow.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Win32 Memory consumption.
Newsgroups: netscape.public.mozilla.general
Date: Sat, 25 Mar 2000 18:00:27 GMT
on nt4 running netscape 7.2 and then click on 12 different URLs
opening them all in different windows ... and it adds about 4mbytes to
my memory consumption.
running mozilla 14 and then click on the same 12 URLs opening them all
in different windows ... and it adds about 28mbytes to my memory
consumption.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
Mike Cowlishaw writes:
Today is a special day for Rexx. The language "comes of age", being 21
today.
Very many thanks to everyone who has used, implemented, and supported
it, and for all the many kind words and feedback about it over the
years!
Mike Cowlishaw
IBM Fellow
not quite 21 ... but >20 years; earliest reference that I stumble across.
Tuesday, February 26, 1980:
9:00 - W.W. Eggleston - VM/370 ITE Kickoff, Mr. Eggleston is the
President of GPD.
9:30 - Ray Holland - ITE Overview.
9:45 - Forrest Garnett - Dynamic Writable Shared Segment Overview.
10:00 - Jim Gray - System R , An Overview.
10:30 - Break
11:00 - Gene Svenson - Extended Networking.
11:30 - Roy Engehausen - Network management and load balancing tools.
12:00 - Lunch
1:00 - Peter Rocker - Network Response monitoning, Remote Dial
Support, and VM/370 HyperChannel attachment
1:20 - Jeff Barber - CADCOM - Series/1 to VM/370 inter-program
communications.
1:35 - Noah Mendelson - PVM - Pass Through Virtual Machine Facility.
2:00 - Noah Mendelson - EDX on Series/1 as a VNET work station.
2:15 - Tom Heald - Clock - Timer Driven CMS Virtual Machine.
2:30 - Break
3:00 - Vern Skinner - 3540 Diskett Read/Write Support in CMS.
3:30 - Bobby Lie - VM/SP - System Product offering overview
and discussion.
4:30 - Closing - From this point on there can be small
informal sessions of points of interest.
Wednesday, February 27, 1980:
9:00 - Billie Smith - Common System Plans.
modifications and results.
9:30 - Claude Hans - XEDIT Update.
Nagib Badre
10:00 - Graham Pursey - SNATAM - Controlling SNA devices from CMS.
10:30 - Break
11:00 - Mike Cowlishaw - REX Executor.
11:45 - Mark Brown - San Jose File Back-up System.
12:00 - Lunch
1:00 - Albert Hafner - VMBARS - VM/370 Backup and Retrieval System.
1:45 - Chris Bishoff - 6670 Office System Printer and VM/370
Tom Hutton
2:15 - Break
2:45 - Rodger Bailey - VM/370 Based Publication System.
3:15 - Dieter Paris - Photo-composition Support in DCF
3:30 - John Howard - VM Emulator Extensions.
Dave Fritz
3:40 - Tom Nilson - DPPG Interavtive Strategy and VM/CMS.
4:30 - Closing - From this point on there can be small
informal sessions of points of interest.
4:30 - Editor Authors - This will be an informal exchange of
information on the changes comming and
any input from users on edit concepts.
All those wishing to express their opinions
should attend.
Thursday, February 28, 1980:
9:00 - Ed Hahn - VM/370 Mulit-Drop Support
9:30 - Ann Jones - Individual Password System for VM/370.
10:00 - Walt Daniels - Individual Computing based on EM/YMS.
10:30 - Break
11:00 - Chris Stephenson - EM/370 - Extended Machine 370 and EM/YMS
Extended Machine Yorktown Monitor System.
12:00 - Lunch
1:00 - Simon Nash - Extended CMS Performance Monitoring Facility
1:30 - George McQuilken - Distributed Processing Maching Controls.
2:00 - Mike Cassily - Planned Security Extensions to VM/370 at
the Cambridge Scientific Center
2:30 - Break
3:00 - Steve Pittman - Intra Virtual Machine Synchronization
Enqueue/Dequeue Mechanisms.
3:30 - Jeff Hill - Boulder F.E. Source Library Control System.
4:00 - Ray Holland - VMITE Closing.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
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 GMT
John Ferrell writes:
No offense intended, but since it is Mike's creation I believe I will take his
numbers to be the correct ones.
???
I never made any statement about mike's dates being incorrect (&/or
intended that such a thing would be implied)
I just posted the earliest reference I could find on rex/rexx.
There is implication that since the reference was a talk about
rex/rexx that rex/rexx should have predated the talk (i.e. it was in
existance before the date of the talk)
If you have a early rex/rexx reference maybe you would care to share
it?
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
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 GMT
i.e. reference to "not quite 21" had nothing at all to do with Mike's
comment about the age of rex/rexx ... it had to do with the antiquity
of the reference that I stumbled across.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
another early rex reference:
http://www.garlic.com/~lynn/94.html#11
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"
Since I still had almost a month left on the product ... I produced
nearly another 800 lines of REXX code that implemented
expert-system-like analysis of postmortem storage images.
It became relatively successful ... although never released to
customers as a product. I directly distributed the application to over
100 internal locations world-wide and at least at one time was in use
by all internal locations as well as all (VM) field service people.
In support of this, I also made a minor modification to CP kernel to
maintain symbol entry-point table. The "standard" DUMPSCAN process was
to merge a "saved" loadmap (generated when the kernel was built) with
the dump storage image.
The CP kernel build process (not really changed since 1967) was to use
the "BPS" loader to load into memory all the kernel binaries. Then a
kernel application would receive control from the BPS-loader and write
the storage-image to a special disk boot-location.
In 1969, I was started playing around with some enhancements to the CP
kernel to allow part of it to be "unpinned" and allow it to page. As
part of this I also modified the boot-build routine. When the
BPS-loader exits to the loaded program, it passes the address of the
loader symbol table as well as the count of entries in the table. The
modification I made to the boot-build routine was to copy the the
BPS-loader symbol table to the end of the kernel core image and write
it out as part of the boot-image. Since it was located in the
"pageable", unpinned portion of the kernel it wasn't going to take up
runtime storage (there were some 360/67s out there that only had
512kbytes of real storage ... fixed kernel size was becoming
critical).
In any case, I went back and resurrected the 1969 modifications and
re-applied them to the '82 cp kernel (appending the BPS-loader symbol
table to the end of the CP kernel boot-image). I then added the
appropriate switch to DUMPRX to utilize the real symbol table if
available. This eliminated the problem of getting entry symbols from a
"load-map" that didn't match the boot-file..
--
+-+-+-+
Lynn Wheeler | lynn@netcom.com, lhw@well.sf.ca.us
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
Anne & Lynn Wheeler writes:
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.
date misquote ... should have been '81 ... i.e.
"In early spring of 1981, the first release of DUMPRX was made
available and also some of the ideas and aspects of the technology
were discussed at a SHARE BOF."
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Those who do not learn from history...
Newsgroups: alt.folklore.computers
Date: Thu, 30 Mar 2000 08:29:49 GMT
kfl@saltmine.radix.net (Keith F. Lynch) writes:
That doesn't sound like a newsgroup name. Not even before the great
renaming. I've been online since the 70s, but the first mention I
saw of the year 2000 bug was in January 1988. Not to say that NOBODY
mentioned it before then, but even if anyone did, there certainly
wasn't enough discussion to inspire creation of a newsgroup.
it wasn't a usenet newsgroup ....... it was an internal discussion
group on the internet network.. random references
http://www.garlic.com/~lynn/99.html#112
http://www.garlic.com/~lynn/99.html#7
http://www.garlic.com/~lynn/99.html#38c
http://www.garlic.com/~lynn/2000.html#1
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
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
An IBM PC may have cost more than an Apple product, but IBM's entry into the
PC market was the impetus for the lower priced clones.
at the time, the major market was the commercial/business
market. hobbyist and consumer was interesting ... but the
commercial/business market was significantly larger (at the time). A
combination of mainframe terminal emulation and various business
applications on the ibm/pc allowed a single box to be deployed on
desks for both functions. Office desk space is typically rather scarce
... putting both a mainframe dumb terminal and a separate PC on office
desk wasn't a practical option in most cases (both space wise and cost
wise). That was somewhat independent of using the IBM name to sell
directly into the lower-end PC business market (not involving
mainframe dumb terminal upgrade).
The size of the mainframe dumb terminal "upgrade" market (coupled with
the rest of the PC business market) made it possible to get the
volumes that could drive down the manufacturing costs and make it
interesting for clones to enter the market. From that point there was
positive feedback with further cost competition opening new market
segments as well as attracting both new manufactures as well as
software developers. This eventually spilled into the consumer and
home market.
misc. ref:
http://www.garlic.com/~lynn/2000.html#6
http://www.garlic.com/~lynn/99.html#28
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
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 GMT
Ed.Long@FMR.COM (Long, Ed) writes:
I had a similar experience with a 370/145 that had 3rd party memory (CMS).
The fan failed, the boards and insulation overheated, and the room became a
smoke house. The machine was essentially replaced in its entirety.
IBM used closed loop liquid cooling with heat exchange unit and
thermal sensors (standard cooling systems tended to be pretty impure
and do things like leave deposits and clog up lines). one site lost
liquid flow on the outboard/building side of the cooling
infrastructure. Unfortunately the mass of liquid on the inboard side
wasn't sufficient to cover the shutdown cycle ... the thermal sensors
noticed the temperture starting to rise and shutdown the power
... however the amount of heat in the system continued to drive up the
temperature until all the TCMs fried. IBM replaced all the TCMs in the
machine and also starting installing flow sensors on the outboard side
of the cooling infrastructure that would also trip power shutdown.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
glass2 writes:
If my memory is correct, S/370-model 145 machines did not use TCMs. The
TCMs were introduced on the 308x machines (and, were one of the reasons
for the existance of the 303x machines).
the lower end machines were air-cooled, 145, 148, 4341, 4381 ... etc
... although the 4381 introduced some (miniture) cooling towers.
the high end machines were water cooled (or at least had heat exhange
unit with water on the outboard side). Later machines used TCMs
(thermal conduction modules) to improve heat transfer. They were solid
blocks inclosing the components and holes drilled thru the blocks with
connectors to flow fluid thru the blocks.
random refs:
http://www-mae.engr.ucf.edu/~jtt/heat_transfer.htm
http://domino.int-evry.fr/IntranetDSI/EuroFret/ibm3090.htm
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
possibly cornell university ... (the requirement for flow sensor on
the out-board side of the heat exchanger may have shown up in some
earlier scenerios)
another TCM story was that target on the 3081 (or 3090?) was going to
be (I believe) six TCMs but it was beginning to look like they would
have to add an extra one for addition channel I/O processing.
the problem was the 3880 control unit ... while the 3880 introduced
data streaming and 3mbyte/sec channel capacity (i.e. instead of
channel/controller handshake on every byte transferred it could
transfer 8bytes per handshake ... also allowed doubling the length on
the bus&tag cables).
The problem is that 3830->3880 went from a fast horizontal mcode
processor to relatively slow vertical mcode jib-prime processor
... with data-path bypass (i.e. control ops went thru jib-prime but
data & control data paths were done separate). The problem was that
the 3880 control processing significantly increased the "channel busy"
time associated with control operations ... enuf so that it would
significantly degrade the aggregate data transfer thruput into & out
of the processor complex (compared to 3830 controller, even with the
change from 3330 disk drives to 3830 3mbyte/sec disk drives).
to maintain aggregate processing thruput required increasing channels
which translated into increase in the number of TCMs ... which were
the major expense factor in the processor complex.
we had seen something analogous earlier in several complexes where we
remoted all the "channel-attached" displays behind HYPERChannel
channel extenders. In much of the '70s had display controllers
intermixed on same channels with disk controllers. The display
controllers also had expensive channel busy control operations
... that implied blocking/delaying disk control access. The internal
HYPERChannel project remoted all the display controllers using local
HYPERChannel (A220) controllers on the processor channels and remote
HYPERChannel (A51x) 370 channel simulators. The A220/A51x processing
was asynchronous allowing local A220 to burst the direct mainframe
channel activity. Just remoting the display controllers (significantly
reducing local channel busy & disk controller interference) resulted
in 10-15% overall aggregate system thruput.
random refs:
http://www.garlic.com/~lynn/94.html#23
http://www.garlic.com/~lynn/94.html#24
http://www.garlic.com/~lynn/96.html#18
http://www.garlic.com/~lynn/96.html#19
http://www.garlic.com/~lynn/2000.html#16
http://www.garlic.com/~lynn/96.html#27
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why are Suns so slow?
Newsgroups: comp.sys.intel,comp.arch,comp.sys.sun.misc
Date: Thu, 30 Mar 2000 21:09:15 GMT
wbe @[ubeblock ]psr.com (Winston Edmond) writes:
It was called "partial matching" -- as long as you typed enough
characters to uniquely identify the command, you didn't have to type the
rest. You could type as many or as few characters as you liked (as long as
it was "enough"). Andy is right that this was not the same as synonyms /
aliases. "Aliases" don't require the alias name and value have anything in
common; e.g. "ls" --> "dir".
but it was the same table/command ... there was a "system" table with
the default values ... but the user could specify a user specific
table which supported both aliases/synonyms and minimum characters.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
kilgallen@eisner.decus.org (Larry Kilgallen) writes:
The big difference about SET is not the certificate format but
rather the protocols used. Simply put, with SET the merchant
cannot learn the credit card number of the customer, but does
get cryptographic assurance that the transaction will be honored.
actually this has been argued both ways ... however the merchant needs
to keep a record of the credit card number after the transaction has
executed ... since there are various business processes that rely on
the merchant having that number.
The consumer encrypts the credit card number under the payment gateway
key ... and sends it to the merchant .. who forwards it to the payment
gateway. For a valid merchant/transaction, the payment gateway echos
the number back to the merchant in the transaction response (where
it goes into the merchant database of credit card numbers).
Also, SET is sensitive to the privacy issues ... not identifying the
certificate owner ... just carrying the bare minimum for having some
account. This somewhat falls into the category of relying-party-only
certificates ... because of both liability & privacy issues.
random other references at
http://www.garlic.com/~lynn/
http://www.garlic.com/~lynn/ansiepay.htm#theory
http://www.garlic.com/~lynn/aepay3.htm#sslset1
http://www.garlic.com/~lynn/aepay3.htm#sslset2
http://www.garlic.com/~lynn/aepay2.htm#aadspriv
http://www.garlic.com/~lynn/aepay2.htm#privrules
http://www.garlic.com/~lynn/aadsmail.htm#comfort
http://www.garlic.com/~lynn/ansiepay.htm#privacy
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
I used 2321 as undergraduate ... we had ONR grant at the university
library and had 2321 data cell and was one of the original CICS
beta-test sites. Had problems in both 2321 and CICS.
never worked on the 2321 later ... but worked with some of the
engineers that had been responsible for the 2321.
random references:
http://www.garlic.com/~lynn/2000.html#9
http://www.garlic.com/~lynn/94.html#33
http://www.garlic.com/~lynn/96.html#9
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
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 GMT
DONT.qed.SPAM.ME@pobox.com (Paul Hsieh) writes:
Well, Lotus became the first "killer app", which made the PC more
attractive for people who wanted a computer but was not interested in
programming one.
note also, ibm was selling the PC into the mainframe terminal market
where you could upgrade from a dumb display on your desk to a PC
... which could be used as both an mainframe terminal and for various
kinds of local processing (like spreadsheets) ... single box on
business desk that satisfied both mainframe terminal as well as local
processing requirements. There were also things like somebody taking
tinycalc from turbo pascal ... and distributing an expense account
spreadsheet for business travelers (much smaller footprint than either
visacalc or 123).
you could get a terminal emulator where you set/tune things like key
repeat delay and key repeat rate ... as well as not lock the keyboard
if you happen to be typing at the moment the mainframe decided to
write to your screen.
random references:
http://www.garlic.com/~lynn/2000b.html#35
http://www.garlic.com/~lynn/99.html#222
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 -0800
1) in late '70s did SYSPAG changes against vm/370 & vm/hpo bases
SYSPAG separated the structure for allocation and deallocation.
allocation structure could be multiple portions of device.
page migration then supported specific (whole) device or specific
allocation areas on a specific device ... which would scan all tables
looking for pages resident on that specific area/device.
it was also possible to remove areas from the allocation control
structure to achieve cleaning. The allocation blocks were removed
before starting the migration .. with specific allocation areas
removed from the allocation structure .. migration would clean off all
pages for the specific area(s) ... and no new pages would get
reallocated during the process. At the end of the clean/migration
process there would be no pages left in the area.
It was then possible to vary off the device.
2) redid the spool file system (SFS) in the early 80s.
spool file infrastructure was modified so that each disk was
effectively an independent spool file system. a specific spool file
tended to be allocated on a single drive ... although it was possible
to "concatenate" spool file segments that crossed volumes. spool file
recovery information was unique to each disk.
at CP startup, each spool disk would be mounted separately and its
spool file system integrated into the CP infrastructure. It was
possible to remove drive from spool file allocation ... although still
allow access to files on the disk. It was possible to more/migrate
files off a spool file disk. It was possible to vary off a spool file
drive whether it contained files or not. Files on a varied off device
were just not available.
Spool drive with intact spool files could be varied back on and merged
back into the production running system at any time.
A lot of the administrative function for SFS was rewritten in Pascal
and moved to a virtual machine. One objective was for SFS to be
significantly faster than the existing 370/HPO spool file system (even
when kernel had to make upcalls to functions running in virtual
address space). Critical to SFS having better performance was that
370&HPO managed the spool file infrastructure with link list
structure ... doing linear scans for adding & deleting. This was
enormously expensive for reasonably sized system. SFS implemented some
things with hash table and other stuff with red/green trees. That
performance improvement more than offset degradation associated with
moving function out of the kernel into virtual address space.
There was also SFS pascal code support for running on unmodied CP
system using the full block spool file interface (used by RSCS) to
pull files out of existing spool system. These could be written to
tape (similar to spool file to tape) or copy to volume in the new
structure. It could also read standard spool file tapes and write to
volume in the new structure.
SFS also implemented thruput enhancements for HSDT (high speed data
transport). Standard RSCS interface processing 4k spool file block was
synchronous .. which resulted in RSCS being blocked (non-runnable)
while the 4k spool file block was read or written. WIth spool file
checkpointing, lots of small files, and any device contention (for
instance other apps doing any spool file activity) ... RSCS thruput
could be as low as 20kbytes/sec (and difficult to get any better than
100kbytes/sec in most configurations).
HSDT had multiple full duplex T1 links; 1.5mbits/sec simplex ... about
150kbytes/sec; 300kbytes/sec full duplex per link, 3-4 links needed
1.2mbytes/sec sustained aggregate thruput. SFS provided a asynchronous
interface for RSCS and did the spool file logging (checkpoint)
completely different to remove it as a bottleneck also.
random URLs:
http://www.garlic.com/~lynn/94.html#22
http://www.garlic.com/~lynn/94.html#29
http://www.garlic.com/~lynn/94.html#31
http://www.garlic.com/~lynn/94.html#33a
http://www.garlic.com/~lynn/94.html#33b
http://www.garlic.com/~lynn/96.html#38
http://www.garlic.com/~lynn/98.html#49
http://www.garlic.com/~lynn/98.html#50
http://www.garlic.com/~lynn/99.html#34
http://www.garlic.com/~lynn/99.html#36
http://www.garlic.com/~lynn/99.html#201
http://www.garlic.com/~lynn/99.html#222
Anne & Lynn Wheeler lynn@adcomsys.net, lynn@garlic.com
http://www.garlic.com/~lynn/ http://www.adcomsys.net/lynn/
Refed: **, - **, - **, - **, - **
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:
That brings back some memories. In the early 70's, there was a PL/I
program at a local service bureau which looked at MVT abends via
//SYSUDUMP DD DSN=&&DUMP,DISP=(,PASS)
etc. My ability to read dumps degraded rapidly - PL/I hardly ever
produces one, unless forced.
the other one ... from the mid to late '60s ... being able to fan a
compiler output "text" deck ... looking for the card to "patch"
(i.e. run thru dup on 026/029 and multipunch a "fix").
misc. references.
http://www.garlic.com/~lynn/93.html#17
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
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 GMT
jon.evans@POSTOFFICE.CO.UK (Jon Evans) writes:
Dick,
For backup, the OSA-Express feature allows multiple cards to automatically
takeover the IP addresses of any other failing cards on the same box & subnet.
During our testing, the takeover took about 10 secs with active FTPs. See the
'Enhanced Network Availability' section in 'OSA Express Guide and Reference'
http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/IOAEXP01/1%2e1%2e9?SHELF=IOA39009
As for balancing, at 2.8 you can't balance the inbound traffic but you can
balance the outbound if the cards are on the same subnet. See IPCONFIG MULTIPATH
PERPACKER or PERCONNECTION in the 'IPCONFIG Statement' section of 'OS/390 V2R8.0
SecureWay CS IP Configuration'
http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/F1AF7020/1%2e4%2e29?SHELF=F1A0BK05
Both very easy to get working. The outbound load balancing just an obeyfile to
switch on/off & worked first time. The failover automatically works, I didn't
actually figure a way to turn this off, not that I'd want to.
Rgds, Jon.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@bama.ua.edu with the message: GET IBM-MAIN INFO
when we first did ip takeover stuff in the late 80s when we were
starting the ibm HA/CMP project ... we found a bug in many of the
TCP/IP clients (many of them had been built off the 4.3 tahoe/reno
distribution).
The problem was in the ARP implementation in 4.3 on the clients.
Normally, ARP is suppose to "age" out the ip->MAC (aka enet or t/r)
address and reload the cache with current value. However, the 4.3
code had a performance speedup in the IP code (just before checking
the ARP cache) ... if the the current packet has a to-ip-address that
is the same as the previous packet ... it had saved the value and
bypassed calling ARP. The problem was in client/server or
client/router configurations where the client tended to only
communicate with the same IP-address for long periods of time. As a
result, the "hip-pocket" MAC address would never change ... and wasn't
subject to the ARP cache time-out rules (i.e. wasn't a problem with
server ip-takeover ... but a bug in all the clients).
We would see instances where we had done the ip-address takeover at
the server and 30 minutes later still had clients trying to
communicate to the old MAC address. Workaround was to send all
discovered clients a PING from a different IP-address. To respond, the
clients would have send a packet to the different IP-address ... &
would have to actually call ARP ... which would change the hip-pocket
ip/MAC address. Then when the client attempted to communicate with the
server again ... the ip-address in the hip-pocket had changed so ARP
would have to be called ... and the current MAC address would be used.
misc. refs.
http://www.garlic.com/~lynn/96.html#15
http://www.garlic.com/~lynn/96.html#34
http://www.garlic.com/~lynn/99.html#54
http://www.garlic.com/~lynn/99.html#71
http://www.garlic.com/~lynn/99.html#164
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
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 GMT
daha@best.com (David S. Harrison) writes:
I have need for a simple authentication protocol that can be used
to insure that a client, speaking to a custom server, cannot be
easily emulated. Due to the nature of the connection between client
and server, I must assume that it is very easy to watch the traffic
between the two.
we've worked with organizations for an AADS version of RADIUS ...
i.e. effectively a digital signature challenge/response in radius.
Radius sends something to be signed ... it gets signed and the
signature returned. the server then verifies the signature using
public key registered for the specific user/account (i.e. public key
registered in place of password). ISPs that use RADIUS for internet
access ... and use web servers that support RADIUS for client
authentication ... then need only a single administrative
infrastructure for authentication.
basically uses similar AADS infrastructure proposed for X9.59
financial transactions. Challenge for X9.59 was lightweight protocol
for all electronic retail payments (credit, debit, e-check, prepaid,
etc) that preserves the integrity of the financial infrastructure with
only a digital signature. Assumptions were transaction could flow over
an untrusted network and everything was subject to evesdropping
... including the account number.
misc. refs.
http://www.garlic.com/~lynn/aadsm2.htm#inetpki
http://www.garlic.com/~lynn/aadsm2.htm#account
http://www.garlic.com/~lynn/aadsm2.htm#straw
http://www.garlic.com/~lynn/aadsm2.htm#keylength
http://www.garlic.com/~lynn/aadsm2.htm#pkikrb
http://www.garlic.com/~lynn/aadsm3.htm#kiss3
http://www.garlic.com/~lynn/aadsmore.htm#hcrl2
http://www.garlic.com/~lynn/99.html#230
http://www.garlic.com/~lynn/2000b.html#14
http://www.garlic.com/~lynn/8583flow.htm
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why are Suns so slow?
Newsgroups: comp.sys.intel,comp.arch,comp.sys.sun.misc
Date: Tue, 04 Apr 2000 16:35:23 GMT
the emerging workstation market had significant better
price/performance for hardware that was becoming almost commodity
priced parts. the cost profile of doing unix fit the startup/companies
doing these sort of hardware products (they could hardly spend more on
proprietary operating system development than they were spending on
hardware devleopment).
misc refs:
http://www.garlic.com/~lynn/99.html#222
http://vm.marist.edu/~piper/party/jph-12.html#wheeler
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How to implement doubly link list with only one pointer ?
Newsgroups: comp.programming,comp.theory
Date: Sun, 09 Apr 2000 16:18:37 GMT
Ariel Scolnicov writes:
So now we've gone from something that's horribly un-C-like to
something incredibly un-C++-like. Anybody feel like making an STL
list implementation?
s/traversal object/iterator/...
i've seen XOR pointer trick used for trees also where there was a lot
of ascending and descending .. have to watch for being at the
bottom/end of branch & at node. Trees would get re-org'ed a lot
... but there was little in them other than some flags and a separate
pointer to the actual data stuff (which lived outside of the tree
structure).
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
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:
VM/370). The first terminals (that I remember) used where 1050s and 1052s
(as I recall, the granddaddies of the 3215), and VM also supported TTY's
(ASCII). A version also supported 2260s, but I don't know if that was
allowed to go to the users. When 3270s became available in the market,
VM was there using them.
I did the TTY support for CP/67 while an undergraduate ..there is a tale about
a bug in the code ... misc. ref
http://www.garlic.com/~lynn/99.html#44
and as indicated also worked on a project that took some interdata
hardware (early precursor to box used for one of the non-DEC ports of
UNIX) and simulated an ibm mainframe controller (supposedly credited with
originating the ibm plug-compatible market).
They were line/print (tty33 & 35) ascii terminals at 110buad ... but
not too long afterwards 300 baud line terminals with heat sensitive
paper & then screens (like adm3a) that simulated line terminals
... but you could play games with cursor re-positioning
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 always liked to tease the MVS bigots about LPAR just being a covered up
VM; of course, they didn't believe me. You could IPL the system, and go into
the appropiate console frame and see the VM IPLing (I forgot which flavor
of VM is was, maybe a VM/SP modified to handle XA ?). Later of course,
ESA support was added along with other stuff.
Gerard S.
3090 for the console & service processor had a pair of 4361s running a
highly modified version of VM Release 6 (not even SP, hpo, etc) & all
the service processor panels were driven from CMS IOS3270.
I'm sure it has had numerous modifications & enhancements since
then. The basic LPAR is effectively enhanced version of the origianl
VM microcode assist or, if you will, the virtual machine SIE
infrastructure with some additional configuration wrappers built
around it thru service processor support.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
jmaynard@thebrain.conmicro.cx (Jay Maynard) writes
Okkay, so what does SIE do, exactly?
on 360 & 370 it was possible to swap from supervisor state & problem
state and address space mode all in a single instruction (LPSW). For
XA ... that was no longer possible ... i.e. the bare bones XA
architecture was much more MVS oriented where the supervisor (aka
kernel) code was resident in all address spaces ... and didn't
switched back & forth between kernel mode and application mode w/o
having to also switch address space.
The CP/VM kernel code had its own address space and needed to be able
to simultaneous switch between priviledge & non-priviledge mode while
at the same time switching between the kernel address space and the
application address space.
SIE was introduced in XA architecture to support CP operation ... &
while they where at it they threw in various VM performance assists
i.e. effectively microcode for instructions that would follow the
rules for how an instruction operated in virtual machine mode ... as
opposed to how it might operate natively. For simulation of a virtual
machine ... CP might follow slightly different rules when simulating
a priviledge instruction ... effectively those virtual machine "rules"
for instruction execution was dropped into the microcode of the machine.
For those things ... it was no longer necessary for CP to simulate a
priviledge instruction according to virtual machine rules ... many of
the instructions ... if they were in "SIE" mode ... would automatically
perform the instruction according to virtual machine rules.
LPARS ... are logical partitions ... a physical processing complex can
be partition into multiple "logical" (or virtual) machines. In some
sense, a logical partition alwas operates in "SIE" mode ... following
the rules for instruuction execution laid down for it. Rather than
actually needing VM operating system to manage the machine ... the
"microcode" (aka service processor) sets up the configuration
operations governing LPAR operation.
--
Anne & Lynn Wheeler | lynn@garlic.com, finger for pgp key
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
jmaynard@thebrain.conmicro.cx (Jay Maynard) writes
Okkay, so what does SIE do, exactly?
load program status word was used in 360 & 370 to switch between
kernel mode and virtual machine mode. CP kernel ran in "real mode" (no
address translation) and supervisor mode (all instructions were
executable). The address space control register pointed to the virtual
address space tables and CP would use the "load real address"
instruction to do virtual->real address translation before operating
on virtual machine/address storage.
The target of a LPSW instruction was an 8byte field that contained the
new instruction address, the supervisor/problem mode bit, and the
real/virtual address (DAT, or dynamic address translation) mode
bit. To start execution of a virtual machine, a LPSW instruction was
executed that had a target of a virtual instruction address in the
virtual address space, the supervisor/problem mode bit set to problem
mode, and the DAT mode bit turned on.
All hardware interrups occured by loading an 8byte PSW field from
fixed location in real storage and storing the current PSW (current
instruction address & state information) in a separate real storage
location . The kernel code had initialized the "new PSW" fields to a
real instruction address in the kernel, supervisor/problem mode bit
set to supervisor and the DAT mode bit turned off.
Any attempt to execute a "supervisor" instruction while in problem
mode would result in storing the current 8byte PSW in the "OLD PSW
field" in fixed real storage along with the reason for the interrupt
and loading a new PSW from fixed real storage.
CP's kernel was mapped to real storage and not included in the virtual
address mapping of any virtual machine. It was possible for CP to
switch to virtual machine mode by first loading the appropriate
address space table in the address space control register and then
executing a LPSW that switched: 1) instruction address, 2) problem
mode, and 3) address translation mode. Any interrupt (supervisor,
program, exception, page fault, I/O, machine, timer, external, etc)
would switch back to 1) cp kernel instruction address, 2) supervisor mode,
and 3) non-DAT mode.
370 introduced BC/EC mode (bit 12 ... former ascii/ebcdic bit in 360
mode). in 360/BC mode, the first 8 bits of the PSW were the channel
interrupt mask (if the corresponding bit was one, the processor would
take I/O interrupts from that channel). In EC/mode, the channel mask
was moved to a 32bit control register and replaced with a single
summary bit which would disabled all I/O interrupts (or enabled the
control register mask).
Following (dated '85) reference contains more detailed description of
interrupts & PSW processing for CMS bc-mode operation (about half-way
down the document):
http://www.geocities.com/SiliconValley/2260/vmcom25.html
SIE stands for "start interpretive execution"
following from:
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/HCSF8A02/3%2e1%2e1%2e2?SHELF=HCSH2A08
3.1.1.2 Interpretive-Execution Facility
One of the key differences between processors that support ESA/370
or ESA/390 architectures and System/370 processors is the
interpretive-execution facility. CP depends on the
interpretive-execution facility to process work for virtual
machines.
A virtual machine currently running under the control of the
interpretive-execution facility is said to be running in
interpretive-execution mode. When the virtual machine runs in
interpretive-execution mode, the interpretive-execution facility:
Handles most privileged and nonprivileged instructions.
Handles the virtual interval timer, the clock comparator, and the
processor timer.
Translates and applies prefixing to storage addresses. For
instance, the facility performs the double-page translation
required to page third-level storage into first-level storage.
Subtopics:
3.1.1.2.1 Assists Supported by the Interpretive-Execution Facility
a listing of CP performance facilities:
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/HCSI1A02/2%2e1%2e4?SHELF=HCSH2A08
The online VM bookshelf is at:
http://www.s390.ibm.com:80/os390/bkserv/vm/
it is possible to select "interpretive execution" text search for
VM/ESA V2 R3.0 bookshelf can be done at:
http://www.s390.ibm.com:80/os390/bkserv/vm/vm23_srch.html#text
which gets the following list:
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/Shelves/HCSH2A08?searchRequest=interpretive+execution&action=Search
and possibly more than anybody wanted to know about LPARs:
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/DA2A8003/CCONTENTS
http://www.s390.ibm.com:80/bookmgr-cgi/bookmgr.cmd/BOOKS/DA2A8004/CCONTENTS
random other refs:
http://www.garlic.com/~lynn/98.html#35a
http://www.garlic.com/~lynn/99.html#71
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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 GMT
DPeiser writes:
I need to have the following functionality and wonder if
anyone has developed this already for any clients:
Smartcard holding a digital certificate (private key) and
health data
Digital Certificate is used for accessing patient health
records via the internet
Ability to use a Smartcard with any PC that has a
compatible card reader - certificate will be read via a web
browser to identify the patient and allow access to that
patient's health record
There should be no record of the certificate on the PC
after the patient logs out
note that a message/request can be authenticated by (digitally)
signing the message with the private key. The corresponding public key
is used to authenticate the digital signature (& the message).
messages typically carry some unique value in order to preclude
"replays" (i.e. either the server that plans on authenticating the
message provides the unique value ... or it keeps around previous
messages and rejects duplicate messages that it has already
processed).
public key certificates have been used in infrastructures for
communicating the public key to the authenticating server ... when the
authenticating server has no prior (business) relationship with the
signing party (patient) &/or when the authenticating server has no
local storage for maintaining records of (business) relationships (or
patients).
environments where there is an existing relationship and/or the
authenticating server has records regarding the requesting party
(patient) ... have been able to upgrade password &/or shared-secret
infrastructures to record the patient's public key for authentication
purposes (i.e. instead of recording a secret password, record the
patient's public key and use that public key for authenticating
digital signatures ... w/o requiring a public key certificate to be
transmitted along with each request).
The analogy in call center/telephone authorized access to patient
records involve asking the patient things that might be found in the
patient record like mother's maiden name, social security number,
patient number, address, birth date, etc.
Some issues with public key certificate infrastructure are who issued
the certificate and can they be trusted ... and does the bound
information in the certificate correspond to any identity information
found in a patient record (i.e. a certificate may be perfectly valid
... but what indicates that a specific certificate in any way
correlates to a specific patient). Also, if there is too much identity
information carried in the certificate ... the identity information
carried in the certificate may represent privacy problems.
On the other hand ... in minimizing privacy exposures with identity
certificates, if the patient record institution issued the certificate
(with only a patient number), then the patient record has already
recorded the patient's public key ... which would be recorded in the
patient's record. In that situation, requiring the patient to transmit
a copy of the certificate back to the patient record institution (in
order to communicate the public key) is redundant and superfluous
since the patient record institution would have the public key already
record (and in fact would have the original of the public key
certificate ... i.e. redundant to send a copy of a public key
certificate back to the institution that has the original of the
public key certificate).
In any case, the problem with making sure a certificate is not left
around (and any exposure involving privacy leakage) is solved by
eliminating any requirement to ahve the certificate exist at all.
recent news article on privacy leakage with identity certificates
http://www.zdnet.com/zdnn/stories/news/0,4586,2523596,00.html
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
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:
RS/6000 (Power) ---> PowerPC -- this has memory translation constructs
called "segments," but they have nothing whatsoever to do with what
Multicians (or even Intel programmers) call segments. Funny, I'd been under
the impression that at least one IBM mainframe had segments, and that big
blue had a clue as to what they are and how to implement them. Oh, well,
more mud in the water...
801->romp->rios/6000/power
used segments and inverted tables. For 32bit addressing ... they
limited things to fixed sized large segments; 16 256mbyte (top four
bits of the virtual address).
Since there weren't any (segment) page tables ... tables were
identified logically with an ID-number (managed by the supervisor)
instead of a pointer to the (segment) page tables.
The original design trade-off had
1) early binding of trust at code build time and little or no run-time
privilege/non-privilege in a "closed system". Effectively, in-line
library code could swap segment pointer/values ... in much the same
way generated code is allowed to load storage pointer values into
address registers
2) small number of "concurrent" segments ... that could be mapped into
efficient segment registers
3) inline code could compensate for the small number of concurrently
addressable segments by being able to rapidly change segment register
(id) values ... w/o having to go thru supervisor calls needed for
authorization access checking (i.e. in much the same way that inline
code can change values in address registers).
ROMP has been described as having 40-bit virtual addressing. It is
actually 32-bit virtual address ... with the top four bits used to
select a segment register. ROMP supported 12-bit segment IDs ... this
translates into an aggregate total of 4096 segments for a running
system and roughly corresponds to the total number of different
(segment) page tables (in a page table hardware architecture ... as
opposed to an inverted table architecture).
RIOS/6000/power increased the segment ID field from 12-bits to 24bits
(and is sometimes described as having 52bit virtual addressing) ...
again the 24bits corresponds to the total system aggregate number of
page tables that could exist in a system (that used page tables ...
rather than inverted tables).
So the 801/romp/power segments are different in two respects
1) need a segment "id" in an inverted table architecture instead of a
page table pointer
2) small number of concurrent segments (16) mapped to hardware
registers was a performance/complexity trade-off based on a design
point that assumed a closed, proprietary operating system that
performed early trust binding and didn't require runtime authorization
checking to swap segment values (could be done using inline code as
simply as changing values in address registers).
current power approach to supporting open operating system with
supervisor calls & runtime authorization checking when changing
segment values has been to create composite shared objects (i.e. cram
multiple different feature/function/libraries into a single 256mbyte
segment object). It overcomes both problem of having large number
of different "shared" objects simultaneously and the overhead and
(unix/application) complexity that would have been associated with
frequent segment switches.
misc. refs:
http://www.garlic.com/~lynn/94.html#47
http://www.garlic.com/~lynn/95.html#5
http://www.garlic.com/~lynn/95.html#6
http://www.garlic.com/~lynn/95.html#11
http://www.garlic.com/~lynn/97.html#5
http://www.garlic.com/~lynn/98.html#25
http://www.garlic.com/~lynn/98.html#26
http://www.garlic.com/~lynn/98.html#27
In '60s, CP/67 (concurrent with Multics but on 4th floor 545
technology sq., running on ibm 360/67) didn't really make use of the
67 segment architecture ... although TSS/360 did. 360/67 had support
for one meg segments, only sixteen per address space in 24 bit mode,
but 4096 in 32 bit mode.
In early '70s, VM/370 did make use of segments when the ibm 370 came
out (initially done 545 tech. sq ... but then moved out to the old SBC
building in burlington mall). 370 had both 2k & 4k page options and
64k & 1meg segment options. VM/370 used 4k pages & 64k segments and
implemented R/O shared segments for CMS.
--
Anne & Lynn Wheeler | lynn@garlic.com
http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **</