2001 Newsgroup postings (10/31 - 11/28) Lynn Wheeler

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

Refed: **, - **, - **

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 - https://www.garlic.com/~lynn/

ASR33/35 Controls

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://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
https://web.archive.org/web/20020220124741/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 - https://www.garlic.com/~lynn/

mainframe question

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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
https://www.garlic.com/~lynn/2000c.html#85 V-Man's Patton Quote (LONG) (Pronafity)
https://www.garlic.com/~lynn/2001.html#30 Review of Steve McConnell's AFTER THE GOLD RUSH

and
https://www.garlic.com/~lynn/subboyd.html#boyd

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

Smart Card vs. Magnetic Strip Market

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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:
https://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card fraud"
https://www.garlic.com/~lynn/aepay6.htm#ccfraud3 "out of control credit card fraud"
https://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit cards!

some discusson on offline/online transaction cost/price
https://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):
https://www.garlic.com/~lynn/x959.html#x959

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

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

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

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

Smart Card vs. Magnetic Strip Market

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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 ...
https://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 - https://www.garlic.com/~lynn/

Smart Card vs. Magnetic Strip Market

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://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 - https://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:
https://www.garlic.com/~lynn/subboyd.html#boyd

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

Smart Card vs. Magnetic Strip Market

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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.

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

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

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

mainframe question

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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
https://www.garlic.com/~lynn/2001m.html#3 mainframe question

https://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 - https://www.garlic.com/~lynn/

mainframe question

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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 - https://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)

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

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, HSDT email

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

mainframe question

Refed: **, - **, - **, - **

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 ...

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

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 - https://www.garlic.com/~lynn/

adventure ... nearly 20 years

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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 - https://www.garlic.com/~lynn/

departmental servers

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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:
https://www.garlic.com/~lynn/2001m.html#12 Multics Nostalgia

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

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, HSDT email

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 market 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 litany 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.
https://www.garlic.com/~lynn/subnetwork.html#3tier

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.

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

mainframe question

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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 blitzkrieg ... 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
https://www.garlic.com/~lynn/subboyd.html#boyd

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

3270 protocol

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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.

DFT 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 DFT. Part of the problem was that since all the smarts had been moved back into controller for DFT ... there was huge amounts of protocol chatter with DFT (for instance controller had to constantly poll the keyboard for each key up/down operation).

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

--
Anne & Lynn Wheeler | lynn@garlic.com - https://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 - https://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 DFT. Part of the problem was that since all the smarts had been moved back into controller for DFT ... there was huge amounts of protocol chatter with DFT (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 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:
https://www.garlic.com/~lynn/98.html#28 Drive letters
https://www.garlic.com/~lynn/2000f.html#61 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2001h.html#11 checking some myths.
https://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?

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

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

--
Anne & Lynn Wheeler | lynn@garlic.com - https://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:
https://www.garlic.com/~lynn/2001b.html#77 Inserting autom. random signature
https://www.garlic.com/~lynn/2001b.html#78 Inserting autom. random signature

--
Anne & Lynn Wheeler | lynn@garlic.com - https://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:
https://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:
https://www.garlic.com/~lynn/subpubkey.html#radius

for more detailed specification of internet standards TLS (standard name for SSL) and RADIUS go to
https://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, https://www.garlic.com/~lynn/

When did full-screen come to VM/370?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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

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

--
Anne & Lynn Wheeler | lynn@garlic.com - https://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 - https://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 expanded 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 expanded 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 IBM 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.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://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 - https://www.garlic.com/~lynn/

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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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
https://www.garlic.com/~lynn/rfcietff.htm

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

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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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 - https://www.garlic.com/~lynn/

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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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 distinguish 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 - https://www.garlic.com/~lynn/

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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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 - https://www.garlic.com/~lynn/

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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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 - https://www.garlic.com/~lynn/

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

Refed: **, - **, - **, - **, - **, - **, - **

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????

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

XEDIT on MVS

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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 - https://www.garlic.com/~lynn/

9-track tapes (by the armful)

Refed: ** -, ** -, ** -, ** -, ** -, ** -, ** -, ** -, **

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
https://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 - https://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:
https://www.garlic.com/~lynn/aepay4.htm#comcert14 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert16 Merchant Comfort Certificates

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

--
Anne & Lynn Wheeler | lynn@garlic.com - https://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:
https://www.garlic.com/~lynn/subtopic.html#disk

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

CA Certificate Built Into Browser Confuse Me

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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 aggravated 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:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

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

CMS under MVS

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

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 same MVS production machine w/o VM (which has since evolved into LPARS). This was one of those periods where there was not going to be anymore VM releases ... i.e. no VM/XA.

At 12:01 AM 11/21/2001 -0600, Alan Ackerman 925-675-4358 wrote:
I heard a rumor once that SIE (Start Interpretive Execution) was originally designed to support running CMS under MVS. I have no way of verifiying this, though.

SIE was quite heavy duty for running simple CMS .... especially if you could do a CMS environment in MVS for running CMS applications.

running cms applications under mvs ref:
https://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party

recent thread in another ng
https://www.garlic.com/~lynn/2001m.html#33 XEDIT on MVS

In some respects the original MVS TCP/IP support was akin to that ... basically the VM TCP/IP ported to MVS with effectively emulators for the necessary VM pieces.

Also, the MVS posix support is somewhat analogous ... i.e. execution environment for posix applications.

