List of Archived Posts

2001 Newsgroup Postings (10/31 - 11/28)

7.2 Install "upgrade to ext3" LOSES DATA

ASR33/35 Controls

RSA SecurID: public key cryptography?

mainframe question

Smart Card vs. Magnetic Strip Market

Smart Card vs. Magnetic Strip Market

Smart Card vs. Magnetic Strip Market

mainframe question

mainframe question

Smart Card vs. Magnetic Strip Market

mainframe question

mainframe question

Multics Nostalgia

mainframe question

adventure ... nearly 20 years

departmental servers

mainframe question

3270 protocol

mainframe question

3270 protocol

Problem with inserting signatures

misc. SSL

When did full-screen come to VM/370?

Smallest Storage Capacity Hard Disk?

Smallest Storage Capacity Hard Disk?

ESCON Data Transfer Rate

Call for folklore - was Re: So it's cyclical.

Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement

Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement

Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement

Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement

Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement

Number of combinations in five digit lock? (or: Help, my brain hurts)

XEDIT on MVS

9-track tapes (by the armful)

CA Certificate Built Into Browser Confuse Me

Is OLTEP really dead?

CA Certificate Built Into Browser Confuse Me

CMS under MVS

serialization from the 370 architecture "red-book"

info

Solutions to Man in the Middle attacks?

denver 2001 convention

FA: Early IBM Software and Reference Manuals

Call for folklore - was Re: So it's cyclical.

Commenting style (was: Call for folklore)

FA: Early IBM Software and Reference Manuals

TSS/360

Author seeks help - net in 1981

TSS/360

Free digital signature??

Author seeks help - net in 1981

Author seeks help - net in 1981

TSS/360

Author seeks help - net in 1981

TSS/360

Contiguous file system

Contiguous file system

Contiguous file system

7.2 Install "upgrade to ext3" LOSES DATA

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 7.2 Install "upgrade to ext3"  LOSES DATA
Newsgroups: linux.redhat
Date: Wed, 31 Oct 2001 18:20:31 GMT

"Daniel McAllister" writes:

I have done quite a bit of homework here, and to the best I can tell, the
RHL 7.2 install CD's do NOT upgrade existing ext2 filesystems to ext3
filesystems correctly (if you have DATA on them!)

So, as a WARNING... if you have DATA on your drive, do NOT ask RHL 7.2 to
upgrade to ext3 for you -- do it manually after the upgrade with the
following command:

# e2fsck <yourdrive>
# tune2fs -j <yourdrive>
# mount -t ext3 <yourdrive> <yourmountpoint>

Then, save your mount info in your /etc/fstab file.

(I allowed RHL 7.2 to "upgrade" a disk with data on it... I got an EMPTY
filesystem and a 32 MB journal file that was worthless! Nothing like 100%
data loss to make one happy he did a backup first!)

I had no problem with allowing RHL7.2 to "upgrade" ... in fact, all my disks
were ext2 (including boot) and it upgraded them all to ext3

I did find a ".journal" file in each filesystem that was approx. point
one percent the size of the filesystem.

I did have a filesystem that was otherwise empty and to just
cross-check, I deleted it, recreates it with mkfs as ext2 filesystem
and then ran tune2f2 and the rest (as above).

It is now a ext3 filesystem ... but there is no ".journal" or
otherwise recognizable file (for the journal). I'm not that familiar
with ext3 ... so I'm not sure where the default journal got stuffed
and/or how the RHL7.2 upgrade created the .journal file.

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

ASR33/35 Controls

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ASR33/35 Controls
Newsgroups: alt.folklore.computers
Date: Thu, 01 Nov 2001 00:48:18 GMT

jmaynard@thebrain.conmicro.cx (Jay Maynard) writes:

The 3270 protocol lends itself to redundant space elimination and not
retransmitting parts of the screen that haven't changed. Unfortunately, the
standard software didn't take advantage of that, though some applications
(most notably [I]SPF) did. One of BMC Software's early products was a
package that inserted itself in the path to the terminal and did that
optimization for it. Since that's the kind of optimization that curses does
automagically, I can believe that folks would want to go that way.

we eventually got a large batch of (ascii) 3101s ... that have a vague
resemblance to 3270s ... which had both block mode & line mode (as
well as attached printer for various kinds of stuff). an internal
application did a heavy job of transmission optimization for 3270s on
3101s (as part of home terminal program). It wasn't all that different
of some of the stuff done earlier for line-mode2 emulation on things
like adm3a (tymshare which used same operating system had something
similar for optimal transmission for line-mode emulation).

the next advance was large availability of ibm/pcs for the home
terminal program ... and an advanced PC/host emulation of 3270 over
ascii lines where the PC/host kept something akin to dictionary of
already transmitted data (at the PC) ... and the host would transmit
the index to the (previously displayed) data to be displayed (as
opposed to the data itself).  This worked especially well for
partially updated screens (this is analogous, but less sophisticated
to some of the current video MP3 compression techniques).

random refs:
http://www.garlic.com/~lynn/99.html#9 IBM S/360
http://www.garlic.com/~lynn/99.html#69 System/1 ?
http://www.garlic.com/~lynn/2000b.html#29 20th March 2000
http://www.garlic.com/~lynn/2000g.html#17 IBM's mess (was: Re: What the hell is an MSX?)
http://www.garlic.com/~lynn/2000g.html#36 stupid user stories
http://www.garlic.com/~lynn/2001b.html#12 Now early Arpanet security
http://www.garlic.com/~lynn/2001b.html#13 Now early Arpanet security
http://www.garlic.com/~lynn/2001e.html#66 line length (was Re: Babble from "JD" <dyson@jdyson.com>)
http://www.garlic.com/~lynn/2001f.html#57 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001h.html#32 Wanted: pictures of green-screen text
http://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question

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

RSA SecurID: public key cryptography?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RSA SecurID: public key cryptography?
Newsgroups: sci.crypt
Date: Thu, 01 Nov 2001 16:09:54 GMT

hifan@gmx.de (Florian Lindauer) writes:

But then, there was the hint with the 6-digit (thus
equivalent to about 20bit) passcodes being much shorter
than any reasonable key-length. Perhaps someone can
refresh my cryptographic knowledge: does it really
compromise the secret key using it to sign very short
hashes (shorter than keylength)? I do not currently see
why this is the case (and thus would really disqualify
pkc for use in this application). Sorry if my level of
cryptographic expertise does not match the prevalent
level in this newsgroup :)

typical public key digital signatures are done by hashing the value
and then encrypting the hash. a typical hash is SHA-1 ... which has
messages padded to be multiple of 64bytes (512bits) . The result of
SHA-1 is 20 byte value (160bits) ... which is then encrypted with the
private key (resulting in a 20byte/160bit signature).

RSA signed messages may also includes specification that the message
itself contain things like a 20 byte randomly generated number
(included prior to hashing).

one issue with key length is brute force attack involved in trying
every possible key. randomly chosen secret keys of N bits can have
2**N possible key values. Issue with RSA keys is that they are prime
numbers ... so for random chosen RSA key of length N bits ... there
are much fewer than 2**N possible key values i.e. it is not all
possible integers of 2**N, but only prime numbers of 2**N. Key length
is chosen so that the number of possible keys are very large making
brute force attack more difficult i.e. in RSA public key case, keys of
length N doesn't mean that there are 2**N possible keys. Because of
the relatively sparcity of prime numbers, RSA key lengths have to be
quite large in order that the number of possible key values are
sufficiently large.

In any case, nearly all chosen RSA private keys these days are much
larger than the size of the 20-byte/160-bit SHA-1 hash that they
"encrypt" (i.e.  256-bit, 512-bit, 768-bit, 1024-bit, etc RSA private
keys are greater than the 160-bit SHA-1 hash).

fips 180-1, sha-1
http://csrc.nist.gov/publications/fips/fips180-1/fip180-1.txt

                            4. MESSAGE PADDING

The SHA-1 is used to compute a message digest for a message or data file that
is provided as input.  The message or data file should be considered to be a
bit string.  The length of the message is the number of bits in the message
(the empty message has length 0).  If the number of bits in a message is a
multiple of 8, for compactness we can represent the message in hex.  The
purpose of message padding is to make the total length of a padded message a
multiple of 512.  The SHA-1 sequentially processes blocks of 512 bits when
 computing the message digest.  The following specifies how this padding shall
be performed.  As a summary, a "1" followed by m "0"s followed by a 64-bit
integer are appended to the end of the message to produce a padded message of
length 512  n.  The 64-bit integer is l, the length of the original message.
The padded message is then processed by the SHA-1 as n 512-bit blocks.

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

mainframe question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: mainframe question
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Thu, 01 Nov 2001 16:52:59 GMT

cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:

Probably the most (in)famous engine unit was the "egg beater" as used in
experimental models of the Lee and Grant and later the Shermans, which was
a 30-cylinder unit constructed by joining five 6-cylinder inline truck
engines together around a common crank, creating something which could be
viewed either as a radial or multi-bank arrangement depending on how you
looked at it!  Wouldn't have fancied trying to maintain that thing, although
it was apparently very reliable.

so going really far OT
http://www.garlic.com/~lynn/2000c.html#85 V-Man's Patton Quote (LONG) (Pronafity)
http://www.garlic.com/~lynn/2001.html#30 Review of Steve McConnell's AFTER THE GOLD RUSH