serialization from the 370 architecture "red-book"

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Date: Wed, 21 Nov 2001 11:17:32 -0700
Subject: serialization from the 370 architecture "red-book"
Newsgroups: bit.listserv.vmesa-l

From System/370 Architecture, AR-3799-01-POK, edition of October 27, 1972:
Thus, a coder may learn to his sorrow, on seeing the core dump tomorrow, lack of serialization can produce both frustration and compute bills that force him to borrow.

The red-book/architecture document was a cms script document that had two modes ... the AR mode and the principles of ops mode .... i.e. AR mode was the full document, POP mode was a subset that showed up in the principles of ops.

The architecture version was distributed in a "red" 3-ring binder (resulting in the reference "red-book").

info

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: info
Newsgroups: alt.os.multics
Date: Thu, 22 Nov 2001 19:09:34 GMT

Chris Jones writes:
When CISL moved from 575 Tech Square (which, BTW, has now been renumbered, I think to 500) to 4 Cambridge Center in about 1984, moving the motor generator was one of the trickiest parts. Its weight exceeded the rated capacity of the freight elevator. As I recall, since the elevators were supposed to have a safety factor of two and the weight was under that, by having a Cambridge elevator inspector on the scene and running the elevator in some special (slow?) mode, it was possible to make the move. The alternative would have been a crane or cherry picker able to hoist the weight up 9 stories, and moving the thing across the floor into its room.

for the machine room on the 2nd floor of 545 Tech sq. ... it was somewhat easier to pop a window and to use a crane to hoist something thru.

there was a separate issue in those buildings having to do with cooling.

the machine room on the 2nd floor had chillers that took directly from the city water system, ran it thru the chillers and then dumped it directly into an 8inch sewer pipe ... it was against the wall on one side of the machine room. For some reason (building code?) it was air gaped ... you could actually see the water roaring out of the pipe from the chillers dumping into the sewer pipe.

In any case, later in the '70s when they looked at conserving water, recycling with cooling towers on the roof ... they found that the tech. sq roofs couldn't handle the loading weight.

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

Solutions to Man in the Middle attacks?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Solutions to Man in the Middle attacks?
Newsgroups: sci.crypt
Date: Thu, 22 Nov 2001 20:00:10 GMT

advonet@yahoo.com (John Hanna) writes:
To celebrate Thanksgiving I thought I'd take a short time to be thankful for my freedom and how crypto contributes to our freedom. Thanks to all you who have contributed to opensource crypto!

SSL solved the Man in the Middle problem by having a trusted third party (Verisign & co) sign certificates.

Are there other solutions to the MITM problem? Specifically, is there any way for two parties to establish a trusted channel with only opensource software? (IE without a third party's confirmation or a previous shared-secret.)

SSL trust is slightly more complicated since the CA's root certificates had to be distributed "out-of-band" with the browsers and you have to trust the procedures used to include trusted root certificates as part of browsers (and the browser distributer has followed some set policies and practices with regard to including such certificates).

The two parts of certificates in SSL domain name certificates were

1) some additional integrity that the server/ip-address you are talking to is the server you think you are talking to when you typed in the URL (basically compares the domain name typed in with the URL to the domain name in the certificate). This supposedly helps with various kinds of domain name infrastructure issues where there might be a redirection of a domain name to some different ip-address. Note this doesn't help situations where somebody is clicking on a html token from a page that might have been maliciously modified (so that the domain name clicked on is guaranteed to be the domain name in the certificate).

2) using the public-key from the certificate as part of a symmetric, secret key exchange.

The interesting issue from #1 is this basically is a matter regarding concernts about the integrity of the domain name infrastructure. However, when somebody contacts a CA about getting an SSL domain name certificate .... the CA has to contact the authoritative agency that controls domain name ownership ... i.e. the domain name infrastructure (the infrastructure with possible integrity issues that justify the certificates in the first place).

Now the interesting thing is that one of the proposals to improve the integrity of the domain name infrastructure (so that it can be better trusted by CAs when they contact the domain name infrastructure to validate the owner of a domain name) is for domain name registration to also include public key registration (then any subsequent transactions by the domain name owner can be signed with the corresponding private key ... and the domain name infrastructure can validate the signature using the registered public key, NCR, aka No Certificate Required).

However, the domain name infrstructure is actually implemented in such that it can do real-time distribution of any information associated with domain name (not just ip-address) .... including real-time distribution of any (registered) publickey. The net is that part of the solution for improving the integrity of the domain name infrastructure so that SSL domain name certificate have a higher quality trust chain (i.e. is the person getting the certificate really the owner of the domain name) also can be a solution for obsoleting the requirement for certificates ... aka given equivalent integrity/trust level, would the preference be for 1) a public-key distribution paradigm using certificates manufactured potentially a year in the past with stale information or 2) a real-time public-key distribution paradigm.

Remember, the final authority with regard to domain name information binding is the domain name infrastructure .... CAs only manufactur certificates representing such information binding after validating the validity of the binding with the authoritative agency responsible for the information (aka the trust in certificate information binding is based on the policies and practices that a CA uses to corroborate the validity of the information that goes into a certificate).

random refs:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
https://www.garlic.com/~lynn/aadsm8.htm#softpki12
https://www.garlic.com/~lynn/aadsm8.htm#softpki14
https://www.garlic.com/~lynn/aadsm8.htm#softpki16
https://www.garlic.com/~lynn/aadsm8.htm#softpki18
https://www.garlic.com/~lynn/aadsm8.htm#softpki19
https://www.garlic.com/~lynn/aadsm8.htm#softpki20

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

denver 2001 convention

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: denver 2001 convention
Newsgroups: comp.sys.super
Date: Thu, 22 Nov 2001 23:50:12 GMT

eugene@cse.ucsc.edu (Eugene Miya) writes:
Best hand out: I got them the weekend before at Hackers. At SC: oh... I dunno. Maybe the flyswatter with and for bugs. I got one for the Museum. There was a light pen (the ink doesn't last nearly as long). The flashlights are all bad compared to photonlights. I did get a Compaq Linux license plate which I am sending to the Smithsonian at their request for the National Air and Space Musem (I gave them my Unix license plate). There were drawings for Palms (I'm not interested in that dumb technology)

slac/fermi
http://sc2001.slac.stanford.edu/

they list a url for the "beam tree" clear plastic cube with embedded "frozen" particle scatter
http://sc2001.slac.stanford.edu/beamtree

but it seems to be 404 at the moment.

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

FA: Early IBM Software and Reference Manuals

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FA: Early IBM Software and Reference Manuals
Newsgroups: alt.folklore.computers
Date: Fri, 23 Nov 2001 05:38:17 GMT

lwinson@bbs.cpcn.com (lwin) writes:
Later on, more "hard core" computer science students got out of school. I suspect many of these people began on non-IBM mainframes, using timesharing (ie GE, RCA, CDC, etc), non IBM S/360 mainframes, or mini computers (ie PDP). They developed a different relationship with the computer and their field, seeing it as a hobby as well as a profession. The smaller machines allowed more personal experimentation, esp with the operating system and direct machine instructions, as opposed to the IBM mainframe where all the "good" stuff was kept tightly locked up.

a large percentage of universities & research institutions had VM/370 timesharing ... possibly as much or more than non-ibm mainframe timesharing. I've contended that while the IBM timesharing may have been larger install base than all the non-IBM mainframe timesharing combined ... that it was somewhat discounted because the IBM non-timesharing installs totally drarfed IBM timesharing installs (when somebody mentioned IBM ... they immediately thot of all the IBM batch processing that had proliferated across the world).

Both CERN and SLAC had similar VM/370 installations and somewhat shared applications as well as application development. I would also claim that CMS/VM370/GML install since early 70s at CERN contributed significantly to HTML & the WEB (i.e. GML evolving into SGML, HTML, XML, etc).

misc. mainframe unix discussion
https://www.garlic.com/~lynn/2001l.html#8 mainframe question
https://www.garlic.com/~lynn/2001l.html#17 mainframe question

misc. related to proliferation of unix boxes:
https://www.garlic.com/~lynn/2001l.html#50 What makes a mainframe
https://www.garlic.com/~lynn/2001m.html#15 departmental servers

posting about ibm mainframes on early arpanet
https://www.garlic.com/~lynn/2001l.html#34

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

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

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Call for folklore - was Re: So it's cyclical.
Newsgroups: alt.folklore.computers
Date: Fri, 23 Nov 2001 15:24:57 GMT

jmfbahciv writes:
I see that name in association with security problems. I played ADVENT in 1976 or 77. Then came a game called HAUNT. When I get my -10 system, that is the game I'm going to download and see if I can figure out how to get inside the GDed house.

first time i ran into it was march of '78 at tymshare (vm/cms). It took me another two weeks to obtain the fortran source to run internally.

misc ref:
http://www.emuunlim.com/doteaters/play4sta1.htm
from above:

You are in a maze of twisty passages, all alike.

Adventure aka ADVENT aka Colossal Caves is the next logical evolution of computer games, a complete text-based adventure game by Willie Crowther. It is written in FORTRAN on the venerable PDP-1 in 1972 while Crowther is working for Bolt, Beranek and Newman, Inc. (BBN), the Boston company made up mostly of MIT students which is awarded the contract to develop the ARPAnet for the U.S. government. Later, at the Stanford Artificial Intelligence Lab at Stanford University, the game is discovered and expanded on by Don Woods. Crowther is inspired by the new fantasy themed paper-and-dice game Dungeons and Dragons which is just starting to become popular. More inspiration comes from his adventures as an avid spelunker. In Adventure, you must explore the vast Colossal Caves and return to the starting point with as many treasures as you can. The locations are based on his and his wife's exploration of the Mammoth Cave system in Kentucky. The original parser in the game is a rudimentary "verb-noun" structure, but the descriptions are very compelling. Again, access to the mainframe running the program through the ARPAnet allows the program to become very popular among university students across the country.

... snip ...