and
http://www.garlic.com/~lynn/subtopic.html#boyd

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

Smart Card vs. Magnetic Strip Market

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Smart Card vs. Magnetic Strip Market
Newsgroups: alt.technology.smartcards
Date: Thu, 01 Nov 2001 23:01:46 GMT

aiko@zonereactor.com (Aiko Yoshikawa) writes:

I am doing some market research on the relative
advantages/disadvantages of smart cards over traditional magnetic
stripe cards.

My understanding of the differences (all numbers US)
                      Magnetic        Smart
Cost/Card             4-10 cents      $1 (read-only card) - $10 (read/write card)
Cost/Reader           <$100        $100
Installed readers     +5 M            20 K
Security              OK-Low          OK-High
Load on network       high            low
"Smart"               No              Yes

My questions:
1) are these the salient characteristics, or have I missed some?
2) is the data correct for card/reader costs and # of installed
readers?
3) Do you know what the "cost" is per transaction on the network for a
credit card vs. a smart card?

a lot of the (financial) smartcards out there have been in some
regions with stored valued for offline transactions (i.e. there is an
offline exchange of value between the stored value on the card and the
terminal).  as the world evolves to online, that segment is getting
smaller.

in the US there have been wide deployment of cards into similar
stored-value market segment, but they are magstripe doing online
transaction (you can see various kinds at j-hooks or boxes at various
register &/or check-out counters, they are sometimes packaged as
"gift" cards).

the issue has been the cost/availability of telco in the respective
regions vis-a-vis the chip/magstripe costs (although online/telco is
starting to become a lot more ubiquitous world-wide).

A typical ISO 8583 message that is typically supported for online
financial transactions can be on the order of 60-100 bytes (hardly a
"high" network load by internet standards ... if every transaction in
the world would be aggregated onto a single line with peaks of four to
five thousands per second that still only represents 500,000
bytes/second or say 5mbits/second (less than a T2 telco) ... hardly
anything compared to the multiple OC3, OC12, OC48 trunks that they
talk about for internet.

With regard to price of an online transaction ... there is a
significant difference between say the online stored-value
transactions and credit-card transactions ... even tho the message
traffic and to some extent the straight-line transaction flow is
similar. An issue in credit-card transaction is that there is
significant ancillary processing.

There has been some look at upgrading the current online transaction
world from magstripe to chips .... focusing on the use of the
magstripe card vis-a-vis hardware-token/chips as a strong
authentication mechnaism (as opposed to enabling offline
transactions).

misc. chip strong authentication ref:
http://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card fraud"
http://www.garlic.com/~lynn/aepay6.htm#ccfraud3 "out of control credit card fraud"
http://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit cards!

some discusson on offline/online transaction cost/price
http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash

references to the financial industry standard X9.59 for all
account-based transactions (all environments, any kind of account):
http://www.garlic.com/~lynn/x959.html#x959

discussion of mapping X9.59 into standard online ISO 8583 message:
http://www.garlic.com/~lynn/8583flow.htm

some AADS chip strawman discussion on characteristic of a chip that
would be applicable for such an environment:
http://www.garlic.com/~lynn/x959.html#aads

misc. sored-value discussions:
http://www.garlic.com/~lynn/aadsm2.htm#straw AADS Strawman
http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
http://www.garlic.com/~lynn/aadsm6.htm#terror12 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda)
http://www.garlic.com/~lynn/aadsm7.htm#pcards4 FW: The end of P-Cards?
http://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS
http://www.garlic.com/~lynn/aadsmore.htm#eleccash re:The Law of Digital Cash

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

Smart Card vs. Magnetic Strip Market

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Smart Card vs. Magnetic Strip Market
Newsgroups: alt.technology.smartcards
Date: Fri, 02 Nov 2001 16:01:45 GMT

aiko@zonereactor.com (Aiko Yoshikawa) writes:

Cost/Reader           <$100           $100

the other issue ... as in aads chip strawman posting ...
http://www.garlic.com/~lynn/aadsm2.htm#straw

it is possible to build a reader for close to $2. volume
manufacturing where the reader is housed inside of some other
component (some housing, wiring, etc effectively for free) can even
further reduce costs.

an issue is that these are low duty cycle consumer readers where there
is typically some rubbing of the contacts as the card is
inserted/removed.

7816 readers in commerical, "high traffic" positions tend to have the
contacts disengaged when the card is inserted/removed ... and the
contacts move into position only after the card is at rest in the
reader (much more expensive than $2). This still is even somewhat of a
problem for 7816 contact cards ... and there is starting to be some
migration to proximity 14483 card/readers (and/or 7816/14483
combo-cards).

This is some more problematical for the offline applications which
have tended to implement various kinds of shared-secret protocol
between the reader and terminal ... so there is a little more
attention paid to man-in-the-middle attacks with regard to 14483
implementations.

By comparison, a lot of the work for online applications with
chip-cards for authentication have less of a problem. The requirement
given the X9A10 working group for X9.59 was transaction for all
account-based transactions in all environments, preserving the
integrity of the financial infrastructure with only authentication
(i.e. not requiring shared-secret and/or encryption).

Much of the original work on genesis for smartcards (especially
multi-app) was done in the '80s and early '90s for the market niche
currently occupied by PDAs and cellphones (especially with respect to
offline applications).  PDAs and cellphones have taken over that
low-end portable computing market with the added advantage that they
also offer portable input/output capability (lacking in the technology
of the era where the genesis for smartcards originated). Furthermore,
almost all the market niches that were originally envisioned as
offline are quickly becoming online (in part because of various
advances caused by the internet as well as cellphones).

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

Smart Card vs. Magnetic Strip Market

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Smart Card vs. Magnetic Strip Market
Newsgroups: alt.technology.smartcards
Date: Fri, 02 Nov 2001 17:03:56 GMT

Anne & Lynn Wheeler writes:

7816 readers in commerical, "high traffic" positions tend to have the
contacts disengaged when the card is inserted/removed ... and the
contacts move into position only after the card is at rest in the
reader (much more expensive than $2). This still is even somewhat of a
problem for 7816 contact cards ... and there is starting to be some
migration to proximity 14483 card/readers (and/or 7816/14483
combo-cards).

another issue increasing the cost of some readers in commercial
environments is their use for financial transactions. Effectively the
POS terminal is an extension of the financial infrastructure but
located remotely in possible hostile & unregulated environment. These
POS terminals effectively need some amount of armoring & both physical
and electronic security ... increasing their costs. However, this is a
common expense that applies to both magstripe and chip-card POS
terminals (and/or even POS terminals that are combo magstripe, contact
7816 and possibly proximity 14483).

some similar work has been done in the area of consumer readers for
financial transactions ... somewhat under the assumption that a
consumer's own PC environment might be hostile and therefor the
chip-reader may need compensating security procedures. Some of this is
evident in the EU's finread activities.

random refs:
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure

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

mainframe question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: mainframe question
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Fri, 02 Nov 2001 19:49:00 GMT

Wild Bill writes:

Nobody's mentioned the Pontiac GTO or Oldmobile 442. Each came optionally
with three deuces (or, six-pack as they were called) with progressive
linkage. As long as you kept the gas pedal within the first half inch, or so
you could expect about 12 mpg. When the 2nd set kicked in, about 10, then
with the 3rd you went down to less than 8.

long ago and far away had big pontiac bonneville (6' trunk) with 389
high-compression .... and except cruising on the open road ... it was
difficult to get better than 12mpg ... stomp it to the floor and all
four barrels opened up and it would move out.

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

mainframe question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: mainframe question
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Fri, 02 Nov 2001 19:54:09 GMT

Charles Richmond writes:

I worked with a guy who used to work for General Dynamics when
GD was building the F-111. His job was engine test...they would
strap down an engine and see how much they could get out of it.
This guy said that if you fully opened the throttle on the F-111,
the engine would literally tear the plane apart. I am not sure
about fuel consumption, but evidently they had all the horsepower
they needed...

and when they first started on the f-15 ... a guy i knew pointed out
would that want a fighter than was even worse than the f-111 (and then
proceeded to correct the design and then go on to do the f-16).

random ref:
http://www.garlic.com/~lynn/subtopic.html#boyd

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

Smart Card vs. Magnetic Strip Market

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Smart Card vs. Magnetic Strip Market
Newsgroups: alt.technology.smartcards
Date: Fri, 02 Nov 2001 20:17:11 GMT

aiko@zonereactor.com (Aiko Yoshikawa) writes:

Cost/Reader           <$100           $100

and finally(?) the projected price of even the consumer finread 7816
contact readers were much, much less than $100 ... and the portable
calculator "looking" contact 7816 reader (also mentioned in the
referenced thread) was about the same as a very inexpensive
calculator.

http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking

random refs:
http://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#5 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market

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

mainframe question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: mainframe question
Newsgroups: alt.folklore.computers
Date: Fri, 02 Nov 2001 21:55:33 GMT

D.J. writes:

The M5 Stuart was a light tank and not used much by the US after WW
2. But the Sherman was used for some time afterwards. There were
Shermans in Viet Nam. The UK used the M5 'Honey' in North Africa.

from previous post/ref
http://www.garlic.com/~lynn/2001m.html#3 mainframe question

http://www.garlic.com/~lynn/2000c.html#85 V-Man's Patton Quote (LONG) (Pronafity)

((.. following URL no longer seems to be active ..))

http://www.valourandhorror.com/DB/SPEC/tank/German_tank_2.htm

 Even with air superiority and tank killers like the Firefly, the
 German tanks were far superior to anything the Allies had and enjoyed
 a kill ratio of 1:10.  In 1943-44 the US produced 47,000
 tanks. Germany produced 29,600 tanks and assault guns.  Britain
 produced only 5,000 tanks in 1944. Because of this the British
 depended on the American Sherman as their main battle tank.

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

mainframe question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: mainframe question
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Sat, 03 Nov 2001 16:35:51 GMT

cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:

The main problem with the Sherman wasn't that it was a _bad_
design, but that it was an _old_ design.  The Tigers that were
in use toward the end of the war were contemporary designs
using the latest that technology and battlefield experience
had to offer; the Sherman, on the other hand, was little more
than a revamped Lee whose origins went back, IIRC, to the early
to mid '30s.  Why the Allies[1] never came up with a decent tank
design during the war I'll never understand; they certainly had
the technological know-how and more than enough experience to
do it, as the UK's post-war Centurion proved.  Shame it was a
few years too late...

the war of attrition and logistics being able to take 10:1 losses and
still turn out huge numbers of shermans and come out ahead ... didn't
do a whole lot for the people in the shermans that were being used as
cannon fodder.

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

Multics Nostalgia

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multics Nostalgia
Newsgroups: alt.os.multics
Date: Sun, 04 Nov 2001 05:43:40 GMT

costas@meezon.com (Costas Menico) writes:

Ah, I can't believe there is a newsgroup about Multics. Speaking of
nostalgia. I used it and did some programming in PL/1 when I worked
for Hanscom AFB (I think I was connecting to MIT) back in 1979.  It
actually supported some really cool graphics. I was using this
workstation called IMLAC and I would write PL/1 code and generate
graphics which was bitmapped downloaed to the workstation. Was slow as
hell since I was connected over a modem probably 300baud.

sorry for the intrusion ... slightly related (names wiped to protect
the guilty)


To: wheeler
Date: 04/04/79  08:49:49

lynn, i am setting up a presentation for airforce data services.  they
are currently a multics user and are going out for a bunch of systems
YYY has suggested that Poughkeepsie would be a good place to dazzle
them and has named XXXX as a contact point.  YYY also suggests perhaps
WWWW to talk about common, and ZZZZ to lay on rscs networking.

we have covered vm/cms basics with these folks (AFDS) and have them
turned on - looks like about 20 4341 class machines with netting,
mass-store, etc.

do you have any suggestions as to who would be good people at pough to
sell the wonders of vm?  feel like a trip east, etc.?

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

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

mainframe question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: mainframe question
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Sun, 04 Nov 2001 18:07:24 GMT

cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:

WRT the gas turbine, I don't know if it's still an issue, but it used to
be a concern that they accellarated very poorly even for a tank; this was
often seen as a bad thing since even heavy tanks need to be as manoeuverable
as possible.  I guess they've got that one sorted out since the M1 Abrams
must've been using gas turbines for around 20 years now, though.

from some archive ...


To: wheeler
Date: 02/25/82  13:51:28

Lynn,

   I just heard that Atari has received a contract from the U.S. Army
to build a special breed of arcade to be placed in the clubs on Army
bases around the world.  Each arcade is a pretty accurate simulation
of what someone would see while seated behind the controls of an XM1
tank or a BF infantry vehicle.  Even the controls are similar if not
identical.

  The important point is that each arcade still requires the 25 cents
to play it.  The soldiers are going to be paying to train themselves!
The idea is brilliant.  In ten years, our military personnel are
going to be even more poorly educated (no more reading of manuals),
poorer in pocket, but incredible shots.

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

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

adventure ... nearly 20 years

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: adventure ... nearly 20 years
Newsgroups: alt.folklore.computers
Date: Sun, 04 Nov 2001 18:08:25 GMT

IBM Instruments Inc (Danbury, Ct.) has  announced on Monday 4/26/82 a Motorola
68000 based MICROCOMPUTER  named ADVENTURE. Preliminary specifications are:
1) Base system consisting of
       a) a box containing a planar board + 5 additional slots
          -Planar board has: 128 kbytes of ram, prom resident operating
           system, 5 1/4 in floppy controller, 1 IEEE-488 port,
           3 serial ports (RS 232), 3 timers (2 Mhz), 1 parallel port
       b) Crt (bw, apa, 768480 resolution)
       c) a function keypad (not key board)