mainframe adventures (doesn't list "adventure" on vm/cms ... but large number in the attached list are all ibm 370):
http://www.lysator.liu.se/adventure/Mainframe_adventures.html

place to get zork (source and executable) for cms
https://www.leeandmelindavarian.com/Melinda#VMHist

random refs:
https://www.garlic.com/~lynn/98.html#56 Earliest memories of "Adventure" & "Trek"
https://www.garlic.com/~lynn/99.html#52 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
https://www.garlic.com/~lynn/99.html#83 "Adventure" (early '80s) who wrote it?
https://www.garlic.com/~lynn/99.html#84 "Adventure" (early '80s) who wrote it?
https://www.garlic.com/~lynn/99.html#169 Crowther (pre-Woods) "Colossal Cave"
https://www.garlic.com/~lynn/2000b.html#72 Microsoft boss warns breakup could worsen virus problem
https://www.garlic.com/~lynn/2000d.html#33 Adventure Games (Was: Navy orders supercomputer)
https://www.garlic.com/~lynn/2001m.html#14 adventure ... nearly 20 years
https://www.garlic.com/~lynn/2001m.html#15 departmental servers
https://www.garlic.com/~lynn/2001m.html#17 3270 protocol

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

Commenting style (was: Call for folklore)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Commenting style (was: Call for folklore)
Newsgroups: alt.folklore.computers
Date: Sun, 25 Nov 2001 16:36:18 GMT

Charles Richmond writes:
Perhaps you are right... I was thinking more along the lines of a macro substitution of "+4" for "". But I guess the result would have been incrementing the location counter by four. Isn't there some legitimate way to really increment the location counter in 370 assembler???

the (machine) location counter and the 370 assembler addresses are slightly different. Effectively, except for RLD adcon, all the addresses used by the assembler are relative to the start of the program (actually esdid) being assembled ... mostly used to generate address register/displayments as operands of instructions.

normally instructions are layed down sequentially in the program as they are encountered in the program. There are some mechanisms like DS (define storage) that can reset that. ORG can also be used to override default assembler operation ... the form might be like:


LM      ra,rb,arg1
         ORG     -4
DC      x'83'
ORG     ,

relative address plus/minus some value. The preceeding might be used in a "diag" macro defining a diagnose/x'83' instruction if the assembler didn't have built-in opcode for the instruction. Basically have the assembler generate a load multiple instruction with the arguments of the macro. Then "org" back to the machine instruction code, and overlay it with the instruction code for diagnose and then "org" forward to the next highest used address.

The assembler (and compilers) then spit out TXT cards that are what actually get loaded into machine storage. TXT cards are effectively binary with data &/or instructions that are to be loaded into machine storage locations.


Col
1               12-2-9 / x'02'
2-4             TXT
5               blank
6-8             relative address of first instruction or data in record
9-10            blank
11-12           byte count ... number of bytes in information field
15-16           ESDID
17-72           56-byte information field
73-80           deck id, sequence number, or both

cols. 6-8 is the hex relative address of the start of data/instructions in the card.

cols. 11-12 is the hex byte count of the data/instructions on the card (i.e. <|=56)

cols. 17-72 is 56-byte hex field for data to be placed in storage.

In the "org" example above, the assembler could generate a truncated TXT card with the load-multiple the last piece of data in the information field. This could be followed by a TXT card that only contained the (relative) address for the start of the load-multiple instruction, a length of one, and just x'83' in col. 11. The next TXT would resume with an address following the load-multiple instruction.

random refs:
https://www.garlic.com/~lynn/2001.html#60 Text (was: Review of Steve McConnell's AFTER THE GOLD RUSH)
https://www.garlic.com/~lynn/2001.html#8 finding object decks with multiple entry points
https://www.garlic.com/~lynn/2001.html#14 IBM Model Numbers (was: First video terminal?)

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

FA: Early IBM Software and Reference Manuals

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: FA: Early IBM Software and Reference Manuals
Newsgroups: alt.folklore.computers
Date: Sun, 25 Nov 2001 16:51:22 GMT

Charles Richmond writes:
Actually it was made possible by IBM. IBM "legitimized" the personal computer and caused big business to buy into the PC. Mi$uck took a giant ride to the top on the backs of IBM...as did the clone makers. Mi$uck merely took advantage of the IBM gravy train...

it was somewhat a evolutionary process. I would claim that IBM legitimized the hardware for a business desk-top computer (although called a personal computer). It had the attributed that the business could replace the desk-top 3270 mainframe interface with a single keyboard/display that provided both the mainframe 3270 function ... and also had local computing capability.

The big star for the local computing capability started out being lotus 123 spread-sheet (aka in terms of exceedingly large sales volume ... at least by personal computer standards up until then, the combination of single keyboard/display for mainframe access and lotus 123 desktop computing was the big winner).

Having achieved critical mass install-base volume with those two winning combinations ... the rest just snow-balled .. aka larger install-base met more people wrote applications, the more people writing applications met more people had additional reasons for buying them. The increasing demand then prompted clones, and cheaper clones fed increasing demand, which fed more application devleopment, which fed more demand.

I would claim that the strictly home/bobbyist of the time never achieved the critical mass for the spontaneous combustion (positive feedback loop). It was the combo

1) beusiness desktop single keyboard/display,
2) mainframe access,
3) lotus 123,
4) ibm marketing in the business community

that resulted in the snowball.

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

TSS/360

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: TSS/360
Newsgroups: alt.os.multics,alt.folklore.computers
Date: Sun, 25 Nov 2001 17:31:37 GMT

ehs suggested a repost here ... possibly comparing the size of the Multics & TSS/360 organizations.

IBM had bid 360/67 for multics (maybe still 360/62 at that time before models 60, 62, 70, got renamed 65, 67, & 75 because of the faster memory technology) and cambridge (2nd & 4th floor, 545 tech. sq) had planned to play a significant part in that activity.