2) Prices start at $ 5695 for the base system. Options include:
       Keyboard (same as PC)       270; 4 color printer-plotter 2095
       Sensor board (A/D; Di/do)   850; Floppy drive (2 8in)    2478
       Hard disk controller/Drive 3900; 1 mb ram board          4100
       Basic                       195; Assembler/linker/editor  155
3) First customer ship date 10/82

Further details are available in 2 weeks. A prototype can be seen in
room 7-041 (PM only please)

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

departmental servers

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: departmental servers
Newsgroups: alt.folklore.computers
Date: Sun, 04 Nov 2001 22:18:37 GMT

cut-over from alt.os.multics thread .... as an aside, note that CP/67,
VM/370, and Multics were all done at 545 tech. sq in cambridge (aka
just on different floors of the same bldg).

re:
http://www.garlic.com/~lynn/2001m.html#12 Multics Nostalgia



To: wheeler
Date: 04/04/79  08:49:49

lynn, i am setting up a presentation for airforce data services.  they
are currently a multics user and are going out for a bunch of systems
YYY has suggested that Poughkeepsie would be a good place to dazzle
them and has named XXXX as a contact point.  YYY also suggests perhaps
WWWW to talk about common, and ZZZZ to lay on rscs networking.

we have covered vm/cms basics with these folks (AFDS) and have them
turned on - looks like about 20 4341 class machines with netting,
mass-store, etc.

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