Loosing the bid, IBM created a group in mohansic for TSS/360, a virtual memory operating system that would run on the 360/67. This would have been sometime '66. I think by '68, the mohansic organization was up to somewhere in the 1000-1200 headcount range working on TSS/360. This continued up through the '70s although TSS was "decommitted" (it wasn't actually canceled, but the group was reduced to possibly 20-30 head-count responsible for supporting the dozen or so major customers).

Later in the '70s & early '80s, TSS(/370) saw some significant re-vitalization from AT&T and bell-labs .... using it as sort-of a microkernel for Unix running on mainframes.

During this period, the cambridge group at the 4th floor started the virtual machine project; first with CP/40 and CMS i.e., custom, relocation hardware was added to a 360/40 and the virtual machine monitor was developed while the user environment "CMS" was being developed in parallel to "run" in a virtual machine. Finally a 360/67 became available in Cambridge and the CP/40 monitor was ported to 360/67 (changing its name to CP/67). I would estimate that by '70 or '71 3-4 times as many 360/67s were running CP/67 as was running TSS/360.

The CP/67 group was split off from the scientific center, eventually taking over the 3rd floor and absorbing most of the IBM Boston Programming Center (and many of the people that had worked on CPS ... a non-virtual-memory, 360-based "conversational programming system" as well as jean sammet and some misc. other people). The group/product was renamed VM/370 for the port/introduction of virtual memory on the 370 line of computers.

Eventually, the group was bursting at the seams in 545 tech. sq and was relocated to a recently vacated SBC building in burlington mall (SBC been turned over/sold to CDC as part of gov. settlement of ibm getting out of service bureau business).

Later in the '70s, when the burlington mall group was shutdown (the group had grown to possible 200 or so by that time) and all the people were told to move to POK to work on the VMTOOL ... a significant number left IBM (especially a lot of the CMS developers) and went to work for DEC on VMS (this was one of those periods when there wasn't going to be anymore VM/370 releases and all the people were needed to support the "internal-only" VMTOOL ... a virtual machine monitor tool that was dedicaetd to MVS/XA development).

a lot of this is covered in much more detail (including misc & sundry CTSS happenings) in Melinda's history paper at:
https://www.leeandmelindavarian.com/Melinda#VMHist

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

Author seeks help - net in 1981

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Author seeks help - net in 1981
Newsgroups: alt.folklore.computers
Date: Mon, 26 Nov 2001 17:07:51 GMT

Lars Poulsen writes:
Fall of 1981 is not too distant from when I got on the 'net, so maybe I can help you a bit. By 1981, the network was solidly TCP/IP, and FTP, telnet and SMTP were firmly in place, but of course WWW was about a decade into the future.

arpanet had tcp, ftp, telnet, etc. but was not "IP" until the great cut-over of jan 1, 1983.

There were host to host protocols, host to IMP protocols, with NCP, IMP, TIP, etc. and around 250 network nodes at the time of the cut-over. Computers didn't directly connect to the network, the network was composed of IMPs and TIPs ... the IMPs provided the interface for host/mainframe computers. The TIPs (terminal interface processors) allowed management of terminals connected to the network where the terminals didn't have to connect to the network thru some host/mainframe.

for a replay of a little of this see:
https://www.garlic.com/~lynn/internet.htm

specific extract from history
https://www.garlic.com/~lynn/2000d.html#72

some email from Dec '82 about the tcp/ip cut-over on 1/1/83:
https://www.garlic.com/~lynn/2000e.html#18

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

TSS/360

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSS/360
Newsgroups: alt.os.multics,alt.folklore.computers
Date: Mon, 26 Nov 2001 17:31:39 GMT

Tom Van Vleck writes:
Lynn's post sure brings back memories of the 60s. I moved from Project MAC to the MIT Comp Center about 1969, continuing to work on Multics but also taking on responsibility for the declining CTSS and the 360/67 that the MIT Urban Systems Lab had obtained, run for a year, and then turned over to the Center. So I got to meet and work with some of the CP/CMS developers on the third floor of Tech Square, and heard presentations about TSS/360 at IBM SHARE meetings.

in terms of group size ... the TSS/360 group had grown to about 1000-1200 in the late '60s ... while the CP/40,CP/67,CMS group (within the science center at 545 tech sq) had grown to 14 by the start of 1970 (CSC on about 1/2 the 4th floor, around 35 people total, with the machine room on about 1/2 of the 2nd floor).

The CP/67 group grew quickly during 70/71 from 14 to maybe 60(?) taking over 3/4ths of the 3rd floor, absorbing the boston programming center, etc (and changed its name to vm/370 officially when virtual memory was finally announced for 370 machines).

As it was bursting at the seams on the 3rd floor, the group moved out to the vacated (ibm) service bureau building in burlington mall where the group grew to 200 or so people until '76 when it was shutdown and moved to POK.

The VM/370 group at its peak in the '70s with thousands of installations was possibly 1/6th the size of the tss/360 group at its peak (with its dozen installations).

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

Free digital signature??

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Free digital signature??
Newsgroups: comp.security.misc
Date: Mon, 26 Nov 2001 17:46:33 GMT

"Henrik Gammelmark" writes:
I know it is possible to get digital signatures for Outlook Express etc. from Verisign.com, but is there anywhere it is possible to get a FREE one????? Verisign offers a free 60 day trial, but I would like to have a permanent one..