about six months later (fall '79) when a col. & a couple majors
made a west coast visit, it had grown from 20 4341s to 210
4341s.

4341 was a really solid workhorse with great (for its time)
price/performance and was starting to heavily populate the emerging
departmental computing market (later taken over by large workstations
and later large PCs).

A couple years later (after the above refs), the head of POK gave a
talk in San Francisco where he stated that there were 11,000-plus VAX
sales should have been 4341s ... in part because 4341 had better
price/performance.

The problem was as much internal politics as external marketing
forces. 4341s also had much better price/performance than 3031s for
essentially the same thruput ... and small clusters of 4341s had much
better price/performance than 3033s. Furthermore, many 3033s from the
period had environments that were both real storage and i/o channel
constrained. You could get six fully decked out 4341s for less money
than 3033 with 16mbytes of real storage (and 16 i/o channels) ... the
small cluster of 4341 had in aggregate faster mip rate (about six
vis-a-vis 4.5), more real storage (96mbytes vis-a-vis 16mbytes), and
more I/O capacity (36 channels vis-a-vis 16 channels). In part, the
3033 32mbyte real-storage option (sort of a kludge for machine that
was 24bit addressing) was in answer to this.

The other issue was that very small percentage of the 4341s were
installed with (POK) MVS. The combination of non-MVS and serious 303x
competition resulted in some interesting internal politics (the SHARE
user group has long litney of internal politics obfuscating the
ability to market and sell VM as well as VM/4341s whether into
traditional data center operations or into the emerging departmental
server market). One of the stranger internal antics was at one point,
POK managed to cut the chip allocation for critical 4341 component
(from internal fab) in half (as a defensive 303x marketing
operation). Various SHARE studies highlighted that the 11,000 plus VAX
sales (which should have been 4341s) were as much the result of
various internal corporate politics (than anything DEC might have
done).

Of course this is purely a late-70s/early-80s phenomema ... by the
mid-80s, workstations (and then larger PCs) were starting to take over
the deparmental computing server market (in parallel with
client/server somewhat negating some of the need in larger
corporations for departmental servers). However, departmental servers
weren't totally done in by client/server ... the introduction of
middle layer and middle-ware brought them back.

Of course, we are now seeing the (sort-of departmental) server farm
consolidation ... with the likes of advocating tens of thousands of
virtual Linux servers supported by a single 390 machine.

random 4341 refs:
http://www.garlic.com/~lynn/95.html#3 What is an IBM 137/148 ???
http://www.garlic.com/~lynn/96.html#1 360/370
http://www.garlic.com/~lynn/98.html#34 ... cics ... from posting from another list
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#36 why is there an "@" key?
http://www.garlic.com/~lynn/99.html#110 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/subindex.html#mainframe Mainframe related postings (1993-2000)
http://www.garlic.com/~lynn/subindex.html#all Collected subjects (1993-2000)
http://www.garlic.com/~lynn/subtopic.html#wsclock Working Set, LRU, WSClock Page Replacement Algorithm
http://www.garlic.com/~lynn/subtopic.html#fairshare Performance and/or Scheduling
http://www.garlic.com/~lynn/subtopic.html#smp Multiprocessor, tightly-coupled, SMP, compare&swap
http://www.garlic.com/~lynn/subtopic.html#xtphsp OSI and High Speed Protocol
http://www.garlic.com/~lynn/subtopic.html#360mcode 360/370 m'code
http://www.garlic.com/~lynn/2000.html#29 Operating systems, guest and actual
http://www.garlic.com/~lynn/2000.html#90 Ux's good points.
http://www.garlic.com/~lynn/2000b.html#37 How to learn assembler language for OS/390 ?
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000c.html#83 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#20 S/360 development burnout?
http://www.garlic.com/~lynn/2000d.html#82 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2000e.html#52 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000e.html#53 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000e.html#57 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001d.html#54 VM & VSE news
http://www.garlic.com/~lynn/2001d.html#63 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#65 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#67 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#68 I/O contention
http://www.garlic.com/~lynn/2001e.html#9 MIP rating on old S/370s
http://www.garlic.com/~lynn/2001e.html#13 High Level Language Systems was Re: computer books/authors (Re: FA:
http://www.garlic.com/~lynn/2001f.html#2 Mysterious Prefixes
http://www.garlic.com/~lynn/2001g.html#29 any 70's era supercomputers that ran as slow as today's  supercomputers?
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#45 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
http://www.garlic.com/~lynn/2001h.html#76 Other oddball IBM System 360's ?
http://www.garlic.com/~lynn/2001i.html#2 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2001i.html#3 Most complex instructions (was Re: IBM 9020 FAA/ATC Systems from 1960's)
http://www.garlic.com/~lynn/2001i.html#13 GETMAIN R/RU (was: An IEABRC Adventure)
http://www.garlic.com/~lynn/2001i.html#42 Question re: Size of Swap File
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001j.html#48 Pentium 4 SMT "Hyperthreading"
http://www.garlic.com/~lynn/2001l.html#14 mainframe question
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2001l.html#41 mainframe question
http://www.garlic.com/~lynn/2001l.html#55 mainframe question
http://www.garlic.com/~lynn/2001m.html#12 Multics Nostalgia

misc middle layer/middleware refs:
http://www.garlic.com/~lynn/96.html#16 middle layer
http://www.garlic.com/~lynn/96.html#17 middle layer
http://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/99.html#124 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/99.html#201 Middleware - where did that come from?
http://www.garlic.com/~lynn/99.html#202 Middleware - where did that come from?
http://www.garlic.com/~lynn/subindex.html#all Collected subjects (1993-2000)
http://www.garlic.com/~lynn/subtopic.html#hacmp Cluster, High Availability and/or Loosely-Coupled
http://www.garlic.com/~lynn/subtopic.html#hsdt HSDT and/or HYPERChannel
http://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001j.html#4 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit

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

mainframe question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: mainframe question
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Sun, 04 Nov 2001 23:51:40 GMT

shannon@daydream.shannon.net (Charles Shannon Hendrix) writes:

The primary problem, IMHO, was leadership from American and British
officers.  They were so out of touch it's hard to believe they were in
command.  What should have followed from this was feeback to create a
better unit, or modify the Sherman to account for knowledge gained.
This is exactly what happened with the P-51 Mustang, and should have
been the norm for tanks too, perhaps even moreso because the lead time
from design to production is much shorter than with airplanes (at
least at that time).

there are other studies regarding allies in wwII ... or at least the
americans ... they had to go from almost zero and crank out large
numbers to put in the field. Not only was it a logistic strategy with
massive amounts of resources ... but (relatively) massive numbers of
inexperienced and quickly trained people.

Part of the solution was a very rigid, top-down command and control
structure. There was some number that the percentage of officers was
five times higher in the US armed forces. This approach addressed
management of huge logistic resources but also huge amounts of
inexperienced personel. One of the issues was that once in place ...
it was difficult to convert to a more agile & flexible C&C structure
(just because the people on the front were gaining experience?). In
fact, some study from the '70s & '80s claimed that part of american
corporate business problems were that the young officers that learned
their organizational skills in the ww-ii rigid, top-down, command &
control structure were starting to populate the CEO ranks and putting
into practice what they had been taught 30-40 years earlier.

One of the studies contrasted the top-heavy allied rigid
command&control structure (decisions are made at as high a level
possible) with the blitzkreig ... and guderian's verbal orders
only. The idea was that the guy on the spot made the decision and
didn't have to worry later about people judging whether it was right
or not. There is this joke that somewhat applies about one of the
definition of auditors ... they are the people that go around the
battlefield after the war, stabbing the wounded.

and of course ... boyd reference
http://www.garlic.com/~lynn/subtopic.html#boyd

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

3270 protocol

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 3270 protocol
Newsgroups: alt.folklore.computers
Date: Mon, 05 Nov 2001 04:11:40 GMT

finally stumbled across a reference.

ANR was the 3272/3277 protocol ... where most of the smarts were in
the display head.

DCA was the 3274/3278/3279/etc protocol ... where most of the smarts
had been moved back in the controller.

The problem when they were coming up with the 3270PC (and various
other pc 3270 coax) was that with things like file transfers (and/or
large data movements), ANR had three times the thruput of DCA.  Part
of the problem was that since all the smarts had been moved back into
controller for DCA ... there was huge amounts of protocol chatter with
DCA (for instance controller had to constantly poll the keyboard for
each key up/down operation).

There was then an effort to revise DCA in order to try and improve
things to be compareable to ANR thruput.

random 3270 refs:
http://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
http://www.garlic.com/~lynn/96.html#41 IBM 4361 CPU technology
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/98.html#56 Earliest memories of "Adventure"  & "Trek"
http://www.garlic.com/~lynn/99.html#26 IBM S/360
http://www.garlic.com/~lynn/99.html#28 IBM S/360
http://www.garlic.com/~lynn/99.html#60 Living legends
http://www.garlic.com/~lynn/99.html#61 Living legends
http://www.garlic.com/~lynn/99.html#69 System/1 ?
http://www.garlic.com/~lynn/99.html#108 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/2000.html#6 Computer of the century
http://www.garlic.com/~lynn/2000.html#90 Ux's good points.
http://www.garlic.com/~lynn/2000b.html#49 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#50 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#63 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000e.html#32 Tektronics Storage Tube Terminals
http://www.garlic.com/~lynn/2000e.html#53 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000e.html#56 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000g.html#17 IBM's mess (was: Re: What the hell is an MSX?)
http://www.garlic.com/~lynn/2001b.html#49 PC Keyboard Relics
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001f.html#8 Theo Alkema
http://www.garlic.com/~lynn/2001f.html#9 Theo Alkema
http://www.garlic.com/~lynn/2001f.html#28 IBM's "VM for the PC" c.1984??
http://www.garlic.com/~lynn/2001f.html#57 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001i.html#18 History of Microsoft Word (and wordprocessing in general)
http://www.garlic.com/~lynn/2001k.html#30 3270 protocol
http://www.garlic.com/~lynn/2001k.html#33 3270 protocol
http://www.garlic.com/~lynn/2001k.html#38 3270 protocol
http://www.garlic.com/~lynn/2001k.html#44 3270 protocol
http://www.garlic.com/~lynn/2001k.html#46 3270 protocol
http://www.garlic.com/~lynn/2001l.html#14 mainframe question
http://www.garlic.com/~lynn/2001l.html#62 ASR33/35 Controls
http://www.garlic.com/~lynn/2001m.html#1 ASR33/35 Controls

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

mainframe question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: mainframe question
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Tue, 06 Nov 2001 06:45:07 GMT

Charles Richmond writes:

I worked with a guy who used to work for General Dynamics when
GD was building the F-111. His job was engine test...they would
strap down an engine and see how much they could get out of it.
This guy said that if you fully opened the throttle on the F-111,
the engine would literally tear the plane apart. I am not sure
about fuel consumption, but evidently they had all the horsepower
they needed...

& a boyd/f-111 story
http://www.codeonemagazine.com/archives/1997/articles/jul_97/july2a_97.html

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

3270 protocol

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 3270 protocol
Newsgroups: alt.folklore.computers
Date: Wed, 07 Nov 2001 05:18:54 GMT

Anne & Lynn Wheeler writes:

The problem when they were coming up with the 3270PC (and various
other pc 3270 coax) was that with things like file transfers (and/or
large data movements), ANR had three times the thruput of DCA.  Part
of the problem was that since all the smarts had been moved back into
controller for DCA ... there was huge amounts of protocol chatter with
DCA (for instance controller had to constantly poll the keyboard for
each key up/down operation).

The attached is from a report on how 3274 controllers make it
impossible to achieve a reasonable "response time" objective of an
avg. of .25 seconds for trivial interactive response.

Avg. trivial interactive response in the '70s and '80s was frequently
measured in terms of avg. system service time; i.e. from the time the
hardware interrupt was presented to the system until the system
serviced the request and wrote a response.

In the 3270 case, block transmission of complete screens and the
3272/3277 was pretty insensitve to partial or complete screen block
transfers. The difference in transmission times between 1byte, 1000
bytes, or 2000 bytes was relatively inconsequential at several hundred
kilobytes per second. Hardware terminal service time was dominated by
controller processing, not bandwidth transmission.

At some point during this analysis I received an email from an MVS
system programmer telling me that I should stop making comments about
how bad TSO response was; that he had tuned a lightly loaded MVS/TSO
system and was capable of (outstanding) avg. 1 second average response
for trivial interactive operations.

By comparison, it wasn't too unusual for well, tuned, large, heavily
loaded VM/CMS systems to avg. .25 seconds for trivial interactive
response. In addition, I was able with some additional special tuning
to cut that in half. For nearly identical workload that many systems
were getting .25sec avg. trivial interactive response, I was able to
show .11sec avg trivial interactive response (similar hardware and
workload).

Note that that is just the system service time, the terminal hardware
service time would have to be added to get the actual end-user
perceived response.

Using the 3272 and 3274 hardware service numbers and adding them to
typical system service times for the end-user perceived response.

               hardware     TSO 1sec.    CMS .25sec.     CMS .11sec.
3272/3277        .086        1.086         .336            .196
3274/3278        .530        1.530         .78             .64

And then if you are talking about SNA attached controllers the
hardware service time will start to dwarf even TSO service times.

=================== start extract ====================

Applications developed for the 3272 will run un-modified on the 3274
but with substantially longer response times.  Service time is 3-8
times that of the 3272.

Quarter second response time objectives CANNOT be
achieved using 3274 model D control units in the local environment. If
the terminals are remote transmission time to the TP link will add to
the system response time.

Some simple data streams

Data        3272         3274
Stream      3277         3278

 A          .086         .283
 C          .086         .530

If the new 3274 functions (color, highlighting and larger character
formats) are used then response times are increased still further.

==================== end extract ============================

A little discussion of the CERN CMS/TSO benchmark/bake-off:
http://www.garlic.com/~lynn/98.html#28 Drive letters
http://www.garlic.com/~lynn/2000f.html#61 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001h.html#11 checking some myths.
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?

Some aspects of MVS contributing to TSO performance
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)

Some HYPERChannel/3270 discussion
http://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2001k.html#46 3270 protocol

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

Problem with inserting signatures

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Problem with inserting signatures
Newsgroups: gnu.emacs.gnus
Date: Fri, 09 Nov 2001 14:29:45 GMT

baskruit@bsltwr.dnsalias.org (S. Kruit) writes:

Hello,

after upgrading to emacs 21.1.1, I've problems with inserting
signatures with gnus (v5.9.0, as included with 21.1.1)

similar thread earlier this year ... selecting a random signature:
http://www.garlic.com/~lynn/2001b.html#77 Inserting autom. random signature
http://www.garlic.com/~lynn/2001b.html#78 Inserting autom. random signature

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

misc. SSL

Date:Thu, 8 Nov 2001 20:48:28 -0700
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: misc. SSL
Newsgroups: bit.listserv.vmesa-l

At 12:01 AM 11/7/2001 -0600, wrote:

SSL does do authentication.  It authenticates the server to
the client, which is backwards from what most folks expect
and from what Mike Walter needs for his application.  But
it can also authenticate the client to the server, through
the use of the optional "client certificate" facility.  If
the server requests the client's certificate during the
initial handshake, the client can choose to provide one or
not.  In Mike's case, the client doesn't sound like a web
browser, but it might still support client certificate
requests.

minor point ... SSL has option for mutual authentication but there isn't a
lot of it. The default SSL is that the code compares what the domain name
part of what a client entered as a URL with what is in the certificate. The
purported purpose of this is a possible weakness in the domain name
infrastructure where somebody specified a web site and because of an
exploit in the domain name system they were redirected to some fraudulent
server/ip-address (i.e. it authenticates that a domain name specified in a
URL ... either typed or clicked on ... matches the domain name in the
certificate).

misc. ref:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

with regard to webserver authentication of clients .... most servers have
some sort of stub code. Frequently an installation writes some sort of
local implementation .... this many times results in roll-your-own code
with flat-file type of implementation with userid/passwords. However,
probably 99.9999 percent of the client authentication that goes on in the
internet world today involves RADIUS. RADIUS supports both authentication &
authorization features with options for userid/password and
challenge/response. Two suggestions are that 1) webservers provide RADIUS
stub code options for client authentication and 2) RADIUS be enhanced with
more types of authentication processes .... including digital signature
authentication options. Using that platform approach would allow a
corporation, enterprise, and/or service to put its authentication
infrastructure under a consistent administrative operation.

misc. ref:
http://www.garlic.com/~lynn/subtopic.html#radius

for more detailed specification of internet standards TLS (standard name
for SSL) and RADIUS go to
http://www.garlic.com/~lynn/rfcietff.htm

and click on "TERM (term -> RFC#)" and from that screen your can
select  "TLS" &/or "RADIUS" from the acronym section. Selecting either one
witll give all the associated internet standards (RFCs) i.e.

remote authentication dial in user service (RADIUS )
     see also authentication , network access server , network services
     3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139
     2138 2059 2058

transport layer security (TLS )
     see also encryption , security
     2847 2830 2818 2817 2716 2712 2595 2487 2246

selecting the individual RFC numbers will bring up more relevant
information about the specific RFC. In the information about the specific
RFC ... selecting the ".txt=nnnn" field will retrieve the actual RFC.

--
Anne & Lynn Wheeler      lynn@garlic.com,  http://www.garlic.com/~lynn/

When did full-screen come to VM/370?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: When did full-screen come to VM/370?
Newsgroups: alt.folklore.computers
Date: Tue, 13 Nov 2001 15:59:23 GMT

"John Lynn" writes:

Anyone know when the pieces came to support the creation of "full-screen"
3270 programs on VM/370? I know about diag 58, but I'm not sure when it came
into vogue totally; and wasn't there another way of doing full-screen
programs before diag 58? Thanks for any pointers...

as an undergraduate ... the university I was at had a channel attach
2250m1 (graphics display). I had taken a cms 2250 library from lincoln
labs and interface the cms editor to produce somewhat full-screen
operation (for output only). This would have been about mid-68.

For the 3270 ... I'm not positive ... but I think that the first was
the edgar editor that was specifically 3270, had full-screen layout
and full-screen "input" (i.e. before that there was simulated
fullscreen output with writing multiple lines to fill the screen
... but no provisions for "real" full-screen read ... the whole screen
could be used for input, and during "editing" text displayed anywhere
on the screen could be modified/replaced). Edgar also had portion of
each display line (during edit) reserved for meta commands (i.e. when
enter was hit ... each line that had a "d" in the corresponding
meta-area would be deleted).

However, edgar also started the scroll up/down wars. It had a
convention that scroll-down moved the display "cursor" (position in
the file) towards the beginning of the file i.e. reference point was
from the stand-point of the program that would move a scroll of text
downward past a window (which moved the cursor/reference towards the
beginning of the file).  The counter argument was that implementing a
"human" reference point (as opposed to a program's reference) ... with
regard to scroll up/down would be with respect to what the person that
was up/down aka rather than the text being scrolled up/down past the
window ... the window would "move" up/down in the file with respect to
the human orientation.

The standard CMS editor then got incrementally enhanced with respect
to full-screen capability ... and various other editors appeared NED,
RED, and eventually XEDIT. The disquishing characteristics after EDGAR
wasn't so much in their full-screen characteristics but in their macro
& scripting features which got more & more sophisticated.

random refs:
http://www.garlic.com/~lynn/94.html#2 Schedulers
http://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
http://www.garlic.com/~lynn/97.html#2 IBM 1130 (was Re: IBM 7090--used for business or science?)
http://www.garlic.com/~lynn/97.html#9 HELP! Chronology of word-processing
http://www.garlic.com/~lynn/99.html#41 A word processor from 1960
http://www.garlic.com/~lynn/99.html#109 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/2000b.html#20 How many Megaflops and when?
http://www.garlic.com/~lynn/2000c.html#63 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2001b.html#12 Now early Arpanet security
http://www.garlic.com/~lynn/2001b.html#14 IBM's announcement on RVAs
http://www.garlic.com/~lynn/2001b.html#71 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001f.html#57 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001i.html#1 History of Microsoft Word (and wordprocessing in general)
http://www.garlic.com/~lynn/2001i.html#17 History of Microsoft Word (and wordprocessing in general)
http://www.garlic.com/~lynn/2001k.html#44 3270 protocol

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

Smallest Storage Capacity Hard Disk?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Smallest Storage Capacity Hard Disk?
Newsgroups: alt.folklore.computers
Date: Tue, 13 Nov 2001 17:35:23 GMT

Kevin Handy writes:

And, that 1.2 gig of disk was probably not on a single drive.

well in 68 it wasn't on a signle drive ... but by early '80s it was
getting much closes (20.1g/32) ... and by the time of triple density
3380s in the mid-80s it would have been 3*630 ... nearly 2gbyte/drive

                2305    2314    3310    3330    3350    3370    3380

data
cap, mb         11.2    29      64      200     317     285     630
avg. arm
acc, ms         0       60      27      30      25      20      16
avg. rot
del. ms         5       12.5    9.6     8.4     8.4     10.1    8.3

misc. comparison
http://www.garlic.com/~lynn/95.html#8 3330 Disk Drives
http://www.garlic.com/~lynn/99.html#6 3330 Disk Drives

system          3.1L            HPO     change
machine         360/67          3081K

mips            .3              14      47
pageable pages  105             7000    66
users           80              320     4
channels        6               24      4
drums           12meg           72meg   6
page I/O        150             600     4
user I/O        100             300     3
disk arms       45              32      4?perform.
bytes/arm       29meg           630meg  23
avg. arm access 60mill          16mill  3.7
transfer rate   .3meg           3meg    10
total data      1.2gig          20.1gig 18

Comparison of 3.1L 67 and HPO 3081k

67/3081 refs:
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001f.html#68 Q: Merced a flop or not?
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)

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