minor clarification ... digital signatures are something you do ... by signing something. certificates are something that you get somewhere that typically attest that they've have done some due diligence checking that the entity generating some digital signature correlates to some attribute ... for instance a specific email address (aka somehow a specific email address belongs to the entity generating the digital signature).

it is also possible to generate your own (self-signed) certificate using various public domain software packages .... but the recipient of the "triple" (message, digital signature, certificate) has less reason to trust any claim you make about a specific email address belonging to you.

In the case of "email" certificates, typically your email processing software has a built-in list of certification authorities (CAs) that you are willing to trust (i.e. your email client has a built-in list of operations that issue certificates where you trust that they have verified the information in the certificate they issue ... like an email address).

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

Author seeks help - net in 1981

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Author seeks help - net in 1981
Newsgroups: alt.folklore.computers
Date: Mon, 26 Nov 2001 19:49:22 GMT

kyork writes:
There was ''Compuserve'' and ''the Source'' both of which had local numbers in many areas. Not really ISPs as such (since none connected to the I), but they did provide a bunch of features, albeit at an astronomically high price.

there were also a number of commercial online services ... including several vm/cms online systems like tymshare, interactive data corporation, ncss, etc. tymshare also operated tymnet, a packet network with POPs in lots of places and provided connectivity services to more than tymshare (i.e. various universities and corporations had tymnet connectivity for things like terminal access around the world).

somewhere in that time-frame there was other ibm-mainframe platform online services, dialog (world-wide library search system), lexis/nexis (world-wide legal & publicaction search system), and national library of medicine.

NLM was initially developed using BDAM access method on ibm mainframes in the late '60s and for all I know still is a mainframe bdam application. In the early '80s, NLM had already run into the large database query problem; aka at about 5-8 query terms it became bi-model either returning tens of thousands of "hits" or zero "hits". The holy grail became how to formulate query strategy such that resulted in more than zero, put less than even large hundreds.

Somewhere in the early 80s time-frame GratefulMed appeared (first I believe on apple) for NLM, where the query response was not the hits ... but the count of the hits. Qeuries were saved and strategy was to discover some query combo that resulted in reasonable number of hits.

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

Author seeks help - net in 1981

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Author seeks help - net in 1981
Newsgroups: alt.folklore.computers
Date: Mon, 26 Nov 2001 23:54:54 GMT

kyork writes:
Also, parts of ''War Games'' were fairly correct for the time, ignoring of course the talking computer.

and what looks more like a 407 tab accounting machine with lights and the side-slot for where the "plug-board" would be.

random war game reference:
https://www.garlic.com/~lynn/2000d.html#39 Future hacks [was Re: RS/6000 ]

some misc. 407 refs (including url pointers to 407 pictures):
https://www.garlic.com/~lynn/99.html#137 Mainframe emulation
https://www.garlic.com/~lynn/2000.html#19 Computer of the century
https://www.garlic.com/~lynn/2000.html#20 Computer of the century
https://www.garlic.com/~lynn/2000f.html#44 Al Gore and the Internet (Part 2 of 2)
https://www.garlic.com/~lynn/2000f.html#46 Al Gore and the Internet (Part 2 of 2)
https://www.garlic.com/~lynn/2001f.html#5 Emulation (was Re: Object code (was: Source code - couldn't resist compiling it :-))

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

TSS/360

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSS/360
Newsgroups: alt.folklore.computers
Date: Tue, 27 Nov 2001 14:56:18 GMT

John Alvord writes:
The purpose of the visit was to make contacts. There was a project to rewrite VM/370 (jokingly called ZM/XB) and it was thought that TSS might serve as a base for that effort. TSS was like Multics in being architected as a three-level system, user/supervisor/kernel was they way I remember it. [The ia386 architecture has 4 ring levels, a ghostlike reflection of the Multics influence.] This was one of many thoughts about the future of VM.