Smallest Storage Capacity Hard Disk?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Smallest Storage Capacity Hard Disk?
Newsgroups: alt.folklore.computers
Date: Tue, 13 Nov 2001 18:23:20 GMT

Anne & Lynn Wheeler writes:

well in 68 it wasn't on a signle drive ... but by early '80s it was
getting much closes (20.1g/32) ... and by the time of triple density
3380s in the mid-80s it would have been 3630 ... nearly 2gbyte/drive

and the double density 3380 (that came between the two) would have been
just slightly over 1.2gbyte.

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

ESCON Data Transfer Rate

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ESCON Data Transfer Rate
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 13 Nov 2001 18:51:25 GMT

dbrazzi@BERKSHIRELIFE.COM (Dominique Brazziel) writes:

What is the maximum data transfer rate for an ESCON channel, and where is
the specification?  I checked the ESCON I/O Interface manual but couldn't
find any hard numbers for transfer rate.

fiber/escon was kicking around since sometime in the '70s
... basically using fairly expensive drivers and operating at
200mbit/sec. If you take out the encoding overhead it drops it to
something over 17mbytes/sec. If you take out various other
higher-level protocol the actual sustain data is somewhat less.

In the '80s rochester/austin basically took the escon specification
and revamped it slightly to something called the serial link adapter
running at 220mbits/sec (10 percent faster than escon) and substituted
inexpensive CDROM-derived optical drivers.

Around 1990, the push for doing a 800mbit/sec SLA got redirected into
fiber-channel standards body activity for 1gbit/sec technology. The
original work done on FCS was by Ancor and LLNL, somewhat as an
outgrowth of a Ancor project at LLNL in high-speed non-blocking
switch.

FCS is full-duplex protocols.

The other activity in the era was HiPPI ... which was basically driven
by LANL (FCS driven by LLNL & HiPPI driven by LANL) to effectively
standardize the Cray channel ... a 800mbit/sec, half-duplex copper
implementation. There was some cross-over between the FCS & HiPPI
camps with similar drivers being used for things like fiber HiPPI
channel extenders.

There was a project that attached a HiPPI channel to a 3090. However,
the 3090 I/O interface had insufficient bandwidth to handle HiPPI
channel .... so it was sort-of glued into the extended store interface
of the 3090. Then rather than doing I/O per se ... it was more like PC
memory-mapped I/O ... there were reserved addresses in extended store
that were used to place HiPPI commands.

However, at that point, it was then possible to attach some of the
common 40mbyte/sec disk arrays. One of the problems that the Kingston
engineering and scientific lab had during the mid-80s was they had
20-40 FPS boxes tied to a 3090 for numerical instensive applications.
The FPS boxes could be configured with 512mbyte real storage and used
40mbyte/sec transfer disk arrays. An issue was how to allow the 3090
to access the same or similar medium speed devices.

random refs:
http://www.garlic.com/~lynn/94.html#2 Schedulers
http://www.garlic.com/~lynn/94.html#16 Dual-ported disks?
http://www.garlic.com/~lynn/94.html#17 Dual-ported disks?
http://www.garlic.com/~lynn/94.html#54 How Do the Old Mainframes
http://www.garlic.com/~lynn/95.html#13 SSA
http://www.garlic.com/~lynn/96.html#5 360 "channels" and "multiplexers"?
http://www.garlic.com/~lynn/96.html#15 tcp/ip
http://www.garlic.com/~lynn/98.html#58 Reliability and SMPs
http://www.garlic.com/~lynn/99.html#217 AADS/X9.59 demo & standards at BAI (world-wide retail banking) show
http://www.garlic.com/~lynn/99.html#224 X9.59/AADS announcement at BAI this week
http://www.garlic.com/~lynn/2000.html#1 Computer of the century
http://www.garlic.com/~lynn/2000c.html#56 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#74 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#14 FW: RS6000 vs IBM Mainframe
http://www.garlic.com/~lynn/2000d.html#38 S/360 development burnout?
http://www.garlic.com/~lynn/2000e.html#52 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000f.html#28 OT?
http://www.garlic.com/~lynn/2000f.html#31 OT?
http://www.garlic.com/~lynn/2000f.html#72 SET; was Re: Why trust root CAs ?
http://www.garlic.com/~lynn/2001.html#12 Small IBM shops
http://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001.html#46 Small IBM shops
http://www.garlic.com/~lynn/2001.html#66 what is interrupt mask register?
http://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001b.html#56 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001b.html#85 what makes a cpu fast
http://www.garlic.com/~lynn/2001d.html#32 Imitation...
http://www.garlic.com/~lynn/2001d.html#63 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#65 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#22 High Level Language Systems was Re: computer books/authors (Re: FA:
http://www.garlic.com/~lynn/2001f.html#66 commodity storage servers
http://www.garlic.com/~lynn/2001g.html#43 The Alpha/IA64 Hybrid
http://www.garlic.com/~lynn/2001h.html#57 Whom Do Programmers Admire Now???
http://www.garlic.com/~lynn/2001i.html#6 YKYGOW...
http://www.garlic.com/~lynn/2001j.html#9 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#22 ESCON Channel Limits
http://www.garlic.com/~lynn/2001k.html#73 Expanded Storage?
http://www.garlic.com/~lynn/2001k.html#74 Expanded Storage?
http://www.garlic.com/~lynn/2001l.html#14 mainframe question

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

Call for folklore - was Re: So it's cyclical.

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Call for folklore - was Re: So it's cyclical.
Newsgroups: alt.folklore.computers
Date: Wed, 14 Nov 2001 22:00:01 GMT

"Charlie Gibbs" writes:

Of course, the domain-specific language of the week is great for
the vendor who's selling it.  Planned obsolescence is everywhere.
If a programmer's knowledge conflicts with the New Paradigm [tm],
simply invalidate his knowledge, and he'll be no better off (i.e.
no more powerful or threatening) than any of the other sheep.

some number of the useful application out there .... aren't a domain
specific language creation ... it was a domain expert who had enuf
insight into the problem and also could program (in whatever). There
is more than a little bit of wishful thinking regarding
domain-specific language being able to compensate for lack of domain
expert and/or domain-specific knowledge.

on the other hand ... domain-specific paradigms/applications have been
known to take-off ... spread-sheet being one ... its paradigm matched
very well with processes performed by accountants and financial types
(using traditional balance sheets).

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

Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
Newsgroups: comp.security.misc
Date: Thu, 15 Nov 2001 16:27:27 GMT

The current Internet is like a street system in a large city with very
few traffic rules, no traffic signs, no traffic lights and little or
no enforcement (i.e. anarchy and chaos).

One of the suggestions was that ISPs filter/discard incoming packets
from customers where the from address didn't correspond to the IP
subnet address(es) assigned to that customer (there are a few
exceptions, but very few). That would have minimized the majority of
the anonymous attacks. A problem at the time (I brought this up in Aug
1995) was that few of the commonly used routers by ISPs were capable
of handling the filtering load.

Most ISPs these days have policy and practices rules about normal
dial-up customers operating various kinds of servers (like HTTP). A
simple way of enforcingq such rules is to discard packets addressed to
such customers that are for all the standard server ports. Such a
practice would also minimize some number of the current attacks.

I currently have a dial-up account that is a flat monthly fee, except
if I happen to have greater than one active connection, in which case
I'm charged for the additional(s) connections on a per minute basis.
Given that anonymous and spoofed packets are significantly minimize,
then it becomes much more predictable where packets have
originated. Various packet discarding enforcement activity could be
funded out of additional fees charged back to their originator
(including customers attempting to originate anonymous and/or spoofed
packets). This would somewhat assume the role of minor traffic fines.

Part of the issue is that there is so much anarchy, an excuse by many
vendors not to improve their contribution to the problem is that any
one such change wouldn't improve the overall situation very
significantly.

Prior to the more recent rash of scripting exploits and attacks one of
the most frequent types of exploits involved some form of buffer
overrun. Buffer overrun exploits have been overtaken by various kinds
of scripting exploits (computing products that can automatically
execute various instructions that could have arrived from the
internet).

I would claim that better being able to identify all packet origins
along with internet traffic fines has a second order
deterance. Customers vulnerable to such activity not under their
direct control will place increased pressure on the vendors that they
obtain their products from. The analogy here is safe operating
vehicles. Habitual offenders would have increased fines because of
operating unsafe vehicles. This will also increase the back-pressure
on vendors to improve their products.

There is also the possibility of accident insurance to cover losses.
The second order effect of such insurance operations is that they tend
to publish statistics about safe and unsafe operations and adjust
their premiums accordingly. This tends to direct consumers towards
safer products (and also provide motivation for product improvements).

RFC references:
2827
     Network Ingress Filtering: Defeating Denial of Service Attacks
     which employ IP Source Address Spoofing, Ferguson P., Senie D.,
     2000/05/16 (10pp) (.txt=21258) (BCP-38) (Obsoletes 2267)
3013
     Recommended Internet Service Provider Security Services and
     Procedures, Killalea T., 2000/11/30 (13pp) (.txt=27905) (BCP-46)
3168
     The Addition of Explicit Congestion Notification (ECN) to IP,
     Black D., Floyd S., Ramakrishnan K., 2001/09/14 (63pp)
     (.txt=170966) (Obsoletes 2481) (Updates 793, 2401, 2474)

for more detailed RFC index ... see
http://www.garlic.com/~lynn/rfcietff.htm

random refs:
http://www.garlic.com/~lynn/99.html#48 Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
http://www.garlic.com/~lynn/99.html#85 Perfect Code
http://www.garlic.com/~lynn/99.html#160 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#163 IBM Assembler 101
http://www.garlic.com/~lynn/99.html#165 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#166 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#219 Study says buffer overflow is most common security bug
http://www.garlic.com/~lynn/2000.html#25 Computer of the century
http://www.garlic.com/~lynn/2000.html#30 Computer of the century
http://www.garlic.com/~lynn/2000b.html#17 ooh, a real flamewar :)
http://www.garlic.com/~lynn/2000b.html#22 ooh, a real flamewar :)
http://www.garlic.com/~lynn/2000b.html#60 South San Jose (was Tysons Corner, Virginia)
http://www.garlic.com/~lynn/2000c.html#40 Domainatrix - the final word
http://www.garlic.com/~lynn/2000c.html#70 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000g.html#50 Egghead cracked, MS IIS again
http://www.garlic.com/~lynn/2001b.html#47 what is interrupt mask register?
http://www.garlic.com/~lynn/2001b.html#58 Checkpoint better than PIX or vice versa???
http://www.garlic.com/~lynn/2001c.html#8 Server authentication
http://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#66 KI-10 vs. IBM at Rutgers
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001d.html#58 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001e.html#40 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001g.html#16 Root certificates
http://www.garlic.com/~lynn/2001i.html#52 misc loosely-coupled, sysplex, cluster, supercomputer, & electronic commerce
http://www.garlic.com/~lynn/2001i.html#54 Computer security: The Future
http://www.garlic.com/~lynn/2001k.html#43 Why is UNIX semi-immune to viral infection?
http://www.garlic.com/~lynn/2001l.html#49 Virus propagation risks

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

Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet like city w/o traffic rules, traffic signs, traffic lights  and traffic enforcement
Newsgroups: comp.security.misc
Date: Fri, 16 Nov 2001 00:17:51 GMT

Nick Hilliard <nick@foobar#delete2email#.org> writes:

I'm not going to argue that core routers should have filters today, because
that's just the wrong place to do it. However, edge filtering is still quite
feasible in most circumstances, and the limiting factor in its widespread
implementation is not performance impact or router load, but rather laziness
and/or ignorance.  There are a few instances where is really isn't easy /
possible.  But for the most part, it's not hugely difficult.

the vast majority of various kinds of attacks that I see are all
coming from dial-up lines and furthermore, large majority of ISPs have
policy and practice staements regarding running "servers" off of
dial-up service (i.e. getting a dial-up line and trying to keep up for
extended periods of time). Some amount of the anonymity attacks are
also done from dial-up connections as an extra level of indirection.

Going to both in-coming filtering as well as some of the most common
outgoing filtering on the dial-up accounts (where some of these
service things are already prohibited) would help situation a great
deal. Of course it doesn't eliminate all possible conditions
... anymore than traffic lights eliminate people running redlights
... but adding a lot of structure in most of the places makes it
simpler to start focusing on the remaining situations. Violations
could also be treated by ISPs with extra service charges ... analogous
to minor traffic fines (which would help cover the cost and overhead
... somewhat in the example where an ISP on flat-rate monthly ... if
they see concurrent connection for same account).

By far the largest majority of probes/attacks I've been seeing appear
to be coming from dial-up accounts. Dial-up would also appear to
involve some of the least sophisticated and therefor most vulnerable
to compromise. Either the account holders ... and/or the vendors of
products that they use need to get fines for unsafe equipment. Using
the traffic analogy ... operator of unsafe equipment get fines whether
they know anything about the equipment or not, produces of unsafe
equipment tend to get even larger fines. Also insurance to cover
various kinds of accidents (compromise) is higher if operator
equipment that is considered significantly less safe.

ISPs that don't play could loose some of the peering privilege. In any
case, considering that I'm seeing possibly a 100 times more probes now
than a year ago ... there is an obvious traffic problem; too much
chaos, too many accidents, etc. Additional structure obviously has to
be put into place even if there are a large number of redlight runners
that wouldn't be caught day one.

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

Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
Newsgroups: comp.security.misc
Date: Fri, 16 Nov 2001 00:30:07 GMT

Todd Knarr writes:

I beg to differ. Most routers used by ISPs can handle the load with
ease. Remember that such filters aren't applied at the interface between
the ISP and the backbone, but at the interface between the customer's
network ( which consists of relatively few, as far as routers are
concerned, netblocks ) and the ISP's network. This minimizes the number
of filter rules, since that router doesn't care about any netblocks not
directly connected to it.

besides the processing load ... the other problem was that the
filtering rules in the most commonly deployed router was egregously
complex ... one of the most common problems of the time was that the
intent of the person specifying the rules was inverted (management of
filtering rules frequently resulted in the wrong thing happening).

however, starting on the edge with incoming spoofing being discarded
... even if it started with just the dial-up pool shouldn't be very
difficult. Improving the structure to preclude a number of the
ip-layer things is a start for catching operators of unsafe equipment
(at least being able to distinquish between the crowd of cars in the
intersection vis-a-vis everybody running the redlights).

Still leaves many of the other categories.

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

Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
Newsgroups: comp.security.misc
Date: Fri, 16 Nov 2001 14:50:53 GMT

jwmeritt@aol.com (JWMeritt) writes:

I sorta like the comparison to "the wild, wild west."

lets say it was more like a sleepy little village, a few vehicles,
never been an accident, never been a theft, and never been any
vandelism. None of the vehicles had keys or locks. And then there was
this huge populatio explosion.

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

Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Internet like city w/o traffic rules, traffic signs, traffic lights   and traffic enforcement
Newsgroups: comp.security.misc
Date: Fri, 16 Nov 2001 17:19:36 GMT

Gary Flynn writes:

The key in this scenario is defining "unsafe". Certainly defective
software would fall into that category. But I'd be very hesitant
about including operating system and application features that are
meant to provide ease of use, easy access, and functionality to
the user of the device as others have suggested. After all,
the market demanded a general purpose, programmable computer
so they could use it for what they want. We've provided highly
complex, highly functional operating systems to the mass market
and told them they're plug-n-play. Click a mouse and execute
50,000 lines of code. I don't think its the vendor's fault for
providing what the market wanted nor the end user's fault for
not realizing the implications of getting what they asked for :)

this was also somewhat the anti seat-belt & anti helmet arguments.

what i didn't understand was some of the deep-pocket court things
... if somebody stole the stop sign ... the gov. was liable for the
accident;

or if there was an accident that took out a guard rail ... and then
within very short time another accident that went thru the opening ...
then gov. agency was at fault for not having an instantaneous, zero
elapsed time guard rail replacement.

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

Number of combinations in five digit lock? (or: Help, my brain hurts)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Number of combinations in five digit lock? (or: Help, my brain hurts)
Newsgroups: sci.crypt
Date: Sun, 18 Nov 2001 18:10:37 GMT

foobmail@yahoo.co.uk (foob) writes:

This type of lock operates as follows:
- there are 5 mechanical buttons (1,2,3,4,5)
- once a button is pressed it cannot be pressed again
- the combination is made of a sequence of presses, not necessarily
containing all buttons (but at least one button must be pressed)
- multiple buttons can be pressed at the same time for any step of the
sequence.

misc:

a) for the simple case of pressing all buttons only once each, one at a time

1 button is 1   or 1

2 button is 1-2, 2-1, or 2

3 button is 1-2-3, 1-3-2, 2-1-3, 2-3-1, 3-1-2, 3-2-1, or 6  .. possibly n(n-1) or n!

4 button is 1-2-3-4, 1-2-4-3, 1-3-2-4, 1-3-4-2, 1-4-2-3, 1-4-3-2
      there are six possible combinations for pressing button 1 first
      there are also six possible combinatioons for pressing any of the
      other buttons first  or 46 = 432 = 24  ... n! combinations

5 button there are 24 combinations for each of the five possible buttons pressed first
      or 524 = 5432 = 120 ... or n!

b) subset of buttons being pressed

for 5 button case:

any single button pressed:  5
any two buttons pressed:    1-2, 2-1, 1-3, 3-1, 1-4, 4-1, 1-5, 5-1
                            2-3, 3-2, 2-4, 4-2, 2-5, 5-2
                            3-4, 4-3, 3-5, 5-3
                            4-5, 5-4
                            8+6+4+2; or 54, = 20
any three buttons pressed:  1-2-3, 1-3-2, 1-2-4, 1-4-2, 1-2-5, 1-5-2,
                            1-3-4, 1-4-3, 1-3-5, 1-5-3
                            1-4-5, 1-5-4
                            2-1-3, 2-3-1, 2-1-4, 2-4-1, 2-1-5, 2-5-1,
                            2-3-4, 2-4-3, 2-3-5, 2-5-3,
                            2-4-5, 2-5-4
                            ...
                            ...
                            512 = 543  = 60

=====================

So simple five button                   120
any single button                         5
any two buttons                          20
any three buttons                        60
                                       ----
                                        205

there is still the any four button case and the possible combinations of
buttons pushed simultaneous which break out into

any two simultaneously
any three simultaneously
any four simultaneously
all five simultaneously