some of the early TSS analysis for ZM/XB that I worked on with Ed Lassettre. The 2nd meeting of the "ZM" project (march '83) was held in Kingston at an off-site classroom. The people that operated the facility were suppose to have scheduled the "VM" meeting with signs indicating the appropriate room. Somehow that was garbled and there were signs up saying "ZM".


                TSS versus VM/SP

                TSS     VM/SP

modules         109     261

LOC             51k     232k

(LOC .. lines of code)

as per prior comments, while the CP/67-VM/370 started out as compact micro-kernel ... over a 15 year period a lot of traditional operating system people (not trained in micro-kernel principles) made up the bulk of the people working on VM & CMS (and since it was so easy to add this thing or that thing to a well-designed micro-kernel ... in the changes went ... unfortunately after 15 years of such activity, it was no longer compact). Some SWAG analysis.


Required TSS modifications

 Removing TAM2 (extended terminal support)
VMC Support
   -  ... KLOC & ... modules hit?
- SIE & MAS dependencies
GTF Follow-on
- hardware/software trade-offs
   - Expanded Store
Close Coupling
   - shared memory
- single system image
Functional Processors

Total estimated KLOC is ???at least 30 percent of base??? and at least
some modification to all modules.

TSS Problems

Scheduling of closely coupled, asynchronous virtual machines (and/or
address spaces).
- (this is a VM/SP problem also).
 Running supervisor in translate mode.
Current type one documentation

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

TSS had been decommuted and only supported by a small, focused group for ten years at this time (some things didn't get done just because they were lower priority and not enough people to work on them).

misc. past references to TSS analysis
https://www.garlic.com/~lynn/94.html#12 360 "OS" & "TSS" assemblers
https://www.garlic.com/~lynn/95.html#1 pathlengths
https://www.garlic.com/~lynn/2001l.html#24 mainframe question

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

Author seeks help - net in 1981

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Author seeks help - net in 1981
Newsgroups: alt.folklore.computers
Date: Tue, 27 Nov 2001 22:08:10 GMT

Patrick Scheible writes:
Right, with a personal computer you would typically dial in to a University server by phone. The modems were 1200 baud then, (possibly 2400?), cost a few hundred $, and the width and depth of a shoebox and about half as tall.

i had gotten a 2741 early in 70 as a home terminal with one of those accoustic modems that you placed the hand-set inside and closed the cover. 2741 ran at 134cps.

late in the '70s I was able to upgrade my home machine to a CDI miniterm that ran at 300. It used rolls of heat-sensitive paper (something like some of the current faxes) and had a cover that when on made it look about like a large briefcase.

In feb. of 1980, my home terminal was upgraded to a 3101 ("glass" teletype) that ran at 1200. The 3101 had a base unit/controller about half the height of the original PC-case, a monitor (similar to a PC b/w monitor), keyboard, and a separate printer (a simpler version than the basic pc-printer).

The 3101 could operate in line-mode or "block-mode" ... sort of a mini-3270 operation. The printer could be set to "slave" every line printed ... or it could be setup so that it would just "print" the current screen when the print screen button was used.

Logging into local corporate mainframe also allowed access to the world-wide internal network (which eventually also had a arpanet/csnet gateway). Six months after the great internet cut-over to "IP" on 1/1/83, the internal network had about four times as many nodes as the arpanet/internet. random ref:
https://www.garlic.com/~lynn/99.html#112

One of the other frequent places to "visit" was Tymshare. Tymshare (large mainframe, online VM/370 service bureau) had set up special online (essentially free) newsgroup operation for Share (ibm mainframe users group) to discuss VM/370 (VMSHARE) and (later) IBM/PC (PCSHARE).

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

TSS/360

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TSS/360
Newsgroups: alt.os.multics,alt.folklore.computers
Date: Wed, 28 Nov 2001 21:16:18 GMT

jraben@cascinc.com (Jeff Raben) writes:
how come there is nothing here about LLMPS (lincoln labs) and MTS (Michigan Timeshare System) that originally ran on the /67?

The combination ran on many univerity machines.

Jeff and stir with a Runcible spoon...

note that LLMPS was mostly simple (ibm/360) multitasker with a number of simple unit-record and tape utilities (card->tape, print tape, copy tape, punch cards, etc). It was a contributed Share program ... I still have the LLMPS manual in a box someplace.

The (strong) rumor is that MTS started off using the LLMPS multitasker for the original base for developing MTS ... Michigan Terminal System, an interactive, virtual memory system for the 360/67 ... offering a lot of vanilla os/360 facilities in a interactive, online environment.

Lincolm Labs had a duplex '67 and was the first installation to get CP/67 installed from the Cambridge Science Center (sometime in '67). The university that I was at was the 2nd installation (after lincoln) ... getting CP/67 installed the last week in Jan. 1968.

For the 360/67 there were (at least) virtual memory, paging systems TSS/360 CP/67 MTS

There was also a virtual memory, non-paging hack done to OS/360 MVT13 running on a pair of 360/67s at Boeing Huntsville. OS/360 for long running applications could get into severe storage fragmentation. Boeing Huntsville ran a number of long-running 2250 (large vector display, used for CAD design and other) applications that would eventually result in severe OS/360 storage fragmentation. The virtual memory, non-paging hack to MVT13 was to help medicate storage fragmentation problems (i.e. use virtual memory to be able to provide something that looked like contiguous storage regions for each application).

There was also a special tri-plex, fully redundant 360/67 for some real-time gov. project being done by Lockheed ... which was writing their own special code (I don't know much about this one).

In the '60s, there were also at least two service bureau spin-offs using CP/67, one was NCSS in stamford, conn. and the other was IDC (a number of lincoln labs. people) out in waltham.

In the middle of June, '68 Cambridge Science Center was holding a one week CP/67 class for prospective & current customers) at a location in Beverly Hills that the University sent me to. The week (possibly friday) the class was to start, several of the people resigned from CSC as part of forming the NCSS startup. As a result, I got pressed into teaching a lot of the class. I believe that sometime in the '70s, NCSS may have also installed a Multics system.

Dec. '68 or Jan. '69, Boeing created Boeing Computer Services with the idea of moving all of their commerical dataprocessing into BCS and be able to start operating it as a profit center (as opposed to cost center). During '69, spring break, IBM talked me into giving a one week computer class to the BCS technical staff (that had been integrated into BCS up to that point). About that time they moved the Boeing Huntsville 360/67s to Seattle. Boeing eventually had quite a few 360/67s running CP/67.

misc. bcs postings
https://www.garlic.com/~lynn/99.html#32 Roads as Runways Was: Re: BA Solve
https://www.garlic.com/~lynn/99.html#130 early hardware
https://www.garlic.com/~lynn/2000f.html#66 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2001b.html#8 "HAL's Legacy and the Vision of 2001: A Space Odyssey"
https://www.garlic.com/~lynn/2001b.html#9 "HAL's Legacy and the Vision of 2001: A Space Odyssey"
https://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2001g.html#56 YKYBHTLW....
https://www.garlic.com/~lynn/2001l.html#32 mainframe question

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

Contiguous file system

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Contiguous file system
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Thu, 29 Nov 2001 00:19:45 GMT

no.way@completely.invalid (William Burrow) writes:
My understanding is that VM and some other mainframe OSes used contiguous file systems. Does anyone here have any familiarity in using these? I am interested in what utilities and techniques were/are used to maintain such filesystems.

For example, one problem with contiguous file systems is that free space can become fragmented. This makes it difficult to create a new, largish file, even if enough space is available, due to the fragmentation. The literature suggests that sometimes the file system is taken down and reorganized. Were there other techniques used to deal with or circumvent this problem?

CMS (under VM/370) has had a scatter (record) allocation system much like the original unix (some have claimed that some of the original personal computer filesystems were actually derived from a stripped down CMS filesystem).

Over the years unix (and others) have attempted to add contiguous record reservation/allocation for files being created (w/o hints ahead of time, you don't necessarily know the total size required) ... however it doesn't mandate it and can degenerate to the original scatter (record) allocation paradigm under severe fragmentation.

CMS has had various strategries over the years to dump/restore files when there hasn't been real-time defrag utilities (aka file records get dump sequentially ... so when they come back to a fresh filesysteam they get allocated sequentially ... even if there is an explicit contiguous allocation schema). This is not a space issue ... but a performance issue when system has degenerated into severe non-contiguous, scatter allocation (as opposed to not being able to allocation non-contiguous records at all).

The mapping of filesystems to raid-5 devices has further motivated contiguous allocation schemas since it allows for the parallel transfer across all devices in the raid.

A separate strategy to address contiguous data transfer (both pre/non-RAID and RAID) that comes from contiguous allocation was log-structured filesystem. The theory was that as cache became more and more prevalent ... a larger & larger percentage of read requests would be directly satisfied from cache. That left the issue of providing sequential/contiguous performance from writes ... where writes from multiple different applications could be interleaved. Log-structured file system somewhat used a sequential write allocation policy ... i.e. the next write operation would be assigned the next sequential fresh block (even if it was supposedly a replacement of an record in an existing file). That resulting in the appearance of the overall system appearing as if all writes occurred sequentially and could effectively block write large number of records in a single I/O operation.

log-structured filesystems tended to have a lot more "cleaning" than just simple defragmentation ... since there wasn't any actual replacement of existing blocks (like some of the LISP and APL storage allocators which had to periodically "garbage" clean & compact allocated records to make available large extents of open space for the sequential write operations.

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

Contiguous file system

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Contiguous file system
Newsgroups: comp.lang.asm370,alt.folklore.systems
Date: Thu, 29 Nov 2001 01:03:46 GMT

"GerardS" writes:
CMS' file system is, in all it's simpilicity, is too comlicated to describe here, but surfice it to say, no matter when you crashed the CMS system (deliberately), the file system (pointers) would be intact and you wouldn't lose file integrity.

the native CMS file system (as oppose to newer cms "shared-file system") from original 1966 or so would always write all "changed" filesystem structure information to new disk location and then update disk record "3" to indicate whether it was using the previous/unchanged version or the new/changed version (in that sense, the filesystem control information was handled very much like a log structured file system).

In the mid-70s, this was enhanced with the CMS/EDF filesystem which had a number of performance enhancements but also introduced the concept of records 3/4 pair. There was a failure mode in the '66 filesystem that if a transient i/o error occurred while updating/writing record 3 AND the system also lost power or crashed at the same time ... then record 3 could be left in a corrupted/inconsistent state.

The EDF filesystem would ping/pong back and forth between writing record 3 and writing record 4. When the filesystem was accessed, both records 3/4 would be read the correct action taken.

however, this is independent of any contiguous allocation file system strategy.

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

Contiguous file system

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Contiguous file system
Newsgroups: comp.lang.asm370,alt.folklore.computers
Date: Thu, 29 Nov 2001 01:21:03 GMT

Anne & Lynn Wheeler writes:
concept of records 3/4 pair. There was a failure mode in the '66 filesystem that if a transient i/o error occurred while updating/writing record 3 AND the system also lost power or crashed at the same time ... then record 3 could be left in a corrupted/inconsistent state.

there was also a specific power-lost failure mode that could occure in the middle of a write operation ... there was sufficient power for the controller/drive to finish the write operation ... but not sufficient power to keep the cpu memory/channel operating ... as a result ... the controller would be "reading" binary zeros off the channel interface & writing to disk. The resulting record would have the start valid data, the remainder of the record all zeros, and a correct ECC calcuated so there was no I/O error indicated on subsequent read.

This was only an issue with record 3 writes and none of the other filesystem structure information. Since updated filesystem control information was always written to a new disk location ... all existing filesystem control information remained intact ... and the information in the "new" locations was only activated after record three was written. If any of the filesystem structure records were being written during loss of power ... record 3 would not have had a chance to be written and restart would use all of the old information. It wasn't until record 3 was in the process of being written that there was a problem. The EDF file system fixed that with the ping/pong use of record 3/4 pair.

... but again, this isn't a contiguous file allocation issue.

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

next, previous, index - home