any two simultanously plus one other
any two simultaneously plus two other
any two simultaneously plus three other
any two simultaneously plus two other simultaneously
any two simultaneously plus two other simultaneously plus one other
any two simultaneously plus three other simultaneously
...
..

so is this one of those homework problems????

random discussions of homework issues
http://www.garlic.com/~lynn/2000.html#28 Homework: Negative side of MVS?
http://www.garlic.com/~lynn/2000.html#32 Homework: Negative side of MVS?
http://www.garlic.com/~lynn/2001.html#70 what is interrupt mask register?
http://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
http://www.garlic.com/~lynn/2001c.html#11 Memory management - Page replacement
http://www.garlic.com/~lynn/2001c.html#25 Use of ICM
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#75 Disappointed
http://www.garlic.com/~lynn/2001l.html#0 Disappointed

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

XEDIT on MVS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: XEDIT on MVS
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 19 Nov 2001 16:20:45 GMT

dale.miller@NDCHEALTH.COM (Miller, Dale #PHX) writes:

use VM constructs?, and "Are you SURE you want to use VM constructs?", ad
nauseum. This would give you the privilege of using XEDIT, where, if you
change your mind, you would have to "QUIT" then respond "QQUIT", which means
"Yes, Dammit! I really meant to QUIT" instead of using the ISPF command
"CANCEL" .Enjoy!

then there is the story from Share when the executive in charge of
ISPF acquired responsibility for VM Performance products in the late
'70s.  The ISPF group had a couple hundred developers ... and the VM
Performance products had three developers ... but the two product sets
had about the same total revenue. It seemed that the revenue from the
VM performance products went a long way to helping his ISPF
development (and the three VM performance product developers made some
comments at share about difficulty in getting approval to work on vm
performance products).

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

9-track tapes (by the armful)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 9-track tapes (by the armful)
Newsgroups: alt.folklore.computers
Date: Tue, 20 Nov 2001 00:22:36 GMT

Arargh! writes:

I thought that 200 was low density :-)  There was also 556? and 800?
or some such in the 7 track drives.

from trusty green-card
http://www.garlic.com/~lynn/gcard.html#25 I/O Command Codes Magnetic-Tape

CCW op-code for 2400 tape drive:

   DDMMM011

where

  D  D
  ----
  0  0    200  7-track
  0  1    556  7-track
  1  0    800  7-track
  1  1    (set 9-track mode)

&

  M  M  M
  -------
  0  1  0     Set density, Set Odd Parity, Data converter on, translator off
  1  0  0     Set density, Set even parity, data converter off, translator off
  1  0  1     Set density, set even parity, data converter off, translator on
  1  1  0     Set density, set odd parity, data converter off, translator off
  1  1  1     set density, set odd partiy, data converter off, translator on

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

CA Certificate Built Into Browser Confuse Me

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CA Certificate Built Into Browser Confuse Me
Newsgroups: comp.security.misc
Date: Tue, 20 Nov 2001 17:48:35 GMT

"Ron Ayoub" writes:

One more short question. Is a certificate a digitally signed document
associating an entity with a public key or is it just the document not
necessarily have a signature? Some source seem to use both interchangeably?

Thanks very much. I think this would complete my BASIC understanding of how
SSL works.

a certificate is a digitally signed document. self-signing just
"proves" you possess the corresponding private key contained in the
certificate.

typically self-signed certificates are distributed by some process you
"trust" (aka you trust that the browser vendor has validated something
about the self-signed certificates that they include).

there is this trust chain thing ... you get a SSL server certificate, you then
trust

1) the CA vendor has proofed that the server owner has the
corresponding private key (by checking some self-signed something from
the SSL server owner prior to manufacturing a certificate)

2) the CA vendor has checked some other stuff that will be placed in
the certificate (like the CA has done some checking that the server
owner is also the domain name owner that gets stuffed in a SSL domain
name server certificate).

3) whole public key process

4) the SSL server certificate you received is validated by the CA
vendor public key

5) the CA self-signed certificate

6) the browser vendor to have only included valid self-signed CA
certificates

7) that the browser vendor has done some checking that included CA
certificates are associated with a valid CA that follows trusted
process when manufacturing and distributing trusted SSL certificates.

8) that the browswer SSL process that once all the certificate and
public key stuff is done ... that having SSL check that the domain
name in the typed-in URL is the same as the domain name contained in
the certificate ... is worth something.

some discussion of what certificates are included in netscape:
http://www.garlic.com/~lynn/aepay4.htm#comcert14 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert16 Merchant Comfort Certificates

additional discussions about some of the individual "trust" issues
listed above:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

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

Is OLTEP really dead?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is OLTEP really dead?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 20 Nov 2001 21:42:22 GMT

James.Urlaub@PCSHS.COM (Jim Urlaub) writes:

Note: it would probably be tough to find a card reader that would
read in a FRIEND card deck anyway.

you could always ipl FRIEND deck in a VM virtual card reader ... the
disk engineering labs (bldg 14) and product test labs (bldg 15) used
to do that a lot

random ref:
http://www.garlic.com/~lynn/subtopic.html#disk

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

CA Certificate Built Into Browser Confuse Me

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: CA Certificate Built Into Browser Confuse Me
Newsgroups: comp.security.misc
Date: Wed, 21 Nov 2001 00:16:47 GMT

alun@texis.com (Alun Jones) writes:

A self-signed certificate does not, as other people have suggested, guarantee
the data inside the certificate is correct.  I could generate a self-signed
certificate today that claimed I was the Pope, but unless you received the
certificate attached to an encyclical, you'd have no way of believing that for
sure.

by validating the signature with the public key (contained in the certificate)
can show that whoever signed the certificate posseses the corresponding
private key to the public key ... and that the contents of the certificate
has not been modified since it was signed.

it says nothing about the validity of the information in the
certificate at the time of the signing (other than the public key
matches the private key used for the signing) ... and the bits have
not been modified since the signing.

now the trust chain ... has people relying on the browser vendor to
have done due diligence on the CA vendor of the certificates that
have been included in the browser (and also that the browser received
by the end-user has not been changed/modified since the browser vendor
created it).

There are typically policy and practice statements regarding what a CA
vendor does before it manufactures a certificate (aka that an end-user
can trust that a standard certificate corresponds to the CA's policy
and practices) ... however I don't remember seeing any policy and
practice statements as to what due diligence a browser vendor
performs before including a self-signed CA certificate in their
browser ... and/or policy and practice statement by any handling of a
browser before delivery to an end-user (to make sure that included
certificates have not be changed).

One of the side interesting things to note is that nominally the
purpose of an SSL domain name certificate .... is so that a
client/end-user can have some confidence that the server it is talking
to is the same as the server that was typed in the URL (i.e. the
domain name from the typed-in URL is checked against the domain name
in the supplied certificate).

Now, assuming that the domain names match ... that implies that the CA
that manufactured the certificate has done some verification as to
whether the entity requesting the SSL domain name server is actually
the valid "owner" of the corresponding domain name.

The whole issue here is concern about the integrity of the domain name
infrastructure. Now do CAs normally have a list of every domain name
and the corresponding valid owners? Normally CAs have to check with
the domain name infrastructure as to the valid owner of the domain
name (i.e. the domain name infrastructure is the authoritative agency
that a CA validates the ownership of a domain name with before
manufacturing a requested certificate).

It turns out that there have indeed been some integrity issues with
the domain name infrastructure ... which affects both clients
requesting domain name to IP-address resolution as well as CAs
checking as to the true owner of a domain name.

As part of improving the overall integrity of the domain name
infrastructure, so that CAs can better trust the information (so that
clients can better trust the SSL domain name certificates) there has
been a proposal that domain name owners register their public keys at
the same time they register their domain name. Then all subsequent
domain name infrastructure transactions are done by digitally signing
them (the domain name infrastructure then can validate the digital
signatures ... not with certificates .... but with the public key
stored in the corresponding account record that was created when the
domain name was registered).

There is an interesting side effect here. The existing domain name
infrastructure can do real-time distribution of any information it has
related to a domain name .... not just ip-addresses. If a domain name
has a public key registered for it ... it is possible for the domain
name infrastructure to do a real-time distribution of that public key
at the same time it distributes the ip-addresses.

Now, the catch-22.

Partially as part of improving the domain name infrastructure trust
for use by CAs, there is a proposal to register domain name owner's
public keys.

The public key in an SSL domain name certificate was placed in that
certificate at the time the certificate was created (potentially a
year in the past) at the same time the CA checked with the domain name
infrastructure as to the validity of the domain name owner (i.e.
certificates are a method of securely distributing information, but is
a solution that may involve stale and old information).

Fixing the domain name infrastructure so that it can be better trusted
by CAs .... opens up an avenue for doing real-time trusted
distribution of public keys ... not requiring certificates and CAs.
The comparison is futher aggrevated by comparing the real-time
distribution of public keys thru the domain name infrastructure to the
possibly year-old (or more) distribution of potentially very stale
information using certificates.

random refs:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

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

CMS under MVS

Date: Wed, 21 Nov 2001 10:50:54 -0700
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: CMS under MVS
Newsgroups: bit.listserv.vmesa-l

I believe that SIE was originally for the VMTOOL (i.e. internal
development tool in POK supporting MVS/XA development) and possibility
of test MVS(s) on the